Software as a Medical Device (SaMD): FDA Classification and Pathway Guide

Software teams usually arrive at regulation from the wrong end. The question is not "which FDA pathway do we use?" It is "is this software a device at all, and if so, what risk does its output carry?" Everything else — classification, pathway, evidence, documentation — follows from those two answers.

Software as a Medical Device (SaMD) is software intended for a medical purpose that performs that purpose without being part of a hardware medical device. A phone app that analyses a retinal image is SaMD. The firmware inside an infusion pump is software in a medical device, which is regulated as part of that device. The distinction matters because it changes what you submit and how the software is assessed.

Is your software regulated at all?

Not every clinical software product is a device. FDA's policies on device software functions and clinical decision support set out categories that are either not devices or subject to enforcement discretion: administrative and billing tools, general wellness products, electronic health records used for record keeping, and certain clinical decision support software that displays or analyses information in a way the clinician can independently review.

That last carve-out is narrower than it sounds. If the software provides a specific preventive, diagnostic or treatment output, if it is time-critical, or if the clinician cannot independently review the basis for the recommendation, it is generally a device. "Independently review" is the hinge. A tool that says "this lesion is suspicious, confidence 0.94" without the clinician being able to reach that conclusion from the same information is a device output, not decision support.

Get this determination documented early and in writing. It is also a good candidate for a Q-Submission pre-submission question if it is genuinely arguable.

How SaMD is classified by risk

FDA classifies devices into Class I, II and III based on risk and the controls needed to provide reasonable assurance of safety and effectiveness. For software, risk is driven by two things: the significance of the information the software provides to the healthcare decision, and the state of the healthcare situation or condition it addresses.

In practice, that produces a familiar spread. Most cleared SaMD sits in Class II — imaging triage and notification software, diagnostic assistance, monitoring analytics — where general and special controls are sufficient. Class III is reserved for software whose output drives a decision in a critical situation where an error carries a high probability of serious harm, typically where the software is the sole basis for a diagnosis or treatment decision in a life-threatening condition.

The practical first step is the same as for any device: search FDA's product classification database for the intended use, not the technology. Find the regulation number and product code that matches what the software is for. If nothing matches, that is a signal, not a dead end — see the predicate device article.

Which pathway applies

Once classification is settled, the pathway follows the same logic as hardware.

510(k) premarket notification, when a legally marketed predicate with the same intended use and technological characteristics exists. This is the route for the large majority of cleared SaMD, including most AI-enabled imaging software.

De Novo classification request, when the risk is low to moderate but no predicate exists. A great deal of novel AI-enabled software has come to market this way, which then creates the classification regulation and special controls subsequent products cite. Note the fee difference: see De Novo fees in 2026.

Premarket approval (PMA), when the software is Class III. Rare for standalone software, but it is the route where the algorithm alone carries a high-risk decision.

Our pathway selection guide walks through the decision sequence, and the cost and timeline comparison covers what each route costs in money and time.

What a software submission actually contains

FDA's guidance on the content of premarket submissions for device software functions sets the expectation, and the documentation level scales with risk. Expect to provide:

A software description and architecture, including the operating environment and any off-the-shelf or open-source components. A risk management file covering software-related hazards, traceable to mitigations. Requirements and design specifications, with traceability from requirement to test. Verification and validation testing with results, including unit, integration and system level. A revision history and unresolved anomaly list with a justification for each remaining anomaly. Cybersecurity documentation, including a software bill of materials and a plan for managing post-market vulnerabilities. Human factors and usability data where use error is a meaningful hazard. Clinical or clinical-grade performance data, with a test set that is independent of training data for AI-enabled products.

For machine learning products, the independence of the test set and the representativeness of the data are where most review questions land. Document the demographics, sites and devices in your data, and state the limitations in labelling rather than leaving them for a reviewer to find.

Planning for change

Software ships updates; submissions do not. If you intend to retrain or improve a model after authorisation, a Predetermined Change Control Plan lets you specify those changes up front and make them without a new submission. See our article on PCCPs for AI/ML devices. Plan the PCCP with the original submission — retrofitting one later is a separate filing.

If you are also going to Europe, note that EU MDR classification rules push a large share of clinical software into Class IIa or higher, often a step above the US position. The EU MDR and UKCA guide covers where the two diverge.

Three things to do now

Settle the device question in writing, with the relevant FDA policy cited, before the engineering roadmap assumes an answer.

Search the classification database by intended use and record the product code and regulation you are targeting, or the absence of one.

Design the evidence and the change control plan together. The test set that supports clearance is also the test set your PCCP will reuse.

For the wider commercial picture, MedTech Compass scores regulatory and reimbursement conditions across 25+ markets, DevicePath offers an open model for early classification triage, and the market access guide covers what happens after clearance.

Sources

1. FDA — Software as a Medical Device (SaMD): https://www.fda.gov/medical-devices/digital-health-center-excellence/software-medical-device-samd 2. FDA — Artificial Intelligence and Machine Learning in Software as a Medical Device: https://www.fda.gov/medical-devices/software-medical-device-samd/artificial-intelligence-and-machine-learning-software-medical-device 3. FDA — Device Software Functions Including Mobile Medical Applications: https://www.fda.gov/medical-devices/digital-health-center-excellence/device-software-functions-including-mobile-medical-applications 4. FDA — Policy for Device Software Functions and Mobile Medical Applications (guidance): https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-functions-and-mobile-medical-applications 5. FDA — Clinical Decision Support Software (guidance): https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software 6. FDA — Content of Premarket Submissions for Device Software Functions (guidance): https://www.fda.gov/regulatory-information/search-fda-guidance-documents/content-premarket-submissions-device-software-functions 7. FDA — Product Classification database: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfPCD/classification.cfm

This article summarises public FDA guidance and is not legal or regulatory advice.