MDR Rule 11: why your app is probably Class IIa

Under the pre-MDR directives, most medical software sat in Class I: self-certification, no notified body, fast market access. Rule 11 of the MDR closed that door. If you develop a SaMD (Software as a Medical Device) intended for the European market, assume you are in Class IIa — then check whether you are the exception. Here is why.

What exactly does Rule 11 say?

Definition: Rule 11 (Annex VIII, MDR 2017/745) classifies any software intended to provide information used to make decisions for diagnostic or therapeutic purposes as at least Class IIa. The text then provides for two escalations:

• Class III if those decisions may cause death or an irreversible deterioration of health;
• Class IIb if they may cause a serious deterioration of health or a surgical intervention.

A second part, often forgotten: software intended to monitor physiological processes is Class IIa, and moves up to IIb if the monitored parameters are vital and their variations could result in immediate danger to the patient. All other medical device software is Class I.

How do you work through the decision tree?

Three questions, in order:

1. Does my software provide information used for a diagnostic or therapeutic decision? Risk score, diagnostic support, dosing recommendation, patient triage, clinical alert threshold: yes. If so → at least Class IIa.
2. What is the potential severity of an erroneous decision based on that information? Death or irreversible deterioration → Class III. Serious deterioration or surgery → Class IIb. Otherwise → Class IIa.
3. Failing that, does my software monitor physiological processes? Yes → Class IIa; vital parameters with immediate danger → IIb.

Why does almost all SaMD fall into IIa at minimum?

Because the notion of “information used to make decisions” is interpreted broadly. The MDCG 2019-11 guidance is explicit: as soon as software has a medical purpose of its own — whether it calculates, filters, interprets or ranks data for a clinical use — it provides this type of information. Is the clinician still in the loop? It doesn’t matter: the text does not speak of automated decisions, but of information used to decide.

If your software influenced no clinical decision, no one would pay for it. It is precisely that value which classifies it.

Simple commercial reasoning is often enough: your pitch deck claims the product “improves care” or “supports diagnosis”. It is then hard to argue before a notified body that the information provided is not used for diagnostic or therapeutic purposes.

MDCG 2019-11 also clarifies the boundary of qualification: software that merely stores, archives, communicates or performs a simple search without interpretation is not a medical device at all. But between “not a MD” and “MD Class IIa”, the Class I zone has become narrow.

Is Class I still possible?

Rarely, but yes. Plausible examples: software with a medical purpose that provides no information for diagnostic or therapeutic decisions and does not monitor a physiological process — for instance certain rehabilitation-tracking apps without clinical interpretation, or planning tools with no diagnostic impact. In practice, every Class I case must be solidly argued against Rule 11 and MDCG 2019-11, because it is the first point the competent authority will challenge. My field experience: most files that reach me as “self-declared Class I” leave as IIa after analysis.

What are the practical consequences once in IIa?

Moving from I to IIa changes the nature of the project:

• Notified body mandatory: audit of your QMS and review of the technical documentation. Expect often long engagement lead times — contact one early.
• Full ISO 13485 QMS: not an option, a prerequisite to the audit.
• Technical documentation compliant with Annexes II and III of the MDR: clinical evaluation, ISO 14971 risk management, post-market surveillance.
• IEC 62304 with a justified safety class: for software whose failures could lead to an erroneous clinical decision, Class B is a realistic floor; Class C is debatable depending on severity. Class A becomes hard to defend for a IIa SaMD.
• Cybersecurity: requirements 17.2/17.4 of Annex I, in practice IEC 81001-5-1.

Budget and timeline: for a first IIa certification, plan a horizon in quarters, not weeks, between the QMS upgrade, compiling the file and the notified body’s lead times.

On compiling that file — its structure and the pitfalls that stall an audit — see: the MDR technical documentation for software.

And the IIb / III cases?

Move up a notch as soon as the decision fed by your software could cause serious deterioration (IIb): for example an algorithm suggesting doses of a narrow-therapeutic-margin drug, or patient triage where a false negative delays urgent care. Class III targets decisions with potentially fatal or irreversible consequences — typically certain decision-support software in oncology or interventional cardiology. Classification is always justified by the worst reasonably foreseeable scenario tied to the claimed use, not by the nominal case.

FAQ

My software has a healthcare professional in the loop: does that downgrade it?

No. Rule 11 targets the information used to decide, not the automation of the decision. The presence of a clinician may reduce the risk in the ISO 14971 sense, but does not change the class.

Can I restrict my intended use to stay in Class I?

It is possible in theory, but the intended use must reflect the real use and your commercial communication. Restricting the label while selling decision support is the shortest path to a nonconformity — and to reclassification by the competent authority.

Does a wellness app escape the MDR?

If it has no medical purpose within the meaning of Article 2 of the MDR, it is not a medical device and Rule 11 does not apply. But as soon as you claim a benefit on a pathology, a diagnosis or a treatment, you shift into qualification — and Rule 11 is waiting for you.