Software as a Medical Device (SaMD) Under EU MDR: A 2026 Guide

"Is my app a medical device?" is the single most consequential question a health software team will answer. Get it right and you build the correct evidence from the start. Get it wrong and you either over-engineer a wellness app or, far worse, ship a regulated product without a CE mark. This guide walks the qualification and classification path under the EU Medical Device Regulation (MDR) and the standards that turn it into an executable plan.

Step 1 — Is your software a medical device at all?

Software is a medical device when it has a medical purpose in its own right: diagnosis, prevention, monitoring, prediction, prognosis, or treatment of a disease or condition. The MDCG 2019-11 guidance is the reference for this "qualification" decision. Software that merely stores, archives, communicates, or performs simple search — or that supports general wellbeing without a medical claim — usually falls outside. The dividing line is your intended purpose, so write it precisely: it drives everything downstream.

Step 2 — Classify with Rule 11

Once you are a medical device, MDR Rule 11 sets the risk class for software that provides information used in decisions or that monitors physiological processes. In practice:

• Class IIa — most decision-support software providing information used for diagnostic or therapeutic decisions.
• Class IIb — where decisions could cause serious deterioration of health or require surgical intervention.
• Class III — where a wrong output could cause death or irreversible deterioration.
• Class I — a small remainder, e.g. software not driving clinical decisions.

The headline reality: Rule 11 pushes nearly all clinical SaMD to Class IIa or above, which means a notified body must be involved in your conformity assessment. Plan for that early — notified-body capacity and timelines are the most common cause of launch slippage.

Step 3 — The standards that make it real

Regulation tells you what; harmonised standards tell you how. The working set for medical software:

• ISO 13485 — your quality management system (QMS). The backbone everything else hangs from.
• ISO 14971 — risk management across the full lifecycle.
• IEC 62304 — the software development lifecycle: planning, architecture, units, integration, and maintenance, scaled by software safety class (A/B/C).
• IEC 62366-1 — usability engineering, because use error is a genuine patient-safety risk.
• IEC 81001-5-1 — cybersecurity across the software lifecycle, which also satisfies MDR security requirements.

Step 4 — Clinical evaluation

You must show the software works and benefits patients. A clinical evaluation for SaMD combines 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 a measurable benefit in the intended population. For AI-driven products this is also where you evidence accuracy, precision, and the stability of your algorithms through verification and validation.

Step 5 — The CE marking pathway

Putting it together, the route to market looks like this:

1. Define intended purpose and confirm qualification as SaMD.
2. Classify under Rule 11 and pick the conformity assessment route.
3. Stand up your ISO 13485 QMS.
4. Run IEC 62304 development with ISO 14971 risk management woven through it.
5. Compile technical documentation (Annexes II/III) and the clinical evaluation.
6. Undergo notified-body assessment (for Class IIa and above).
7. Draw up the Declaration of Conformity, affix the CE mark, and register in EUDAMED.
8. Operate post-market surveillance and a vigilance process.

Frequently asked questions

What makes software a medical device? A medical purpose of its own — diagnosis, monitoring, prediction, prognosis, or treatment. Pure storage, communication, or general-wellness tools usually are not devices.

What class is most SaMD? Under Rule 11, most clinical SaMD is Class IIa or higher, so a notified body is required. Class III applies where an error could cause death or irreversible harm.

Which standards apply? ISO 13485 (QMS), ISO 14971 (risk), and IEC 62304 (software lifecycle), plus IEC 62366-1 (usability) and IEC 81001-5-1 (cybersecurity).

Neurova AI builds custom medical software the compliant way — IEC 62304 lifecycle, risk management, and documentation built in, not bolted on. Continue with our guides to the EU AI Act, the European Health Data Space, and what custom medical software costs.