Classifying Software Under MDR: Rule 11 Explained

Why software has its own classification rule

Hardware medical devices follow classification rules based on physical contact, invasiveness, and energy delivery. None of those map well to software. Rule 11 in Annex VIII was introduced specifically for software — it anchors classification to the severity of harm that could result if the software provides incorrect information or fails to work correctly.

This is the part that catches teams off guard: the classification isn't about what the software does when it works correctly. It's about what happens to a patient if it doesn't. That reframe changes how you approach the analysis.

How Rule 11 works

Rule 11 creates four possible outcomes. Work through the logic in order:

Class III — software intended to provide information used to make decisions with serious irreversible consequences. Think: software that tells a surgeon which tissue to resect, or software that drives an automated drug dosing decision in a high-acuity setting. If the wrong answer leads to death or irreversible serious harm, this is where you land.

Class IIb — software intended to provide information used to make decisions with serious but potentially reversible consequences, or decisions about a patient's condition. Examples: diagnostic software that detects a condition where delayed diagnosis causes serious harm, or clinical decision support for high-risk therapeutic choices. Most AI/ML diagnostic tools that inform clinical decision-making sit here.

Class IIa — software intended to provide information used to make decisions for therapeutic or diagnostic purposes where the potential harm is less severe. Also: software that monitors physiological processes in a way that is not time-critical. A lot of clinical analytics tools that support clinical decisions without being the sole or decisive input land here.

Class I — all other software. Software that doesn't influence clinical decisions about individual patients, or where the information it provides could not directly cause harm even if wrong. Administrative tools, scheduling, general wellness software that qualifies as a device.

Worked examples

What MDCG 2021-24 adds

MDCG 2021-24 is the practical reference document for Rule 11. It extends the analysis to AI and ML-based software, but its worked examples are useful for any SaMD classification. One particularly useful clarification: the document reinforces that "intended to provide information" is read broadly — it includes any output the software generates that a clinician uses, whether or not the software itself frames it as a recommendation.

One thing teams often get wrong: they try to argue their software into a lower class by saying "the clinician makes the final decision." MDCG 2021-24 is clear that the role of the clinician in the loop does not automatically reduce the classification. What matters is whether the software's output — if wrong — could contribute to harm. A radiologist who misses a finding because the AI told them it wasn't there is still a harm case, even though a human reviewed it.

The severity of harm question

When you're working out your class, you need to document your harm severity reasoning. Two questions to work through explicitly:

1. What is the worst-case wrong output? Not the most likely one — the worst plausible one. A false negative that a clinician acts on. An incorrect dosing calculation that is applied. An alert that doesn't fire when it should.

2. What happens to the patient as a result? Is the harm reversible or not? How severe is it? How quickly could it manifest? Does a clinical workflow check exist that would catch the error before harm occurs — and is that check reliable enough to affect classification?

Document this harm analysis. Your Notified Body will want to see it, and it directly feeds your ISO 14971 risk assessment anyway.

What your class means in practice

Class I software: you self-declare, no Notified Body involvement. Technical documentation still required, but the conformity route is straightforward.

Class IIa, IIb, and III: Notified Body involvement is mandatory. Class IIb and III bring more intensive scrutiny of your clinical evaluation and technical documentation. If your software sits at IIb or III, budget realistically for Notified Body engagement from early development — not just at the end.

Your classification isn't permanent. If you add functionality, change your intended purpose, or change how clinicians use the output, revisit Rule 11. The MDCG guidance is clear that significant changes trigger reclassification analysis.