Rule 11: Why Your Software Is Not IIa Just Because You Say So
I see it in every third submission. The manufacturer classifies their medical device software as IIa. The justification? A one-paragraph statement that the software ‘provides information’ rather than ‘drives or influences’ treatment. Then the Notified Body asks three questions, and the entire classification collapses. Because Rule 11 does not care what you call your software. It cares what your software actually does.
In This Article
Most software classification errors do not come from ignorance of Rule 11. They come from wishful thinking. From reading the rule as if it were negotiable. From assuming that softer language in the intended use will somehow lower the class.
It does not work that way.
Rule 11 determines your software class based on the clinical decision it supports. Not on how you phrase the intended use. Not on whether you add disclaimers. Not on whether the physician can override the output. The question is simple: what does the software enable the user to do that they could not do without it?
If the answer involves diagnosis or treatment decisions with serious consequences, you are looking at IIb. If it involves decisions with moderate consequences, you are looking at IIa. And if your software only stores, archives, or communicates data without interpretation, you stay at Class I.
The distance between these classes is not semantic. It is clinical. And that distinction drives everything downstream in your regulatory file.
What Rule 11 Actually Says
Rule 11 from Annex VIII of the MDR establishes three classification levels for software intended to provide information used to make decisions for diagnostic or therapeutic purposes.
Class IIa applies when the software is intended to provide information to support decisions with serious consequences. Class IIb applies when those consequences are potentially life-threatening or could result in irreversible deterioration of health. Class I applies when the software is only for storage, archival, communication, or simple search without clinical interpretation.
The wording matters. The rule does not say ‘could influence’ or ‘might support.’ It says ‘intended to provide information used to make decisions.’ If your intended use positions the software as a tool that informs clinical decisions, you are under Rule 11 scrutiny.
The classification is locked in by what the software is intended to do, not by how much autonomy the clinician retains. A physician can override any software recommendation. That does not lower the class. What matters is the role the software plays in the decision pathway.
This is where manufacturers stumble. They assume that if the doctor makes the final call, the software is merely informational. But that logic fails the moment your software generates a diagnostic suggestion, a risk score, a treatment recommendation, or a parameter that directly feeds into clinical action.
The IIa/IIb Boundary: Seriousness of Consequences
The line between IIa and IIb is not drawn by technology. It is drawn by clinical risk.
MDCG 2019-11 gives examples. Software that detects atrial fibrillation to guide anticoagulation decisions is IIb. Software that calculates fracture risk to inform osteoporosis treatment is IIa. Both support clinical decisions. Both involve diagnosis and treatment. The difference is the immediacy and severity of what happens if the software is wrong.
In practice, you assess this by asking: what could go wrong if the software output is incorrect or misleading? If the consequence is death, permanent disability, or a critical delay in life-saving treatment, you are at IIb. If the consequence is a suboptimal but reversible treatment choice, you are at IIa.
Manufacturers often classify software as IIa by pointing to secondary use cases or by emphasizing that the software ‘only assists’ the physician. But if the primary intended use involves diagnosing a life-threatening condition or guiding critical treatment, the class is IIb. The intended use must reflect the most serious application, not the safest one.
Notified Bodies evaluate this ruthlessly. They look at the clinical claims. They look at the validation studies. They look at the user instructions. If your software detects early signs of cancer, predicts stroke risk, or recommends insulin dosing, you will not get away with IIa just because you add a line that says ‘physician judgment is required.’
Physician judgment is always required. That is not a classification argument. That is a given.
Intended Use Is Not a Marketing Tool
The most dangerous misconception is that you can write your way into a lower class. That if you carefully word the intended use to avoid terms like ‘diagnose’ or ‘recommend,’ you can keep the software at IIa or even Class I.
This strategy fails at the first technical review.
Because the classification is not based on what you claim. It is based on what the software does. If your software outputs a probability score that clinicians use to decide whether to biopsy a lesion, that is a diagnostic decision. If your software generates a risk stratification that determines whether a patient gets admitted or discharged, that is a treatment decision.
You can call it ‘clinical decision support’ or ‘informational display’ or ‘advisory output.’ The Notified Body will still ask: what decision does this information support? What happens if the information is wrong? What is the clinical consequence?
And if your answer to those questions reveals serious or life-threatening risk, your class goes up. No matter how softly you worded the intended use.
The intended use must align with the clinical claims, the validation evidence, and the actual use cases described in your risk management file. If there is a mismatch, the Notified Body will elevate the class to match the highest risk scenario supported by the evidence.
This is not hypothetical. I have reviewed files where the intended use was carefully neutral, but the clinical evaluation included studies where the software was used to guide chemotherapy decisions. The manufacturer argued IIa. The Notified Body required IIb. Because the evidence showed life-threatening consequences.
The lesson is simple: do not classify based on what you wish the software did. Classify based on what it actually does in clinical practice.
The MDCG 2021-24 Clarifications
MDCG 2021-24 added further detail on software classification, particularly around diagnostic and therapeutic decision-making. It confirms that software does not need to directly control a device or deliver therapy to be Class IIb. It only needs to provide information that is used to make decisions with serious or life-threatening consequences.
This matters for software that analyzes imaging, predicts disease progression, or calculates treatment parameters. Even if the software does not administer the treatment, it is classified based on the decision it enables.
The guidance also clarifies that software used for screening in asymptomatic populations can be IIb if the condition being screened for is life-threatening and the screening result drives immediate clinical action. This applies to cancer detection algorithms, cardiac risk prediction tools, and infectious disease screening software.
Manufacturers often miss this because they think of screening as low-risk. But screening is only low-risk if a false result does not delay critical treatment. If your software screens for a condition where early detection is life-saving, and a false negative means missed treatment, you are at IIb.
Software manufacturers sometimes argue that because their tool is used in low-acuity settings, the class should be lower. But the setting does not determine the class. The clinical consequence does. A stroke risk calculator used in a GP office is still IIb if a wrong result delays anticoagulation therapy.
What This Means for Your Clinical Evaluation
Once your software is classified as IIa or IIb, your clinical evaluation requirements change fundamentally. A Class IIb software requires a much deeper body of clinical evidence, including post-market data that demonstrates safety and performance in real-world use.
You cannot justify a IIb classification with only analytical validation. You need clinical validation. You need evidence that the software performs correctly in the hands of the intended users, in the intended clinical environment, for the intended patient population.
This is where many submissions stall. The manufacturer realizes mid-process that the clinical data they have is not sufficient for the class they are in. They either have to generate new studies, which delays the submission by months, or they have to downgrade the intended use, which limits the commercial value of the product.
Both options are painful. But both are better than submitting a file that claims IIa when the evidence shows IIb. Because that file will not pass. It will come back with a major non-conformity, and you will lose more time than if you had classified correctly from the start.
Your classification decision should happen before you design your clinical evaluation plan. Not after. Because the class determines the evidence standard. And if you collect IIa-level evidence for a IIb device, you will have to start over.
How to Justify Your Classification
The classification rationale is a formal section in your technical documentation. It is not optional. It is not a checkbox. It is a reasoned argument that demonstrates you understand Rule 11 and have applied it correctly to your software.
Start with the intended use. State clearly what clinical decision the software supports. Then describe the consequences if the software output is incorrect. Be specific. Do not say ‘the patient might receive suboptimal care.’ Say ‘a false negative could delay cancer diagnosis by six months, reducing five-year survival by 20%.’
That level of specificity forces you to confront the real clinical risk. And it shows the Notified Body that you have thought through the classification seriously.
Next, reference the relevant examples from MDCG 2019-11 or MDCG 2021-24. Show that your device is analogous to a classified example, or explain why it differs. If your device is borderline between IIa and IIb, acknowledge that. Explain your reasoning. Show that you considered the higher class and made a deliberate choice.
Finally, align the classification with your risk management file. If your risk analysis identifies hazards that could result in death or serious injury, your class cannot be IIa. The classification and the risk analysis must tell the same story.
Many classification rationales are written defensively, as if the goal is to minimize the class. The goal is not to minimize. The goal is to classify correctly. A well-justified IIb classification is far stronger than a poorly justified IIa classification that collapses under scrutiny.
The Cost of Getting It Wrong
Misclassification is not a minor documentation error. It is a fundamental regulatory failure. If your device is classified too low, and the Notified Body catches it during review, your submission stops. You revise the classification, which means revising the clinical evaluation, the risk management file, and possibly the entire quality management system if you were not audited for the correct class.
If the misclassification is not caught until post-market, the consequences are worse. You could face enforcement action, market withdrawal, or a requirement to re-certify under the correct class with full clinical data.
And if harm occurs because the device was not evaluated to the correct standard, you face liability that no amount of retrospective justification will reduce.
This is not about being conservative. It is about being correct. Rule 11 is not ambiguous. The guidance is clear. The examples are available. The only question is whether you apply them honestly to your own device.
If your software influences clinical decisions with serious consequences, it is IIa. If those consequences are life-threatening, it is IIb. Everything else is detail.
Classification is the foundation of your regulatory strategy. Get it right first, and everything downstream becomes clearer. Get it wrong, and every document you build on top of it will eventually collapse.
In the next part of this series, we will look at how classification drives your clinical evaluation strategy, and why a Class IIb device cannot rely on equivalence the way a Class I device can. Because once you cross into IIb, the evidence standard changes completely.
Peace,
Hatem
Clinical Evaluation Expert for Medical Devices
Follow me for more insights and practical advice.
Frequently Asked Questions
What is a Clinical Evaluation Report (CER)?
A CER is a mandatory document under MDR 2017/745 that demonstrates the safety and performance of a medical device through systematic analysis of clinical data. It must be updated throughout the device lifecycle based on PMCF findings.
How often should the CER be updated?
The CER should be updated whenever significant new clinical data becomes available, after PMCF activities, when there are changes to the device or intended purpose, and at minimum during annual reviews as part of post-market surveillance.
What causes CER rejection by Notified Bodies?
Common reasons include inadequate equivalence demonstration, insufficient clinical data for claims, poorly structured SOTA analysis, missing gap analysis, and lack of clear benefit-risk determination. Structure and logical flow are as important as the data itself.
Which MDCG guidance documents are most relevant for clinical evaluation?
Key documents include MDCG 2020-5 (Equivalence), MDCG 2020-6 (Sufficient Clinical Evidence), MDCG 2020-13 (CEAR Template), MDCG 2020-7 (PMCF Plan), and MDCG 2020-8 (PMCF Evaluation Report). MDCG 2019-11, MDCG 2021-24
Need Expert Help with Your Clinical Evaluation?
Get personalized guidance on MDR compliance, CER writing, and Notified Body preparation.
✌
Peace, Hatem
Your Clinical Evaluation Partner
Follow me for more insights and practical advice.
– Regulation (EU) 2017/745 (MDR), Annex VIII, Rule 11
– MDCG 2019-11: Guidance on Qualification and Classification of Software
– MDCG 2021-24: Guidance on Classification of Medical Devices
Deepen Your Knowledge
Read Complete Guide to Clinical Evaluation under EU MDR for a comprehensive overview of clinical evaluation under EU MDR 2017/745.
