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

Introduction

Software as a Medical Device is defined by the IMDRF as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. The definition is the global baseline, adopted by the FDA, the EU and most other jurisdictions.

Everything downstream of that definition is jurisdiction-specific, and the divergence is wider than most teams expect. The same product is Class IIa in Europe under Rule 11 and a Class II 510(k) in the United States; the classification logic that produces those two answers has almost nothing in common. And the ground moved in January 2026, when the FDA revised its Clinical Decision Support and General Wellness guidance and withdrew its SaMD clinical evaluation guidance entirely.

This guide covers qualification — whether your software is a device at all — then classification in both markets, the standards that apply once it is, the AI overlay, and what has changed recently enough that it is not yet in most reference material.

SaMD, SiMD and MDSW: three terms, three scopes
Qualification: is your software a device?
The IMDRF framework
Classification in the EU: Rule 11 and MDCG 2019-11 Rev.1
Classification and pathway at the FDA
What changed in January 2026
The standards that apply once it is a device
AI-enabled SaMD
Technical documentation
Post-market surveillance and software updates
Compliance checklist
Frequently asked questions
Conclusions

SaMD, SiMD and MDSW: three terms, three scopes

The three are routinely used interchangeably and mean different things. Which one applies decides which classification rules you are reading.

Term	Scope	Examples	Regulated as
SaMD Software as a Medical Device	Standalone software performing a medical purpose independently of any hardware device, running on general-purpose computing platforms	An app analysing retinal images for diabetic retinopathy; a cloud algorithm detecting arrhythmia from wearable ECG data; a treatment recommendation engine	A device in its own right
SiMD Software in a Medical Device	Software embedded in or integral to a hardware device — it drives or controls the hardware	Ventilator control software; infusion pump firmware; MRI image reconstruction	Part of the hardware device
MDSW Medical Device Software	The EU term, from MDCG 2019-11. The superset: software intended for a purpose in the MDR or IVDR device definition, whether independent or driving or influencing a device	Both of the above	Under the MDR or the IVDR

The EU does not use the term SaMD in the Regulation. It uses MDSW, and MDSW is broader: it captures software that influences a hardware device as well as software that stands alone. A team searching EU guidance for “SaMD” will find very little, and will conclude wrongly that the EU has no framework for it.

Qualification: is your software a device?

Qualification comes before classification, and it turns on intended purpose alone — not on the platform, the technology or the sophistication of the algorithm.

Software qualifies where it is intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease or injury; for investigation, replacement or modification of the anatomy or of a physiological process; for control or support of conception; or for the disinfection or sterilisation of devices.

Not a device	Why	Where it gets difficult
General wellness apps — fitness tracking, calorie counting, meditation	No medical intended purpose	A wellness app that begins detecting a condition has changed its intended purpose regardless of how it is marketed
Administrative software — scheduling, billing, records storage	No analytical or decision-support function	An EHR module that flags drug interactions is performing a medical function
Software that only stores, archives or communicates data	Simple search and lossless compression are not analysis	Any transformation of the data that changes what a clinician concludes

Figure 1 — Qualification, then two different classification systems

✦ Premium bundle · SW Documentation Kit Gold

Classified your SaMD? The next step is the lifecycle file.

Whatever the risk class, reviewers expect a complete IEC 62304 file with cybersecurity built in. The Gold Kit covers the full lifecycle, the AI/ML module built on the IMDRF GMLP principles including the PCCP and the AI-augmented CEP and CER, and the cybersecurity documentation — three coordinated modules with a Master Index and Conformity Matrix.

✓ 23 templates · 19 Word + 4 Excel

✓ Scalable to safety Class A, B or C

✓ Save €199 vs buying the SW Kit and AI/ML Kit separately

Get the Gold Kit → €799

The IMDRF framework

The IMDRF risk categorisation, published in 2014, is the conceptual foundation both the FDA and the EU built on. It has two axes and produces four categories.

Significance of the information → Healthcare situation ↓	Inform clinical management	Drive clinical management	Treat or diagnose
Critical life-threatening condition or serious deterioration	Category II	Category III	Category IV
Serious requires major therapeutic intervention	Category I	Category II	Category III
Non-serious no major intervention required	Category I	Category I	Category II

The horizontal axis is about how much of the clinical decision the software is making: inform supplies supplementary information, drive informs a decision a clinician still makes, treat or diagnose makes the decision itself. The vertical axis is about the consequence of getting it wrong.

The framework is not legally binding anywhere. Its value is as a common language: it lets a team reason about where a product sits before confronting either of the two regulatory systems that then apply their own rules.

Classification in the EU: Rule 11 and MDCG 2019-11 Rev.1

In the EU, SaMD is MDSW and is classified primarily under Rule 11 of Annex VIII. Rule 11 provides that software intended to provide information used to take decisions for diagnostic or therapeutic purposes is Class IIa — unless those decisions may cause death or an irreversible deterioration of health, in which case Class III, or a serious deterioration of health or a surgical intervention, in which case Class IIb. Software intended to monitor physiological processes is Class IIa, or Class IIb where it monitors vital physiological parameters whose variation could result in immediate danger.

Class	When	Conformity assessment
Class I	Rare. Software with negligible risk that does not inform a diagnostic or therapeutic decision. MDCG 2019-11 Rev.1 added an example of a low-risk tool based on a validated algorithm with no direct clinical action.	Self-certification, no Notified Body
Class IIa	Most diagnostic and therapeutic decision-support software where an incorrect output leads to non-serious harm; monitoring of physiological processes	Notified Body assessment of the quality system, with technical documentation sampling
Class IIb	Incorrect output may cause serious deterioration of health or lead to a surgical intervention; monitoring of vital parameters where variation causes immediate danger	Full Notified Body assessment including technical documentation review
Class III	Incorrect output may cause death or irreversible deterioration of health	The most rigorous route, with possible expert panel consultation

Class I is absent from the body of Rule 11, and that absence is the single most consequential fact about EU software classification. Software that provides information used in a diagnostic or therapeutic decision starts at Class IIa, which means a Notified Body — with the cost, the queue and the surveillance cycle that follow. Teams that budgeted for self-certification discover this late, and it changes the business case rather than the paperwork.

MDCG 2019-11 Rev.1, issued in June 2025, introduced three changes worth noting. The term Medical Device Artificial Intelligence appears for the first time, marking AI-enabled software as a distinct subset of MDSW. The treatment of modular MDSW is reinforced, requiring each module’s intended purpose to be defined and documented separately. And examples were added covering when software not intended for a medical purpose may still fall under the MDR through Annex XVI, and when MDSW can justifiably be classified as low risk.

Classification and pathway at the FDA

The FDA classifies SaMD within its standard three-tier system, and the route to market is determined by whether a predicate exists rather than by a rule applied to the intended purpose.

Pathway	When it applies	What it requires	Result
510(k)	Class II SaMD with a legally marketed predicate. The most common route for diagnostic and decision-support software.	Demonstration of substantial equivalence in intended use and technological characteristics	Clearance
De Novo	Novel low to moderate risk SaMD with no suitable predicate	A classification request with proposed special controls, usually supported by clinical evidence	Classification into Class I or II — and the device becomes a predicate for others
PMA	Class III SaMD: software supporting or sustaining life, or whose failure could cause serious adverse health consequences	Valid scientific evidence including clinical data	Approval, device-specific and not usable as a predicate

The consequence of the predicate-based system is that two functionally identical products can take different routes depending on what has been cleared before them. It also means the classification question in the US is answered by research — finding and evaluating candidate predicates — rather than by applying a rule, which is a different kind of work from the EU exercise and is usually underestimated by teams approaching the US first.

Figure 2 — EU and FDA classification compared

What changed in January 2026

On 6 January 2026 the FDA published revised final guidance on Clinical Decision Support Software and on the General Wellness policy for low risk devices, superseding the 2022 and 2019 versions respectively. On 7 January it withdrew its guidance on Software as a Medical Device: Clinical Evaluation. The direction is deregulatory, and it moves the qualification boundary rather than the classification rules.

Change	What it does	Who it affects
CDS guidance, Criterion 3	Under the 2022 version, software presenting a single clinically appropriate option failed Criterion 3 and was therefore a device. The 2026 version softens this: the FDA will exercise enforcement discretion where all other criteria of section 520(o)(1)(E) are met.	Anyone producing a risk score, a priority recommendation or a single treatment directive who concluded under the 2022 guidance that they had become a device manufacturer
CDS guidance, transparency	The emphasis on Criterion 4 is maintained and sharpened: the clinician has to be able to understand and independently review the basis of the recommendation, with information presented usably rather than exhaustively	All non-device CDS, and AI-based CDS in particular, where automation bias is the stated concern
General wellness guidance	Non-invasive wearables estimating physiological parameters such as heart rate, blood pressure or glucose can qualify as general wellness products where the intent is solely non-medical, the risk is minimal, and no disease, diagnostic or clinical-management claims are made	Wearable and consumer health products near the qualification boundary
SaMD: Clinical Evaluation withdrawn	The FDA has withdrawn its adoption of the IMDRF clinical evaluation guidance for SaMD	Anyone whose clinical evidence strategy cites that guidance as the FDA’s expectation

The withdrawal matters more than it first appears. The three-pillar model of SaMD clinical evaluation — valid clinical association, analytical validation, clinical validation — comes from that guidance. The model remains sound, remains the IMDRF framework, and remains what a Notified Body expects in Europe. What has gone is the FDA document adopting it, so a US submission that presents the three pillars as satisfying an FDA expectation is now citing a withdrawn guidance. The evidence is still the right evidence; the justification for producing it has to come from somewhere else.

Both guidance documents are non-binding and both were issued without a public comment period. The FDA has signalled that a broader AI regulatory framework is in preparation, and the CDRH guidance agenda for 2026 includes reissuing the policy on device software functions as draft. Anyone whose product sits near the qualification boundary should treat the current position as unstable and re-check it rather than relying on an assessment made against the previous versions.

The standards that apply once it is a device

Standard	What it governs	What it produces
ISO 13485	The quality management system, covering the whole software lifecycle from design inputs to post-market	The QMS itself — and in the US, the legal standard since the QMSR took effect
IEC 62304	Software lifecycle processes, scaled by safety class A, B or C	Development plan, requirements specification, architecture, SOUP list, verification and validation records, release documentation
ISO 14971	Risk management, applied to software-specific hazards: incorrect output, failure, cybersecurity vulnerabilities, use error, interaction failures	The risk management file feeding the benefit-risk determination
IEC 62366-1	Usability engineering — central for software, where the interface is the device	The usability engineering file
IEC 81001-5-1	Cybersecurity activities across the software lifecycle	Threat model, security requirements, security testing evidence, SBOM, vulnerability disclosure policy

The IEC 62304 safety class is not the EU device class and not the FDA class. A Class C software system frequently sits inside a Class IIb device, but the two determinations use different criteria and each has to be performed and justified on its own terms.

On clinical evidence, the three-pillar structure remains the working model regardless of the FDA withdrawal: valid clinical association, showing the output is clinically meaningful and supported by medical evidence; analytical validation, showing the software processes input data correctly and reliably; and clinical validation, showing it performs as intended in real use. Our guide to the EU MDR clinical evaluation report covers how that evidence is assembled for a European submission.

✦ SW documentation kit · IEC 62304

The complete IEC 62304 software file, plus cybersecurity.

12 templates covering the full software lifecycle — development plan, architecture, SRS, traceability, SOUP, verification and validation, release and anomaly log — plus the cybersecurity documentation Notified Bodies now expect under MDCG 2019-16 and IEC 81001-5-1.

✓ 12 templates · 9 Word + 3 Excel

✓ Clause-referenced throughout

✓ Scalable to safety Class A, B or C

Get the SW Kit → €499

AI-enabled SaMD

Software containing a machine learning model carries everything above plus a second regulatory layer, and the two markets have taken different approaches to the same problem: what happens when the device changes after it is cleared.

In the United States, the FDA finalised its guidance on Predetermined Change Control Plans in December 2024. A PCCP lets a manufacturer specify in the original submission which algorithm changes are anticipated, how they will be implemented and validated, and how the impact will be assessed — so that those changes can be made post-market without a new submission, provided the approved protocol is followed. It is the mechanism that makes a learning system commercially viable under a premarket regime.

In the European Union there is no equivalent. Any change affecting the intended purpose, the safety or the clinical performance requires reassessment before implementation. The AI Act adds a parallel set of obligations: a device that is a high-risk AI system under the AI Act carries both regimes, and the obligations for AI systems that are safety components of products covered by Union harmonisation legislation apply from August 2027. The interaction between the two, and the harmonised standard that supports it, are covered in our guides to AI medical device regulation and to EN 18286, the AI Act standard for medical devices.

MDCG 2019-11 Rev.1’s introduction of the term Medical Device Artificial Intelligence signals that the EU intends to treat AI-enabled MDSW as a distinct subset rather than as ordinary software with an unusual implementation.

Technical documentation

The content scales with risk class but the structure is stable, and it differs between the two markets in organisation rather than in substance.

EU — Annex II and III	US — premarket submission
Intended purpose stated precisely: medical condition, patient population, clinical setting, and what information the software provides	Device description and indications for use
Software description: architecture, interfaces, SOUP components, security measures	Software description and architecture design chart
IEC 62304 lifecycle documentation	Software development and maintenance practices; software requirements specification summary; design specification summary
ISO 14971 risk management file with software-specific hazard analysis	Device hazard analysis
Clinical evaluation report	Clinical evidence where required for the pathway
IEC 62366-1 usability engineering file	Human factors documentation where applicable
IEC 81001-5-1 cybersecurity documentation	Cybersecurity documentation including the SBOM
Post-market surveillance plan under Annex III	Lifecycle management plan for updates and patches
Both require traceability across requirements, design, testing and risk controls — and cross-document consistency, so that the intended purpose, the risk file, the clinical evidence and the labelling all describe the same device

Post-market surveillance and software updates

Post-market surveillance is harder for software than for hardware, for a specific reason: the device changes. Patches ship, vulnerabilities are disclosed, models drift, and real-world performance diverges from the validation set in ways the validation set could not have predicted.

Under the MDR the obligations are the general ones — complaints, vigilance, literature, registries and PMCF where applicable — with the PSUR frequency set by class: at least annually for Class IIb and Class III, at least every two years for Class IIa. Our guide to EU MDR post-market surveillance covers the plan and the reports.

The software-specific question is which updates require regulatory action. Bug fixes, security patches and usability improvements generally do not. A change that affects the intended purpose, the clinical algorithm, the user interface in a clinically significant way or the security posture may constitute a significant change requiring assessment before release. The boundary has to be defined in the change control procedure in advance, because it will otherwise be decided under release pressure, and it will be decided the same way every time.

Compliance checklist

Qualification and classification

Document the intended purpose precisely — condition, population, setting, and the information the software provides. Everything downstream derives from it.
Determine whether the software is standalone or drives hardware.
Apply Rule 11 with MDCG 2019-11 Rev.1 for the EU, and identify candidate predicates for the US. Do both; neither predicts the other.
Where several classification rules apply, the most stringent governs.
Re-check qualification against the January 2026 FDA guidance if the product is near the CDS or general wellness boundary.

Quality system and development

ISO 13485 quality system covering all software development activities.
IEC 62304 safety class assigned to each software item, with the rationale recorded.
Full lifecycle documentation proportionate to that class.
SOUP list maintained with versions and ongoing anomaly monitoring.

Risk and clinical evidence

Software hazard analysis under ISO 14971, including cybersecurity hazards and use error.
Clinical evaluation covering valid clinical association, analytical validation and clinical validation.
For Class IIb and III in the EU, plan PMCF from the outset rather than after certification.

Cybersecurity

Security requirements inside the software requirements specification, not appended to it.
SBOM in CycloneDX or SPDX.
Coordinated vulnerability disclosure policy and a post-market monitoring process. See our guide to cybersecurity risk assessment and threat modeling.

✦ Complete catalogue

Find the documentation you need — instantly.

Whether you need a complete kit or just one specific SOP, the catalogue has it. Individual process packages and complete bundles, all instantly downloadable and fully editable.

✓ Complete bundles or individual packages

✓ Individual process packages from €69 each

✓ Software · ISO 13485 · MDSAP · EU MDR · EU IVDR

Browse All Kits →

Frequently asked questions

Is all health software regulated as a medical device?

No. Software qualifies only where it has a medical intended purpose — diagnosing, treating, monitoring, predicting or preventing a disease or condition. General wellness apps and purely administrative software are outside the scope. The boundary cases are clinical decision support tools and wellness applications that approach clinical functionality, and both were addressed by the FDA in revised guidance in January 2026.

Does the EU MDR use the term SaMD?

No. The Regulation does not use it. The EU term is Medical Device Software, defined in MDCG 2019-11, and it is broader: it covers both standalone software and software that drives or influences a hardware device. Any software with a medical intended purpose is regulated under the MDR or the IVDR regardless of which label is applied to it.

What is the minimum classification for SaMD under the EU MDR?

In practice Class IIa. Rule 11 places software that provides information used in diagnostic or therapeutic decisions at Class IIa as a baseline, escalating to IIb or III according to the severity of harm from an incorrect output. Class I is possible but rare, and requires that the software does not inform any diagnostic or therapeutic decision.

Can a mobile app be a medical device?

Yes, where it has a medical intended purpose. An app analysing ECG data to detect atrial fibrillation is a medical device. An app counting steps for general wellness is not. The platform is irrelevant; the intended purpose determines the regulatory status.

What is the difference between SaMD and SiMD?

SaMD is standalone: it performs its medical purpose without being part of a hardware device, running on general-purpose computing platforms. SiMD is embedded in or integral to a hardware device and drives or controls it, and is regulated as part of that device. The EU term MDSW covers both.

What changed in the FDA’s January 2026 guidance?

The FDA published revised final guidance on Clinical Decision Support Software and on General Wellness on 6 January 2026, and withdrew its guidance on Software as a Medical Device: Clinical Evaluation on 7 January. The CDS revision softens Criterion 3, so that software presenting a single clinically appropriate option may fall outside the device definition through enforcement discretion where the other statutory criteria are met. The wellness revision expands the conditions under which non-invasive wearables estimating physiological parameters qualify as general wellness products.

How is AI software that changes after release handled?

Differently in each market. The FDA’s Predetermined Change Control Plan guidance, finalised in December 2024, allows anticipated algorithm changes to be pre-specified in the original submission and implemented post-market without a new one, provided the approved protocol is followed. The EU has no equivalent mechanism: any change affecting the intended purpose, safety or clinical performance requires reassessment before implementation, and the AI Act obligations for high-risk AI systems that are safety components apply from August 2027.

Is the IEC 62304 safety class the same as the device class?

No. IEC 62304 Class A, B and C are determined by the severity of harm that could result from a software failure, and the EU device class and FDA class are determined by different criteria. Class C software is often found in Class IIb or III devices, but the correlation is not a rule and each classification must be performed and justified separately.

Conclusions

The single most valuable thing a SaMD team can do early is write the intended purpose precisely. Classification, clinical evidence, risk scope, documentation depth and post-market obligations all derive from it, and a loose statement produces reclassification and gaps discovered late, when they are expensive.

The second is to work both classification systems separately. The EU asks what could go wrong and applies a rule; the US asks what has been cleared before and looks for a predicate. Neither answer predicts the other, and a team that classifies in one market and assumes the other will follow has done half the analysis.

The third is to accept that this area is moving. The FDA revised two guidance documents and withdrew a third in the first week of January 2026, has signalled a broader AI framework in preparation, and has the policy on device software functions on its 2026 agenda. In the EU, MDCG 2019-11 was revised in June 2025 and the AI Act obligations arrive in 2027. An assessment made two years ago should be re-checked rather than relied on.

If you are building the file, the SW Documentation Kit covers the IEC 62304 lifecycle with the cybersecurity documentation alongside it, and the Gold Kit adds the AI/ML module for devices containing a model.