Software as a Medical Device (SaMD) occupies a unique position in the regulatory landscape. Unlike physical devices, software can be updated continuously, deployed across borders instantly, and embedded into clinical workflows in ways that are difficult to audit or reverse. These characteristics make it one of the most complex categories to bring to market under the EU Medical Device Regulation (MDR, Regulation (EU) 2017/745).
This guide covers what SaMD developers, digital health companies, and regulatory teams need to understand to achieve and maintain CE marking under EU MDR, from initial classification through to post-market surveillance.
For companies developing AI-powered SaMD, see our companion guide: EU AI Act and Medical Devices: What SaMD Developers Need to Know
1. Does Your Software Qualify as SaMD?
Not all medical software is a medical device. The first and most important step is determining whether your software falls within the MDR’s scope.
The International Medical Device Regulators Forum (IMDRF) defines SaMD as:
“Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”
Under MDCG 2019-11 the EU guidance document on software qualification and classification, software qualifies as a medical device when the manufacturer’s intended purpose includes one or more of the following: diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease or injury in individual patients.
The key word is intended. It is not the capability of the software that determines its regulatory status, it is how the manufacturer positions, labels, and markets it.
Software that qualifies as SaMD:
- An AI-based image analysis tool that assists radiologists in detecting tumours
- A mobile app that predicts hypoglycaemic events for diabetic patients
- A cloud algorithm that classifies ECG signals to detect arrhythmias
- A clinical decision support tool that recommends treatment options based on patient data
Software that does not qualify as SaMD:
- Scheduling, billing, or administrative healthcare software
- General wellness or fitness apps not marketed for disease diagnosis or monitoring
- General-purpose image viewers used in clinical settings but not intended for diagnosis
- Software that drives or controls a hardware medical device (classified as software in a device, not as a device)
If there is genuine uncertainty about whether your software qualifies, document the reasoning explicitly. This is one of the first things a Notified Body will look for.
2. Classification Under MDR Rule 11
Once software is confirmed to be a medical device, it must be classified according to Annex VIII, Rule 11 of the MDR. This is the rule specifically designed for software, and it determines whether you need a Notified Body and which conformity assessment route applies.
Rule 11 classification depends on the intended purpose and the consequences of error:
Class III — Software intended to provide information used to make decisions for diagnosis or therapy of life-threatening conditions, where an error could cause immediate deterioration or irreversible harm. Examples: software diagnosing acute MI from ECG, cancer detection algorithms used in surgical planning.
Class IIb — Software intended to provide information for diagnosis or therapy of serious conditions where an error could cause significant deterioration. Examples: software classifying radiology images for treatment planning, AI tools supporting oncology staging.
Class IIa — Software intended to provide information for diagnosis or monitoring, where errors are unlikely to cause serious harm. Examples: chronic disease monitoring apps, software flagging abnormal lab values for clinical review.
Class I — Software intended only for administrative purposes, or software that monitors physiological processes in non-critical contexts. Class I requires no Notified Body involvement (unless sterile, with a measurement function, or reusable surgical).
The critical implication: the majority of clinically meaningful SaMD — any tool that informs a clinical decision, will land in Class IIa or above, requiring Notified Body review. Plan for this from the start of development.
3. The MDR Compliance Roadmap for SaMD
Achieving CE marking for SaMD under MDR requires a structured process across multiple technical and quality domains. These are not sequential checkboxes — they must be built in parallel and integrated throughout the software development lifecycle.
Intended Purpose and Use Context
Define the intended medical purpose with precision: who the users are, in what environment the software will be used, what inputs it processes, and what outputs or decisions it supports. This definition drives classification, clinical evidence requirements, labelling, and risk management. Changes to intended purpose late in development are expensive and disruptive.
Risk Management (ISO 14971)
Software-specific hazards go beyond physical failure. For SaMD, risk management must address algorithm drift (model performance changing over time on real-world data), cybersecurity vulnerabilities, data input errors, interoperability failures, and the consequences of false positives and false negatives in different clinical scenarios. Risk management is a lifecycle activity — it does not end at submission.
Quality Management System (ISO 13485)
A QMS certified to ISO 13485 is mandatory. For software, the QMS must specifically address design control, configuration management, version control, change control, software validation, and CAPA processes for software defects. Many software organisations transitioning from commercial development processes (Agile, DevOps) find that adapting these to ISO 13485 requirements is one of the most significant operational challenges.
Software Lifecycle (IEC 62304 and IEC 82304-1)
IEC 62304 is the harmonised standard for medical device software lifecycle processes. It requires software safety classification (Class A, B, or C based on the severity of harm if the software fails), and mandates specific documentation, verification, and validation activities proportionate to that class. IEC 82304-1 extends this to standalone health software. Compliance with these standards, evidenced in the technical documentation, significantly streamlines Notified Body review.
Clinical Evaluation (MDCG 2020-1)
SaMD must demonstrate clinical benefit not just technical performance. Under MDCG 2020-1, clinical evaluation for software must include a systematic literature review, analysis of clinical data from studies or real-world evidence, and a clear demonstration that the software’s outputs lead to measurable benefit in the intended patient population. “The algorithm is accurate” is not sufficient. The evaluation must show that clinical accuracy translates to clinical benefit.
Cybersecurity
Cybersecurity is a GSPR requirement (Annex I, section 13.6) and is assessed as part of conformity. Requirements include: ensuring confidentiality, integrity, and availability of data throughout the lifecycle; defining minimum IT requirements and secure configurations; implementing and validating security controls; providing clear IFU guidance on data protection, updates, and decommissioning; and maintaining a post-market security plan that tracks vulnerabilities and manages patches. The MDCG 2019-16 guidance and the IMDRF cybersecurity framework are the primary references.
Technical Documentation (Annex II and III)
SaMD technical documentation must include software architecture documentation, the software development plan and lifecycle records, risk management file, usability engineering file (IEC 62366), verification and validation records, clinical evaluation report, and labelling. For AI-based SaMD, documentation of training data, model validation methodology, and performance across demographic subgroups is increasingly expected by Notified Bodies.
Conformity Assessment and CE Marking
For Class IIa and above, a Notified Body must review the QMS and technical documentation. Once conformity is demonstrated, the manufacturer issues a Declaration of Conformity and applies the CE mark. Post-CE marking, the technical documentation must be kept current and the Notified Body must conduct periodic surveillance audits.
Post-Market Surveillance and Software Updates
PMS for SaMD is not passive. Manufacturers must actively monitor real-world performance data, including clinical outcomes where available, algorithm performance metrics, user feedback, and incident reports. Critically, every software update must be assessed to determine whether it constitutes a significant change requiring re-assessment or Notified Body notification. Changes to the algorithm, training data, intended use, or clinical claims are most likely to trigger this requirement.
4. Common Pitfalls and How to Avoid Them
Underestimating classification. Many developers initially classify their software as Class I, expecting to self-certify, only to discover during technical documentation preparation that the intended purpose clearly falls under Rule 11 Class IIa or above. Classification should be confirmed with regulatory input before development begins, not after.
Clinical evidence left to the end. Clinical evidence for SaMD takes time prospective studies, real-world performance evaluations, and literature reviews cannot be conducted in parallel with Notified Body submission. Build the clinical evidence strategy into the development plan from the start.
Treating the QMS as a documentation exercise. Notified Bodies now conduct in-depth QMS audits that test whether processes are genuinely embedded in the organisation. A QMS that exists only in documentation will not survive an audit.
Ignoring post-market obligations. The MDR’s post-market surveillance requirements for software are active and ongoing. Failure to establish functioning PMS processes before launch is a common finding in post-certification audits.
5. SaMD Under IVDR
If the software is intended to process data from in vitro diagnostic tests for example, software that interprets NGS data for clinical decision-making, or a companion diagnostic algorithm — it may be regulated under IVDR (2017/746) rather than MDR. The classification rules differ (IVDR uses Annex VIII Rules 1–7), and the clinical evidence requirements under IVDR are in some ways more stringent, requiring performance evaluation under ISO 20916 and, for Class D IVD software, EMA consultation. Read more about NGS bioinformatics validation.
If your software sits at the boundary of MDR and IVDR, an early regulatory opinion is essential. Getting the regulatory framework wrong at the start can require complete rework of technical documentation.
Challenges, Risks & Strategic Recommendations for SaMD
| Challenge | Mitigation / Best Practice |
|---|---|
| Unclear intended purpose or software classification | Define the medical purpose at project initiation. Align IFU, labeling, marketing, and technical files with intended use and Rule 11 logic. |
| Insufficient clinical/performance evidence | Use prospective studies or robust real-world performance evaluations aligned with MDR Annex XIV and, where applicable, AI Act testing provisions. |
| Data quality and representativeness | Implement data governance for acquisition, preprocessing, and validation. Ensure datasets represent the intended patient population and use context. |
| Transparency and user comprehension | Provide clinically interpretable outputs. Explain functionality, limitations, and user responsibilities in the IFU and training materials. |
| Traceability gaps between requirements, risks, and tests | Maintain a requirements-to-verification traceability matrix that links requirements, risk controls, verification results, and clinical claims. |
| Software updates and regulatory impact | Establish change management to evaluate whether updates are significant and require re-assessment. Integrate these controls into the QMS. |
| Regulatory and Notified Body capacity constraints | Engage early with a qualified Notified Body. Provide clear, harmonized documentation to streamline assessments. |
| Evolving standards and regulatory guidance | Monitor new EU and MDCG guidance and standards (ISO 14971, ISO 13485, IEC 62304, IEC 81001-5-1) and the EU AI Act. Review QMS procedures periodically to stay aligned. |
Where to Start: step-by-step for SaMD Manufacturers
Delivering safe and compliant Software as a Medical Device (SaMD) requires a structured approach that integrates regulatory, technical, and quality considerations across the lifecycle. Compliance with the EU MDR ensures that safety, performance, and clinical benefit remain clear and consistently supported.
Advanced technologies, including AI, can enhance SaMD functionality; however, they should not overshadow the core principles of safety, effectiveness, and human oversight. The same regulatory rigor and lifecycle management practices apply to all SaMD, regardless of the underlying technology.
Manufacturers should:
- Define a clear intended purpose aligned with clinical benefit
- Maintain a QMS that addresses MDR and, where relevant, AI Act obligations
- Engage early with Notified Bodies and keep documentation, risk, and cybersecurity controls consistent
- Treat post-market surveillance and maintenance as continuous improvement
By embedding these principles, manufacturers can reach compliance efficiently and deliver trustworthy, clinically valuable SaMD solutions.
