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 an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 24 LINKSSaMD is software that is itself the device — regulated across the CSV and quality-system disciplines through a lifecycle stack (IEC 62304, ISO 14971, ISO 13485), and strained anew where the AI/ML systems below are designed to keep learning.
06 · QUALITY MATURITY — SOFTWARE AS A MEDICAL DEVICE (SAMD), REACTIVE TO ADAPTIVE
Software ships with a medical purpose but no device quality system; risk is assessed at the end and design history is reconstructed on request.
IEC 62304 processes and ISO 13485 procedures exist, but the software safety class and the risk file are assembled to pass review rather than to drive design.
Each software item is safety-classed, requirements trace through verification and validation, and ISO 14971 risk management runs through the lifecycle.
Real-world performance, complaints, and adverse events feed the risk file and design changes before regulators ask.
A predetermined change control plan governs model updates within an agreed envelope, with drift monitoring and human oversight built into the product.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 5
Derived from the 5 standards SPEQ maps to this subject, across 4 regulatory bodies: FDA, ISO, EC, IEC.
RECORDS & OBJECTIVE EVIDENCE
- Software safety classification (IEC 62304 class A/B/C) with rationale
- Requirements-to-verification-and-validation traceability for the software
- An ISO 14971 risk-management file maintained across the lifecycle
- Clinical-evaluation and intended-use documentation supporting classification
- For AI/ML, a predetermined change control plan and real-world performance monitoring
COMMON INSPECTION FINDINGS
- Medical-purpose software placed on the market without a device quality system
- Risk file assembled after design rather than driving it
- Software changes made without assessing impact on safety classification
- A model retrained and deployed outside any authorised change envelope
- Post-market performance monitoring for model drift absent
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.
FREQUENTLY ASKED
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.