Software as a Medical Device
SaMD Category Self-Assessment
Usability Engineering for SaMD: IEC 62366 and Annex I Requirements
What IEC 62366-1 requires in practice for software — how to plan and document usability engineering, what a summative evaluation needs to show, and how this connects to your GSPR Annex I obligations.
AI and Machine Learning as a Medical Device: MDR, MDCG 2021-24, and the AI Act
How AI/ML-based SaMD is classified under EU MDR Rule 11, what MDCG 2021-24 adds for machine learning software, and how the EU AI Act intersects with your MDR obligations.
Post-Market Surveillance for SaMD: Articles 83–92 and Real-World Data Obligations
What MDR Articles 83–92 require from SaMD manufacturers in practice — how to build a PMS system that works for software, what PMCF obligations look like, and how real-world data flows into your PSUR and technical documentation.
Does Your Software Qualify as a Medical Device?
How to apply the intended purpose test under EU MDR to determine whether your software is a medical device — and where MDCG 2019-11 draws the line.
EUDAMED Registration for SaMD: UDI Obligations and What SaMD Manufacturers Need to Do
What EUDAMED registration looks like for standalone software — how to assign a Basic UDI-DI, what data you need to register, and what the UDI labelling rules mean for software that has no physical packaging.
Classifying Software Under MDR: Rule 11 Explained
How Rule 11 in Annex VIII works for software, with worked examples — and how the severity of potential harm drives your device class.
MDCG Guidance for SaMD: The Documents That Shape How Regulators Assess Your Software
An overview of the MDCG guidance documents specifically relevant to SaMD manufacturers — what each one covers, how they connect to each other, and which ones are essential reading before submitting for Notified Body review.
Technical Documentation for SaMD: What the File Actually Needs
What the technical file looks like for software — integrating IEC 62304, software development lifecycle documentation, and MDR Annex II/III requirements in practice.
Cybersecurity Requirements for SaMD Under EU MDR
What GSPR 17.2 and MDCG 2019-16 rev.2 require in practice — and how to integrate cybersecurity into your ISO 14971 risk management process.
Clinical Evaluation for SaMD: What Your CER Actually Needs
How Article 61 and Annex XIV apply to software — what clinical evidence looks like without hardware clinical investigation data, and how to structure PMCF for SaMD.
Software as a Medical Device
Whether software qualifies as a medical device under MDR is not always obvious, and teams often get it wrong in both directions — claiming medical device status when it isn't warranted, or missing it entirely for software that genuinely is in scope. The starting point is always intended purpose: if the software is intended to be used for diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease, it may well be a medical device. MDCG 2019-11 is the qualification guidance the industry and regulators use, and it is worth reading carefully rather than relying on informal interpretations.
Once qualification is settled, classification is the next challenge. Software that qualifies as a SaMD is classified using the general rules in Annex VIII, but Rule 11 applies specifically to software and catches many teams off guard. The class is driven by the severity of harm that could result if the software provides incorrect information — not by the software's complexity or technical sophistication. Software that informs clinical decisions about serious conditions or drives therapy can land at Class IIb or III, triggering full Notified Body involvement. MDCG 2021-24 provides the classification guidance, with worked examples that are far more useful than reading Rule 11 in isolation.
Cybersecurity is a hard requirement under MDR, not a nice-to-have. GSPR Annex I, Chapter I, Section 17.2 requires that software is designed to resist unauthorised access and that cybersecurity risks are addressed throughout the lifecycle. MDCG 2019-16 rev.2 (updated in 2022) is the current reference document. One thing that catches teams off guard: cybersecurity is expected to be covered in both the risk management file and the technical documentation. A security assessment done as a standalone exercise — disconnected from the ISO 14971 risk process — will not satisfy a Notified Body.
Clinical evaluation of software is a recurring source of confusion. The same Article 61 and Annex XIV obligations apply, but the evidence sources look different from hardware devices. Literature on the underlying algorithm or clinical use case may be available; clinical investigations generate usability and performance data; PMCF for software often means systematic collection of real-world use data. State of the art in software clinical evaluation is still evolving, and auditors' expectations have tightened since 2021. Resources here walk through what a software CER needs to cover and where the gaps most commonly appear.
AI and machine learning add another layer. MDCG 2021-24 addresses AI/ML-based software, and the European Commission's AI Act intersects with MDR for high-risk AI systems — software that is both a medical device and a high-risk AI system must satisfy both regulatory frameworks. This is a fast-moving area. Resources in this category flag what is settled, what is still guidance in draft, and what teams need to monitor as implementation develops.
AI Participation & Regulatory Notice
The content on this page may be partially assisted by Artificial Intelligence (AI) to improve readability and ensure clarity.
While our team audits this content, please be aware:
- Accuracy: AI-assisted interpretations may contain nuances that differ from official MDCG guidance.
- Timeliness: Medical Device Regulations (MDR) are subject to updates. Always verify critical information against the official EUR-Lex database.
- Liability: MDR Academy provides these resources for educational purposes only. They do not constitute legal advice.