An app that reminds you to drink water is not a medical device. An app that analyzes heart rhythm and warns you about atrial fibrillation is. The difference is not the technology — it can be identical — but the intended use. The moment software is intended to diagnose, treat, prevent, monitor a medical condition, or drive a clinical decision, it becomes a regulated medical device in its own right, even with no hardware attached. The FDA calls this category Software as a Medical Device, or SaMD, and it is one of the fastest-growing and most closely watched areas in digital health. This article is educational background for product teams, not regulatory or legal advice; classification decisions belong with qualified regulatory counsel.

Where the Line Actually Falls

The FDA looks at what you claim and what the software functionally does, not at your business intentions. In broad strokes:

  • Generally outside device regulation: general wellness and fitness tracking, a symptom journal the user maintains themselves, general medical reference information, medication reminders the user configures, and tools that simply display data without interpreting it.
  • Generally inside device regulation: analyzing physiological data to produce a diagnosis or alert, recommending a dose, triaging patients by urgency, interpreting images or test results, and computing a clinical risk score — including, and especially, when a machine learning model does the interpreting.

There is also a middle band the FDA has said it generally intends not to enforce against — low-risk software that supports healthy lifestyles or helps patients manage a condition without analyzing data to make clinical calls. That enforcement discretion is not a legal exemption, and relying on it without a documented rationale is a risk.

How you word your intended use is therefore a genuine strategic decision. The same technical capability can be marketed as a wellness product or developed as a regulated device, and that choice determines your entire development path. But the claim has to be truthful: an app presented as "wellness" whose marketing hints at diagnosis is a regulatory and liability exposure, not a clever workaround. If you are still unsure which side you are on, start with our test in is my product a medical device.

What Changes Once You Cross the Line

The principles are the same as for any medical device — risk-based classification, a quality system, risk management, and a technical file, as laid out in our guides to FDA medical device classes and the FDA approval process. Software adds several requirements of its own:

  • A documented software lifecycle. Requirements, architecture, unit and integration verification, and full traceability from every requirement to the test that covers it. The FDA also expects a documented software safety classification that determines how much of this documentation it wants to see.
  • Clinical validation. Evidence that the algorithm detects what it claims to detect, on real and demographically diverse data — not on a curated internal dataset. Sensitivity and specificity claims have to be supported.
  • Software-specific risk management. What happens when the input is wrong, the sensor disconnects, the phone is in airplane mode, or the user misreads the output. A false alarm and a missed alarm are different failure modes with different consequences and different mitigations.
  • Controlled updates. You cannot simply push a release. Every change is assessed for its impact on safety and effectiveness, and a significant change can require a new submission. The update mechanism itself has to be validated — the engineering side is covered in OTA firmware updates.
  • Cybersecurity as a regulatory requirement. Not merely good practice. Health data is among the most sensitive there is, and the FDA expects a threat model, a software bill of materials, and a plan for handling vulnerabilities across the product's supported life.

Manufacturers also need a quality management system that covers software design controls; most teams building for both the US and international markets align it with ISO 13485 from the beginning rather than retrofitting later.

The App Stores Are a Second Gatekeeper

Even after the regulator, the distribution platforms have their own rules. Both major app stores require evidence of regulatory clearance or approval before they will publish software making medical claims, and they will pull listings that make claims the developer cannot support. Plan that review into the launch schedule alongside the ordinary submission process described in publishing an app to the app stores.

Learning Models: The New Regulatory Problem

A model that keeps learning poses a question the traditional framework was never built for: how do you clear a product that changes itself? The approach that has emerged is that what gets cleared is a frozen, documented model version, and every change to it is managed. Regulators now allow developers to submit a predetermined change control plan up front — a document defining which kinds of model updates are permitted without a new submission, within what performance boundaries, and through what internal validation process.

If you are planning a learning product, build that infrastructure from day one: version-controlled training datasets, a fixed benchmark suite every candidate model must clear before deployment, documented data provenance, and field performance monitoring that detects drift before users do. Retrofitting dataset governance onto a model that has already shipped is close to impossible.

The Burden Is Also the Moat

The regulated path is slower and more expensive than shipping an ordinary app — realistically a multiple of the cost, with the largest line items being clinical evidence and the quality system rather than the code. Our breakdowns of FDA approval cost gives a realistic frame.

But that burden is also protection. A competitor cannot copy a cleared product in a month. A cleared product earns clinician trust, opens the door to health-system partnerships, and becomes eligible for reimbursement pathways that consumer wellness apps can never reach. In a field where trust is the entire product, regulation is an asset on the balance sheet.

Build the Software and the Evidence Together

Projects House develops medical software and connected devices with the design history file, risk management, and verification evidence produced alongside the code rather than reconstructed afterward. Have a clinical algorithm or health app and need to know which path it falls on? Tell us what it claims to do through our contact form. More in our medical device development knowledge center.