MDR Rule 11: Why Class I Barely Exists for Software

Rule 11, in Chapter III of Annex VIII to the MDR, is the classification rule that governs medical device software (MDSW). It is also the rule teams get wrong most often — not because it is technically complex, but because the self-classification memo usually starts from the wrong assumption. “Our software just displays information, it doesn't do anything” sounds like a Class I argument. Read against Rule 11's actual structure, it is almost never one.

What Rule 11 actually says

Rule 11 splits medical device software into two tracks. The first: software that drives a device or influences its use takes the same class as that device — a dosing algorithm embedded in an infusion pump is classified with the pump, not on its own scale. The second, and the one that generates most of the disputes: if the software is independent of any other device, it is classified in its own right, and the rule sets a default. Software intended to provide information used to make a diagnostic or therapeutic decision is Class IIa, unless a wrong decision could cause death or irreversible deterioration (Class III) or serious deterioration or a surgical intervention (Class IIb). A separate limb covers software that monitors physiological processes, defaulting to Class IIa and rising to IIb when it monitors vital parameters whose variation could create immediate danger. This structure is why teams evaluating software as a medical device need to work through the rule's actual limbs rather than reason from how the product feels to describe.

Why Class I self-classifications keep failing review

Once the decision-support limb and the monitoring limb are both read broadly — and the Commission's guidance instructs reading them broadly — the software left over for Class I is a narrow category: pure storage, archiving, straightforward search, or communication functions with no diagnostic, therapeutic, or monitoring role. A tool that surfaces lab trends for a clinician to interpret is not archiving; it is providing information used in a decision, which is the decision-support limb regardless of how the marketing copy describes it. Products used in clinical decision support are the pattern most likely to be mis-scoped this way, because the software's own developers often describe it as passive when a Notified Body will read the intended purpose as active.

• The “just displays information” framing. If a clinician acts on that information for diagnosis or treatment, the software is on the decision-support limb, not the residual one.
• Treating monitoring as automatically low-risk. Physiological monitoring defaults to Class IIa on its own, before any diagnostic claim is added.
• Writing one intended purpose for a multi-module product. MDCG 2019-11 Rev.1 expects modular software to be assessed module by module, so one low-risk module cannot carry a higher-risk one into an understated class.
• Confusing “drives” with “informs.” Software embedded in and controlling a device inherits that device's class; software a person reads and then acts on is classified independently under the decision-support or monitoring limb.

The question a self-classification memo has to answer is not whether the software feels passive. It is whether Rule 11's decision-support or monitoring limb applies — and for most clinical software, one of them does. Why the intended-purpose statement decides the class

What the June 2025 revision changed

MDCG 2019-11 Rev.1 did not rewrite Rule 11 — the Commission's guidance interprets the regulation, it does not amend it — but it sharpened the areas where classification memos most often go wrong: drafting an intended purpose with enough regulatory precision to show which limb applies, new worked examples including software intended for treatment purposes, and explicit treatment of modular MDSW, where a single product bundles components with different intended purposes and each module needs its own classification pass. The revision also addressed how the guidance interacts with the European Health Data Space framework as health-data-handling software becomes more common. None of this loosens the decision-support or monitoring limbs; if anything, the added examples make it harder to argue a borderline product into Class I.

None of this is a reason to over-classify defensively, either — genuine Class I software still exists, and treating every product as automatically IIa wastes conformity-assessment effort the rule does not require. The discipline is the same either direction: work through Rule 11's actual limbs against the specific intended purpose, not against how simple the interface looks. Teams building AI-enabled or adaptive software face a related version of this problem on the FDA side, where predetermined change control plans require the same precision about what the software actually does before regulators will accept a modification pathway. If your last classification memo leaned on “informational only” without testing it against both limbs, that memo is worth revisiting before a Notified Body does it for you — our EU MDR & IVDR team runs this walkthrough as a standard part of software conformity assessment prep.