Citing an IMDRF category as a regulatory classification
It carries no legal force. A submission needs an MDR class or an FDA device classification; the IMDRF category is reasoning, not an answer.
IMDRF SaMD Framework
The IMDRF Software as a Medical Device framework is a series of guidance documents from the International Medical Device Regulators Forum that gives regulators a common vocabulary for SaMD. It defines the term, proposes a four-category risk model based on what the software informs and how serious the patient’s situation is, and sets out corresponding quality system and clinical evaluation expectations.
- Full title
- IMDRF Software as a Medical Device guidance series
- Issued by
- International Medical Device Regulators Forum
- Applies
- No legal force; the shared conceptual layer behind EU and US approaches
What it covers
- N10: key definitions, including SaMD itself — software intended for a medical purpose that performs that purpose without being part of a hardware medical device
- N12: the risk categorisation framework, Category I through IV
- N23: application of quality management system principles to SaMD
- N41: clinical evaluation, and the three-part model of valid clinical association, analytical validation and clinical validation
In practice
The N12 categorisation is built from two axes: the significance of the information the software provides — whether it treats or diagnoses, drives clinical management, or informs clinical management — and the state of the healthcare situation, critical, serious or non-serious. Their intersection gives Category I through IV.
This is not law in any jurisdiction. It is the shared conceptual layer that EU MDR’s Rule 11 and FDA’s approach both draw on, and that is exactly what makes it useful. Where it earns its keep for a founder is as a planning tool before either regulator is engaged: reasoning through the two axes forces an honest statement of what the software actually claims to do clinically, and that statement drives classification, evidence burden and cost in both markets.
N41’s three-part evidence model is also the clearest available articulation of what clinical evidence for software means — that the output relates to the clinical condition, that the software computes it correctly, and that using it produces the intended clinical result.
Where teams get it wrong
Skipping valid clinical association
Teams validate that the model performs and forget to establish that the thing being measured relates to the condition at all. That is the step reviewers probe first.
Deferring the clinical claim
The evidence plan cannot be scoped until the claim is written down. Ambiguity here is what makes evidence budgets unpredictable.
Common questions
What is Software as a Medical Device?
Software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device. That excludes embedded firmware driving an instrument, and includes standalone diagnostic, decision-support and therapeutic applications running on general-purpose hardware such as a phone or a server.
What are the four IMDRF SaMD categories?
They come from two axes. The significance of the information provided — whether the software treats or diagnoses, drives clinical management, or informs clinical management — crossed with the state of the healthcare situation: critical, serious or non-serious. Their intersection produces Category I through IV, with IV the highest impact.
Is an IMDRF category a legal classification?
No. The framework has no legal force in any jurisdiction. A submission needs an EU MDR class or an FDA device classification. What the category is genuinely good for is reasoning before either regulator is engaged, because working through the two axes forces an honest statement of what the software clinically claims to do.
Working out how IMDRF SaMD Framework applies to what you are building is usually the first conversation.
Get in touch →