Software as a Medical Device Explained: How FDA Regulates Standalone Clinical Software

Software as a Medical Device is software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device, per the definition FDA adopted from the International Medical Device Regulators Forum. The category covers standalone products, from mobile screening apps to clinical decision tools, and FDA's SaMD page has carried the definition since at least its December 2018 content date.

What Counts as Software as a Medical Device?

The regulatory question is whether the software performs a medical purpose on its own. FDA's Digital Health Center of Excellence explains that SaMD can run across medical device platforms, commercial off-the-shelf platforms, and virtual networks, and that use of the category continues to increase. The definition deliberately excludes software embedded in a hardware device and software used to manufacture or maintain devices, which follow the pathway of the hardware product itself. It also excludes general-purpose wellness software, which is not a device at all. The boundary cases occupy most of the category's regulatory attention, particularly software that interprets data rather than merely displays it.

Which Software Functions Does FDA Actually Regulate?

FDA maintains a public examples page that maps regulated functions to classification regulations. The agency's examples list includes a mobile platform used to produce controlled test tones for diagnostic hearing evaluations, an audiometer function tied to 21 CFR 874.1050, and a sensor-based function measuring tremor caused by certain diseases, tied to 21 CFR 882.1950. The page also lists functions for which FDA exercises enforcement discretion and functions that are not medical devices, which makes it a practical first screen for product teams. The common thread in the regulated examples is interpretation for a diagnostic purpose in specific patients. Display-only and general health functions generally fall outside the device framework.

How Does a SaMD Product Reach the U.S. Market?

The pathway question reduces to risk class, and the process follows a recognizable sequence.

1. Determine whether the software performs a medical purpose; if not, it is outside device regulation.
2. Identify an existing classification regulation and product code for comparable software.
3. If a predicate exists, file a 510(k) premarket notification demonstrating substantial equivalence.
4. If the function is low to moderate risk with no predicate, use the De Novo classification request.
5. For higher-risk functions that support or sustain life, file a premarket approval application.
6. Comply with quality system regulation and postmarket obligations, including software maintenance and updates.

Each step is documentary: the agency acts on the file a manufacturer submits, and the classification follows the intended use statement, not the underlying technology. Changes to a cleared SaMD, including algorithm changes, can require a new submission depending on their effect on safety and effectiveness.

How Does SaMD Differ From Other Device Software?

The three buckets are easily confused, and the comparison determines both the pathway and the evidence burden.

FDA's examples page anchors each row in specific classification citations, which is what makes the framework usable in a product plan. Companies that misclassify early discover the error at submission, which is the most expensive place to find it.

Why Does the SaMD Framework Matter Now?

The category is where diagnostic algorithms, imaging software, and digital biomarkers land when they seek U.S. marketing, and its definitions predate the current wave of AI-enabled products. FDA's device framework applies to AI-enabled medical devices regardless of the underlying model architecture, and the IMDRF-harmonized SaMD definitions give regulators across jurisdictions a shared vocabulary. For developers, the practical discipline is unchanged: state the intended use precisely, find the predicate, and expect the evidence package to scale with risk class. The framework does not pre-judge any pending filing, and each submission is decided on its own record.

Where Do Clinical Decision Support Functions Fit?

Decision support is the busiest boundary in the category, because much of it is intended for clinicians rather than patients and much of it displays rather than interprets. FDA's examples framework treats functions that acquire, process, or interpret patient data for diagnostic or treatment purposes as device functions, while display-only and workflow tools generally are not. The practical test a product team applies is whether the software's output would substitute for clinical judgment about a specific patient. If it would, the function is inside the device framework and needs a classification basis. If it merely organizes information the clinician already has, it likely sits in the enforcement-discretion or non-device rows of the same table. The examples page is the reference for drawing that line before committing to a submission strategy.

What Evidence Does a SaMD Submission Contain?

Whatever the pathway, the file has to demonstrate that the software does what it claims, on the population it claims, under the conditions it will actually meet. Validation datasets with defined ground truth, sensitivity and specificity with their intervals, and a description of failure modes form the analytical core. Software documentation covers architecture, version control, and the testing that ties each release to the validated configuration. For connected products, cybersecurity documentation is part of the file rather than an afterthought. The evidence burden scales with risk class, which is the entire logic of splitting 510(k), De Novo, and premarket approval into separate tracks. Developers who scope the evidence package to the intended use statement early avoid the most common cycle of deficiency letters.

How Is SaMD Regulated Outside the United States?

The category's shared vocabulary is international by construction. The definition FDA uses comes from the International Medical Device Regulators Forum, a body in which multiple regulators work toward harmonized principles, and the same framework underpins how other jurisdictions approach standalone medical software. Harmonization does not mean a single global filing: classification rules, reviewing authorities, and local representation requirements still differ by market. What harmonization buys is a common definitional layer, so a manufacturer can describe one product consistently across dossiers. Companies planning multi-market launches still sequence submissions market by market, on each regulator's documented timeline. The framework aligns vocabulary, not calendars.

What Obligations Continue After Clearance?

Marketing authorization is the midpoint of a SaMD product's regulatory life, not the end of it. Manufacturers operate a quality system that governs how the software is built, released, and changed, and significant changes can require a new submission depending on their effect on safety and effectiveness. Complaint handling, adverse event reporting, and field actions apply to software exactly as they apply to hardware. Because SaMD ships as updateable code, the change-control discipline is more visible to regulators than it is for physical devices, and version history is part of the inspection record. Postmarket evidence can also reshape the intended use over time. The durable rule is simple: the regulatory story of a software product continues for as long as the product runs.