Software as a Medical Device (SaMD)
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 diagnostic algorithm, a treatment-planning app, an AI that flags a scan. Because the software is the device, its quality, safety, and risk management are regulated as a device in their own right, under a stack of standards built specifically for software that can harm a patient.
What counts as SaMD
The International Medical Device Regulators Forum (IMDRF) defines SaMD as software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. That distinguishes it from software that drives or is embedded in an instrument (software in a medical device) and from general wellness or administrative software with no medical purpose.
The line matters because it determines whether the full weight of device regulation applies. A phone app that calculates an insulin dose is SaMD; the firmware inside an infusion pump is device software but not SaMD; a step counter is neither. Getting the classification right at the outset drives every downstream obligation.
The lifecycle and quality stack
SaMD is developed under a device quality management system — ISO 13485 — with a software-specific lifecycle standard, IEC 62304, that structures development, maintenance, risk management, configuration management, and problem resolution. IEC 62304 assigns each software item a safety class (A, B, or C) according to the harm a failure could cause, and scales the required rigour accordingly.
Risk management runs through everything via ISO 14971, applied across the whole lifecycle rather than as a one-time assessment. In the US the quality-system requirements sit under 21 CFR Part 820 (converging with ISO 13485 as the FDA Quality Management System Regulation takes effect in 2026); usability engineering (IEC 62366) and, increasingly, cybersecurity expectations round out the stack.
Classification and market access
Risk class determines the regulatory pathway. Under EU MDR (Regulation 2017/745), Rule 11 classifies most decision-driving software into higher risk classes — software intended to provide information used for diagnostic or therapeutic decisions is generally Class IIa or higher, up to Class III where decisions could cause death or irreversible deterioration — which pulls in Notified Body involvement. In the US, SaMD is cleared or approved through the 510(k), De Novo, or PMA pathways according to risk, with the 21st Century Cures Act having clarified which clinical-decision-support software falls outside the device definition.
The IMDRF risk framework — combining the significance of the information the SaMD provides with the state of the healthcare situation — is the shared language regulators use to reason about how much assurance a given SaMD needs. Classification is not a formality: it sets the evidence bar, the clinical-evaluation expectation, and the level of independent scrutiny.
AI/ML SaMD and change control
AI- and ML-driven SaMD strains the traditional model because the software is designed to change. A model retrained on new data is, in the classic view, a modified device requiring re-review — which is incompatible with continuous learning. Regulators have responded with predetermined change control plans (the FDA’s approach) that authorise a defined envelope of future modifications up front, so a model can be updated within agreed bounds without a new submission each time.
This is also where SaMD meets Good Machine Learning Practice and the emerging good-AI-practice principles: data quality and representativeness, transparency about a model’s intended use and limits, monitoring for performance drift in the real world, and human oversight of automated decisions. The device standards define how to build SaMD safely; the AI-practice principles define what "safe" additionally means when the device learns.
Derived from the 5 standards that anchor this topic.
What is Software as a Medical Device (SaMD)?
Per the IMDRF, SaMD is software intended for a medical purpose that performs that purpose without being part of a hardware medical device — such as a diagnostic algorithm or a treatment-planning app. Because the software itself is the device, it is regulated as a medical device.
What standards apply to SaMD?
A device quality system (ISO 13485), the software lifecycle standard IEC 62304 with its A/B/C safety classes, risk management under ISO 14971, and usability engineering (IEC 62366). In the US, 21 CFR Part 820 (the QMSR from 2026); in the EU, MDR 2017/745.
How is SaMD classified under EU MDR?
MDR Rule 11 classifies most decision-driving software into higher risk classes — generally Class IIa or above for software informing diagnostic or therapeutic decisions, up to Class III where a wrong decision could cause death or irreversible harm — which brings Notified Body involvement.
How is AI/ML software regulated as a medical device?
AI/ML SaMD is designed to change, which strains the fixed-device model. Regulators use predetermined change control plans to authorise a defined envelope of future model updates up front, alongside Good Machine Learning Practice expectations for data quality, transparency, real-world performance monitoring, and human oversight.
Get the Weekly GxP Briefing
Curated regulatory intelligence — enforcement, recalls, guidance, and quality signals — in one practitioner-grade email each week. Free.