Rule 11 of MDR Annex VIII is the single rule that pushes the most software up the risk ladder. For many manufacturers, it is the difference between a self-declared Class I product and a Class IIa, IIb or even Class III device that needs a Notified Body. This guide reads Rule 11 line by line, turns it into a decision tree, works through five real examples from Class I to Class III, and covers what the 2025 revision of MDCG 2019-11 changed. The aim is simple: let you reach a defensible class for your software without guessing.

First: Is Your Software Even a Medical Device?

Rule 11 only applies once your software qualifies as a medical device. Before classifying, confirm qualification under MDR Article 2(1): software has a medical purpose when it performs an action on data beyond storage, archival, communication or simple search — and that action is for the benefit of an individual patient (diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease). This is the central test in MDCG 2019-11, the European Commission’s guidance on the qualification and classification of software.

Two consequences follow immediately:

Document the intended purpose of each module separately. MDCG 2019-11 Rev.1 (2025) reinforces that a multi-module product is assessed module by module: a medical module inside an otherwise administrative platform pulls only that module into the device regime, provided the boundaries and dependencies are documented.

What Rule 11 Actually Says

Rule 11 has three parts. The first covers software for decisions; the second covers monitoring; the third is the catch-all. In plain language:

1. Software for diagnostic or therapeutic decisions

Software intended to provide information used to take decisions for diagnostic or therapeutic purposes is Class IIa by default. It escalates when the decision’s potential impact is more severe:

2. Software that monitors physiological processes

Software intended to monitor physiological processes is Class IIa, except where it monitors vital physiological parameters and the nature of their variation could result in immediate danger to the patient — in which case it is Class IIb. The same logic applies to software intended to control physiological processes.

3. All other software

Any software that is a medical device but does not fall into the decision-support or monitoring categories above is Class I.

The Rule 11 Decision Tree

Work through these questions in order. The first one that matches sets your class:

  1. Does the software provide information used for a diagnostic or therapeutic decision? If no, skip to step 4.
  2. What is the worst credible harm if that decision is wrong? Death or irreversible deterioration → Class III. Serious deterioration or a surgical intervention → Class IIb. Otherwise → Class IIa.
  3. Does it monitor or control physiological processes? Yes, and the parameters are vital with risk of immediate danger → Class IIb. Yes, but not vital/immediate → Class IIa.
  4. None of the above, but still a medical device? → Class I.

The pivot in step 2 is the phrase “worst credible harm.” Rule 11 classifies on the severity of the potential impact of the information, considered in the clinical context of use — not on how likely the error is. This is why so much decision-support software lands in IIa or higher (see the critique below).

Five Worked Examples

These follow the qualification test and the decision tree above. The exact class always depends on the documented intended purpose and the worst-case clinical harm — but these illustrate how the logic plays out in practice:

Software Class Why
Cytostatic (chemotherapy) dose calculator Class III Provides information driving a therapeutic decision where an error could cause death or irreversible deterioration. Worst credible harm sits at the top of the scale.
ICU patient data management system that supports therapy planning Class IIb / III Decision-support in a critical-care setting. Depending on the intended purpose, an erroneous output can lead to serious or irreversible harm, placing it in IIb or III.
Software diagnosing sleep apnea from recorded signals Class IIa Provides diagnostic information, so it leaves Class I, but a wrong result does not typically cause death, irreversible or serious deterioration on its own — the default IIa applies.
Software controlling an insulin pump (delivery of a vital parameter) Class IIb Controls a vital physiological parameter where the nature of variation can cause immediate danger to the patient — the monitoring/control sub-rule sets IIb. A fully closed-loop system that makes autonomous dosing decisions can be argued up to Class III.
Software that only stores and forwards images without interpreting them (MDDS) Class I No diagnostic or therapeutic interpretation, no monitoring of vital parameters. It falls into “all other software.” If it performs no medical action at all, it may not qualify as a device.

Why So Much Software Ends Up in Class IIa or Higher

A recurring criticism of Rule 11 — voiced by Notified Bodies, consultants and developers alike — is that it is severity-based, not risk-based. Classical risk management combines severity and probability. Rule 11 looks only at the severity of the potential impact: even an improbable catastrophic outcome can trigger Class III. The practical effect is that almost any software giving information for a clinical decision lands in Class IIa at minimum, dragging it into Notified Body assessment and a certified quality management system.

This hits small developers and startups hardest, because the step from Class I (self-declaration) to Class IIa (Notified Body, ISO 13485, clinical evaluation) is a large jump in cost and time. Two practical takeaways:

What Changed in MDCG 2019-11 Rev.1 (2025)

On 17 June 2025, the European Commission published MDCG 2019-11 Revision 1, the first update to the primary software qualification and classification guidance since 2019. It is now the version to cite. The changes are interpretive rather than structural, but several matter for Rule 11:

Rule 11 and the EU AI Act

If your software uses AI and is a medical device under Rule 11, you are likely in scope of both the MDR and the EU AI Act. Medical devices that are Class IIa or above under the MDR are generally treated as high-risk AI systems when they embed AI, meaning the two frameworks stack rather than replace each other. Plan the conformity work as one combined effort, not two sequential projects. We cover the overlap in detail in our guide to the EU AI Act for medical device and SaMD developers.

Find your device’s MDR class in minutes

Use our free MDR Classification Wizard to walk through all 22 Annex VIII rules — including Rule 11 for software — and get a defensible class with the reasoning behind it.

Open the Classification Wizard
Share this article:

Sources and further reading