Software as a Medical Device (SaMD): Key Definitions
Establishes the term "Software as a Medical Device" and the vocabulary regulators now share for it — what counts as SaMD, how it differs from software embedded in a device, and the concepts subsequent SaMD guidance builds on.
What this does not cover
stated in the document's own scope- Establishes definitions and terminology; it does not itself set risk categories — that is the subject of the companion document N12.
- Is a harmonisation guidance document, not a binding regulation; each member regulator gives its concepts effect through national law.
- Defines SaMD, and explicitly excludes software that is embedded in or drives a hardware medical device from the SaMD term.
- Provides vocabulary, not quality-management or clinical-evaluation requirements, which are covered by later IMDRF SaMD documents and by standards such as IEC 62304.
Always verify against the current published text before relying on it for a submission or inspection.
Overview
IMDRF/SaMD WG/N10, "Software as a Medical Device (SaMD): Key Definitions," is the document that established the internationally shared term "Software as a Medical Device" and the vocabulary regulators now build on. It 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, and it distinguishes SaMD from software that is embedded in or drives a hardware device. It sets out the core concepts and terminology — the boundary of what counts as SaMD, its relationship to a platform, and the notions that later SaMD guidance (risk categorisation, quality management, clinical evaluation) depends on.
Scope & applicability
Software intended for a medical purpose that performs that purpose without being part of a hardware medical device.
Legal basis & how it acquires force
N10 is guidance from the International Medical Device Regulators Forum (IMDRF), a voluntary forum of medical-device regulators; it is not a statute and creates no binding obligation on its own. It acquires influence by being taken up by member regulators — the FDA, the European Commission and EU authorities, Health Canada, and others — who have aligned their definitions and guidance to its concepts. IMDRF is a harmonisation forum, not a regulator: its documents shape national rules and guidance rather than replacing them, and MDSAP is a separate programme run by participating authorities, not an IMDRF product.
Document structure
| Part | Covers |
|---|---|
| Scope and purpose | Why a common SaMD vocabulary is needed and what the document sets out to define |
| Definition of SaMD | Software intended for a medical purpose that performs it without being part of a hardware medical device |
| Distinguishing concepts | How SaMD differs from software embedded in, or that drives, a hardware medical device, and its relationship to a computing platform |
| Key terms and concepts | The supporting definitions and framing that later SaMD documents (N12 and beyond) rely on |
Key requirements
- Correct determination of whether a product is SaMD before selecting a pathway
- Consistent use of the shared vocabulary in technical documentation
Implementation tips
- Settle the SaMD determination in writing at the concept stage — it drives pathway, evidence and QMS scope
- Check how each target regulator has adopted or adapted the IMDRF terms; adoption is not uniform
Where this control fails
live FDA enforcementLive FDA recalls SPEQ maps to this standard’s topics — a SPEQ interpretation, not an FDA classification.
International alignment
N10 is the definitional foundation of the IMDRF SaMD document set: N12 builds a risk-categorisation framework on its definitions, and subsequent IMDRF SaMD guidance on quality management systems and clinical evaluation uses the same vocabulary. Because IMDRF members include the FDA, EU authorities, Health Canada, Japan, Australia, and Brazil, the N10 definitions have become the common reference regulators draw on when framing their own SaMD rules.
IMDRF/SaMD WG/N10: frequently asked questions
Quick answers to common questions about IMDRF/SaMD WG/N10.
What is Software as a Medical Device (SaMD)?
Per IMDRF N10, SaMD is software intended to be used for one or more medical purposes that performs those purposes without being part of a hardware medical device. Software that is embedded in, or that drives, a hardware device is not SaMD.
Is IMDRF N10 a regulation?
No. IMDRF is a voluntary forum of device regulators, and N10 is harmonisation guidance. It becomes influential when member regulators — FDA, EU authorities, Health Canada, and others — align their own definitions and guidance to it.
How does N10 relate to N12?
N10 establishes the SaMD definitions and vocabulary; N12 uses those definitions to propose a framework for categorising SaMD by risk. N10 is the foundation N12 builds on.
Is MDSAP part of IMDRF?
No. The Medical Device Single Audit Program is a separate programme operated by its participating authorities. IMDRF is a harmonisation forum that produces guidance such as the SaMD documents; it does not run MDSAP.
This standard in practice
Recall domain is a SPEQ mapping of this standard’s topics, not an FDA classification.