Rule 11: Why Your Software Is Probably Class IIa – and What That Means

EU MDR 2017/745 · Annex VIII Rule 11 · MDCG 2019-11

The two previous articles covered the big picture: why the MDR came about and what it means for start-ups. Now we get specific. We look at the single rule that has disrupted more HealthTech business models than any other provision of the past decade: Rule 11 in Annex VIII of Regulation (EU) 2017/745.

Anyone developing software that works with health data in the broadest sense cannot avoid this rule. And most end up in a higher class than they had hoped.

1. The Text – and What It Actually Says

Rule 11 reads as follows:

• death or an irreversible deterioration of a person's state of health, in which case it is in Class III, or
• a serious deterioration of a person's state of health or a surgical intervention, in which case it is in Class IIb.

Software intended to monitor physiological processes is classified as Class IIa, unless it is intended for monitoring of vital physiological parameters, where the nature of variations in those parameters is such that it could result in immediate danger to the patient, in which case it is in Class IIb.

All other software is classified as Class I.

Three things stand out:

1. The default for decision-supporting software is IIa – not I.
2. Class I is the exception, not the rule.
3. The threshold for IIb/III is tied to potential harm, not probability.

That last point is crucial. It is not about how often something goes wrong – it is about how severe the consequences can be when it does.

2. What "Medical Device Software" Actually Means

Before Rule 11 is even applicable, software must qualify as a medical device within the meaning of Art. 2(1) MDR. The guidance document MDCG 2019-11 ("Guidance on Qualification and Classification of Software") assists with this preliminary assessment.

Software is a medical device if it has a medical intended purpose – for example:

• Diagnosis, prevention, monitoring, prediction, prognosis or treatment of a disease
• Compensation of an injury or disability
• Obtaining information about physiological processes

The following are typically not considered medical devices:

• Pure data storage without processing or interpretation
• Communication platforms (e.g. doctor-patient messengers without medical logic)
• Billing and administrative software
• Lifestyle apps without a medical claim ("wellness tracker")

The boundary is blurry. An app that "merely displays" sleep data is not medical device software. The moment it says: "Your values suggest sleep apnea, please consult a doctor," it very likely falls within the MDR world.

3. The Four Typical Categories in Practice

The following classifications are typical interpretations – the final assessment always depends on the specific claim.

Almost everything that actively interprets health data ends up in IIa or higher. That was the explicit intent of the legislator – and the answer to years in which apps with clinical significance passed through as Class I.

4. The Jump from Class I to IIa – Operationally Speaking

For many manufacturers who were Class I under the MDD and land in IIa under the MDR, this is not a gradual transition but a paradigm shift.

Class I (the MDD world for many software products):

• Declaration of conformity by the manufacturer itself
• No Notified Body required
• Comparatively lean technical documentation
• Market entry possible within weeks

Class IIa (MDR reality):

• Involvement of a Notified Body mandatory
• Complete QMS per ISO 13485, audited by the Notified Body
• Clinical evaluation per Annex XIV with robust evidence
• Post-Market Clinical Follow-up (PMCF) as an ongoing obligation
• Periodic Safety Update Report (PSUR) every 2 years
• Realistic time to market: 12–24 months from application to the Notified Body

The cost difference between these two worlds is – very roughly – a factor of 10 to 20. Not because the Class IIa requirements are disproportionate, but because the Class I requirements are comparatively minimal.

5. The Underestimated Standards Behind Rule 11

Anyone landing in IIa or higher is not only working with the MDR but with an entire stack of harmonised and recognised standards:

• IEC 62304 – Software lifecycle processes. Establishes safety classes A, B, C (independent of the MDR class!) and prescribes specific development and maintenance processes.
• ISO 14971 – Risk management. Every potential harm must be identified, assessed and controlled.
• IEC 62366-1 – Usability engineering. Usability is not optional – it is a regulated obligation.
• IEC 82304-1 – Health software in general. Particularly relevant for standalone software.
• ISO 13485 – Quality management system.
• ISO/IEC 27001 or IEC 81001-5-1 – Information security and cybersecurity for medical software.

A common mistake: these standards are worked through sequentially. That does not work. They interlock – risk management (14971) feeds software architecture (62304), which in turn influences usability engineering (62366-1), all embedded in the QMS (13485). Anyone who does not build this as an integrated system produces inconsistent documentation – and that is immediately apparent at audit.

6. Where Rule 11 Leaves Room – and Where It Does Not

There is room at the level of the intended purpose. Classification is directly tied to the wording of your claims. An example:

• "Our software diagnoses atrial fibrillation." → Class IIa, possibly IIb
• "Our software informs the physician about conspicuous ECG patterns for further medical assessment." → still medical device software, but often classifiable at a lower level
• "Our app is a wellness tracker for general fitness." → potentially not a medical device at all

This is not linguistic acrobatics – it is regulatory strategy. The claim defines the purpose. The purpose defines the class. The class defines costs and timelines.

There is no room when it comes to reality. Whoever internally clearly builds diagnostic software and markets it externally as an "information tool" will be caught at the first unannounced audit – or worse: at an incident involving a regulatory investigation.

7. What to Do Now – A Structured Starting Point

If you are developing software today that may fall within the scope of the MDR, the following sequence is recommended:

1. Clarify qualification: Is the software a medical device at all? Work through MDCG 2019-11.
2. Formulate the intended purpose precisely: What exactly does the software do, for whom, in what context?
3. Carry out classification: Apply the rules from Annex VIII systematically – not only Rule 11.
4. Document the result: A traceable justification for each rule. This is mandatory, not optional.
5. Plan the consequences: Time, budget, resources, Notified Body, QMS, clinical evidence.
6. Create a regulatory roadmap: Concrete milestones through to CE marking.

Structured support pays off especially at steps 3 and 4. A sound classification is not a by-product – it is the document that carries your entire regulatory project.

Conclusion: Rule 11 Is Not an Obstacle – It Is a Design Specification

Rule 11 forces software manufacturers to think precisely about their own product: What does it really do? Which decisions does it influence? What would the consequences of a failure be?

These questions are not only regulatory sound – they are strategically valuable for the product. A company that has cleanly answered Rule 11 understands its own product better. And ultimately builds better software.

The alternative – software with a diffuse intended purpose and an optimistic self-classification – is no longer a viable model today. Not in the EU, not in Switzerland, and increasingly not in neighbouring markets such as the UK.

The good news: anyone who applies Rule 11 early and honestly has a clear path ahead. With plannable costs, realistic timelines – and a product that is regulatory sound before the first user ever touches it.

The next article looks at the role that is most often neglected in start-ups – until it is too late: the Person Responsible for Regulatory Compliance (PRRC) under Article 15 MDR.