How is software classified as a medical device under MDR Rule 11?

Software is classified as a medical device under Rule 11 of Annex VIII of the Medical Device Regulation (EU) 2017/745 ("MDR"). The short answer: software that provides information used to take decisions for diagnosis or therapeutic purposes is Class IIa by default, moves up to Class IIb when a wrong or delayed decision could cause serious deterioration of health or a surgical intervention, and reaches Class III when it could cause death or an irreversible deterioration of health. Software that monitors vital physiological parameters is Class IIb where a variation could result in immediate danger. All other software is Class I. First, though, the software has to be a medical device at all.

Step 1 — is the software a medical device?

Before Rule 11 ever applies, the software must meet the definition of a "medical device" in Article 2 of the MDR. A device is any article — software is named explicitly — intended by its manufacturer for a medical purpose: diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease, among others. The intended purpose is what counts, not the technology.

This is where most products are decided. A fitness tracker that counts steps, a hospital scheduling tool, or a general-purpose spreadsheet has no medical purpose and is not a device. Software that calculates a drug dose, flags a suspicious lesion on a scan, or interprets ECG data to support a diagnosis does have a medical purpose — it is Software as a Medical Device (SaMD) and must be classified and CE-marked. The European Commission's MDCG 2019-11 guidance on the qualification and classification of medical device software (MDSW) walks through this qualification question with worked examples, and was revised in 2025 to cover AI-based software and modular architectures.

Step 2 — apply Rule 11

Once qualified, almost all standalone medical-device software lands under Rule 11. The rule is built around the consequence of the information the software produces:

• Decision-driving software → Class IIa. Software intended to provide information used to take decisions with a diagnosis or therapeutic purpose starts at Class IIa.
• → Class III if those decisions may cause death or an irreversible deterioration of a person's state of health.
• → Class IIb if those decisions may cause a serious deterioration of health or a surgical intervention.
• Monitoring vital parameters → Class IIb. Software intended to monitor physiological processes is Class IIa, except where it monitors vital physiological parameters and a variation could result in immediate danger, in which case it is Class IIb.
• All other software → Class I. Anything that is a device but does not drive diagnostic or therapeutic decisions — and does not monitor vital parameters — defaults to Class I.

Class matters because it sets the conformity-assessment route. Class I software can in most cases be self-declared by the manufacturer; Class IIa and above require a notified body — an independent organisation, identified by a four-digit number — to assess conformity and issue the certificate that lets the device be lawfully placed on the EU market. Note the framing: the notified body issues the certificate; EUDAMED only records it. There is no such thing as an "EUDAMED-issued" approval.

What MD Atlas data shows about SaMD

EUDAMED has no single top-level "software" node — software is scattered across the EMDN nomenclature wherever a device family happens to be digital. The cleanest citable proxy is the dedicated MDSW leaf, EMDN category V92, "Medical Device Software – not included in other classes." As of June 2026, MD Atlas indexes 1,143 devices carrying that V92 code. You can reproduce the figure directly: every device tagged EMDN V92.

Treat that number as a floor, not a census. It is an indexed subset of the public EUDAMED records — and because software is spread across many EMDN branches, the V92 leaf captures only the devices manufacturers explicitly filed under the dedicated software category. It is the most defensible single proxy, not the total population of regulated SaMD on the EU market.

To go wider, it helps to combine filters. You can browse the full device dataset by risk class and country, or start from the companies behind the software by listing registered manufacturers. Cross- referencing the manufacturer, the risk class and the EMDN category is exactly the kind of question the public EUDAMED interface makes slow and MD Atlas makes instant.

Common pitfalls

• Assuming "low risk" means Class I. Rule 11 deliberately pushes most decision-supporting software to Class IIa or higher. The default for genuine SaMD is not Class I.
• Confusing the registry with the certifier. Certificates are issued by notified bodies under MDR Annex XII and merely recorded in EUDAMED. The registry registers, records and publishes — it does not approve.
• Reading the EMDN count as the market size. The 1,143 V92 devices are a subset and a proxy; real SaMD coverage is wider and harder to bound.

Where to verify

For the authoritative classification rules, read Annex VIII, Rule 11 of Regulation (EU) 2017/745 directly, and use MDCG 2019-11 for the qualification and worked classification examples. To see how individual SaMD products are registered, the European Commission's EUDAMED portal remains the reference; MD Atlas makes the same public records searchable at scale.