SaMD regulatory pathways: a practical guide for digital health teams

What qualifies as SaMD

The IMDRF definition is narrow and useful: software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. Three practical tests follow from it:

• Medical purpose. Diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease. General wellness and fitness claims sit outside.
• Independent of hardware. Software that controls an infusion pump is software in a device (SiMD) and follows the parent device. A mobile app that interprets images from any camera is SaMD.
• Claims drive class. The same algorithm marketed as "flags possible atrial fibrillation" and as "logs your heart rate" lands in two different regulatory worlds.

IMDRF risk categorisation

IMDRF categorises SaMD on two axes: the significance of the information the software provides (treat or diagnose / drive clinical management / inform clinical management) and the state of the healthcare situation (critical / serious / non-serious). The intersection yields categories I through IV, with IV the highest risk. Regulators do not adopt these categories verbatim, but the matrix is the fastest way to predict where a product will fall in both FDA class and EU MDR class.

FDA classification and pathways

• Exempt / not enforced. General wellness software, most administrative and EHR-adjacent tools, and medical device data systems that only transfer, store or display data.
• 510(k). The default for Class II SaMD with a legally marketed predicate — CAD triage, image post-processing, physiological signal analysis. You demonstrate substantial equivalence, usually with a standalone performance study against a reference standard.
• De Novo. Novel low-to-moderate risk software with no predicate. Slower and evidence-heavier than 510(k), but it creates the classification regulation and product code later entrants use.
• PMA. Class III software supporting critical diagnosis or therapy where failure carries a high probability of serious harm. Expect clinical trial evidence.

Whichever route applies, FDA expects documentation proportional to the software's level of concern: architecture and requirements, cybersecurity per the premarket cybersecurity guidance, human factors for clinician- or patient-facing interfaces, and validated off-the-shelf software components.

Clinical decision support carve-out

Section 520(o)(1)(E) of the FD&C Act excludes certain CDS from the device definition. All four criteria must hold: the software does not acquire or analyse a signal, image or pattern from a device; it displays or analyses medical information; it supports or provides recommendations rather than a specific preventive, diagnostic or treatment output; and the healthcare professional can independently review the basis of the recommendation. Time-critical outputs, signal/image analysis, and non-transparent model reasoning each defeat the exclusion.

EU MDR Rule 11 and UKCA

Rule 11 of MDR Annex VIII is the single most consequential rule for digital health in Europe. Software intended to provide information used for diagnostic or therapeutic decisions is at least Class IIa; it escalates to IIb where an incorrect decision could cause serious deterioration or surgical intervention, and Class III where it could cause death or irreversible deterioration. Monitoring of vital physiological parameters is IIa, or IIb where variation could result in immediate danger. In practice almost no clinically useful software remains Class I, so a notified body and a full QMS under ISO 13485 are the baseline, with IEC 62304 for the software lifecycle and IEC 82304-1 for health software products.

Great Britain currently operates the UKCA route under the UK MDR 2002, with EU CE marking accepted during the extended transition period; Northern Ireland continues to follow EU rules. A UK Responsible Person is required for non-UK manufacturers, and the forthcoming UK regime is expected to align more closely with MDR software classification.

AI/ML change control and PCCP

Adaptive models create a regulatory problem: the authorised device is the version reviewed. A Predetermined Change Control Plan lets you specify in the original submission which modifications you intend to make (retraining data, performance thresholds, input types, deployment regions), the protocol and verification methods, and the impact assessment. Modifications inside the authorised plan can ship without a new submission. In Europe, equivalent planning shows up through the change management procedure agreed with your notified body and, for high-risk AI, the EU AI Act's overlapping obligations on data governance, logging and human oversight.

Pre-submission checklist

• Write the intended-use statement first; every classification decision follows from it.
• Search FDA classification and 510(k) databases for a plausible predicate and product code.
• Map the product against the IMDRF matrix and MDR Rule 11 in parallel — they often disagree.
• Decide on a PCCP before locking the model if retraining is on the roadmap.
• Plan standalone performance evidence with a pre-specified reference standard and subgroup analysis.
• Line up IEC 62304 lifecycle records, cybersecurity documentation and human factors evidence early.

FAQ