EU MDR Rule 11: how to classify your software as a medical device

The most important decision in your entire regulatory journey

Before a single page of technical documentation is written, before an ISO 13485 QMS is implemented, before a Notified Body is selected — the first regulatory decision is: what is my device class? Under EU MDR, software classification under Rule 11 determines everything that follows: whether you need a Notified Body, what conformity assessment route you must use, how rigorous your clinical evaluation must be, and what post-market obligations apply.

Misclassification is far more common than the industry acknowledges. We have seen software teams declare Class I self-certification for products that clearly fall into Class IIa under Rule 11 scrutiny — and discover the error when a Notified Body review reveals the mismatch. We have also seen teams over-classify in the other direction, spending years building Class IIb documentation for what is genuinely a Class IIa device. Both errors are costly.

Understanding Rule 11: the full text, explained

EU MDR Annex VIII Rule 11 states that software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes shall be:

• Class III if those decisions have an impact on the life of a patient or have a serious impact on a patient's health
• Class IIb if those decisions have an impact liable to cause serious deterioration of a person's state of health or a surgical intervention
• Class IIa in all other cases

All other software intended to monitor physiological processes is:

• Class IIa if intended to monitor vital physiological parameters where changes could result in immediate danger to the patient
• Class I in all other cases

Rule 11 also specifies that software intended for any other purpose not covered above (storage, archiving, communication, search functions, or simple search) is Class I.

Applying Rule 11 in practice: worked examples

AI diagnostic imaging software (ophthalmology)

Intended use: "Automated analysis of retinal photographs to assist ophthalmologists in identifying findings consistent with diabetic retinopathy for diagnostic review."

Classification analysis: This software provides information (algorithmic assessment of retinal images) used to take decisions with diagnostic purposes (identification of diabetic retinopathy). The condition is serious (diabetic retinopathy leading to blindness is a serious deterioration of health). The physician makes the final diagnosis, so the software is "assisting" not "deciding" — this is a nuanced but important distinction that places it at IIa or IIb depending on how the intended use is worded and the clinical workflow is designed.

Classification: Class IIa (with strong arguments for Class IIb if the software output directly drives treatment decisions without independent physician review).

Clinical decision support — antibiotic stewardship

Intended use: "Recommends antibiotic selection and dosing for hospital patients based on patient data, microbiology results, and local resistance patterns, for physician review and approval."

Classification analysis: This software provides information (antibiotic recommendations) used to take decisions with therapeutic purposes (antibiotic prescribing). Incorrect antibiotic selection or dosing can cause serious deterioration of health. Even though a physician approves the recommendation, the software's output is the primary driver of the therapeutic decision.

Classification: Class IIb.

Remote patient monitoring — post-operative vital signs

Intended use: "Continuous monitoring of heart rate, oxygen saturation, and respiratory rate in post-operative patients, with alerts for values outside predefined clinical thresholds."

Classification analysis: This is monitoring software for vital physiological parameters. Changes in the monitored parameters (post-operative deterioration, hypoxia) could result in immediate danger to the patient. Class IIa monitoring rule applies.

Classification: Class IIa.

The December 2025 simplification proposal — Rule 11 amendments

The European Commission's December 2025 proposal to simplify MDR/IVDR includes an amendment to Rule 11 that would allow a broader range of MDSW to fall under Class I classification, reducing the number of products requiring Notified Body assessment. This amendment could significantly impact SaMD certification economics if adopted.

However, the proposal is at the very beginning of the EU legislative process. It requires approval from the European Parliament and the Council, and will likely be subject to significant amendments. A realistic estimate for the amended Rule 11 taking effect is 2027 at the earliest, and it could be significantly later depending on political dynamics.

Writing a defensible classification justification

Your classification is not a decision you make once and forget — it is a documented position that must be justified in your technical file and that Notified Bodies will scrutinise. A weak or unsupported classification justification generates NB queries at the beginning of your review. Here is what a robust Rule 11 classification document includes:

• Intended use statement: Specific, precise, unambiguous. Defines the medical purpose, patient population, intended users, and clinical context.
• Qualification analysis: Why the software qualifies as an MDSW under EU MDR, referencing MDCG 2019-11.
• Rule 11 analysis: Which limb of Rule 11 applies, and why. Explicit reasoning for the chosen class — not just a statement of the class.
• Consideration of other rules: Confirmation that no other implementing rules or implementing measures would result in a higher classification.
• Device combinations: If your software is intended to work with hardware, classification may be elevated to match the hardware class.