Software as a medical device: MDR Rule 11 explained

Rule 11 of Annex VIII of Regulation (EU) 2017/745 (MDR) is one of the most impactful provisions of the new European framework. It moved almost all Software as a Medical Device (SaMD) into a higher class, with major consequences for costs, time to market and clinical obligations.

For medical software publishers, understanding Rule 11 in detail is not optional — it determines the economic viability of a project.

What is software as a medical device?

Before talking classification, you need to know whether software is a medical device within the meaning of the MDR. The definition in Article 2.1 applies: software is a medical device if it is intended by its manufacturer for a specific medical purpose in humans — diagnosis, prevention, monitoring, prediction, prognosis, treatment, alleviation of a disease, injury or disability.

MDCG 2019-11 is the reference guide that helps distinguish:

• SaMD — standalone software meeting the medical device definition
• SiMD — Software in a Medical Device, embedded software that drives a device but does not work alone (example: firmware of an infusion pump)
• Out-of-scope MDSW — purely administrative or management software (hospital ERP, appointment scheduling), wellness software (step counter) without a medical purpose

An app that calculates a BMI or reminds you to drink water is not a medical device. An app that proposes an insulin dose adjusted to a patient profile is a medical device.

The text of Rule 11

"Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause:

— 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 classified as class IIb.

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

All other software is classified as class I."

Decoded, this gives three sub-rules:

1. Software supporting diagnostic or therapeutic decisions → IIa by default, IIb or III depending on severity
2. Software monitoring physiological processes → IIa by default, IIb if vital and dangerous
3. All other software → class I

Changes compared with the former Directive 93/42/EEC

Under the directive, much software was in class I by applying the classic rules (active instrument, limited duration of use). Under the MDR, the majority moves to at least class IIa.

Immediate consequences:

• Mandatory notified body involvement (whereas in class I, self-declaration sufficed)
• Expanded technical documentation (Annex II)
• Formalised clinical evaluation with PMCF by default
• PSUR to be produced periodically
• SSCP mandatory for implantable class III — therefore rare for pure software
• Cost and time to market: an additional 12 to 24 months, €50k to €200k in notified body fees

How to classify concretely?

MDCG 2019-11 proposes a structured decision tree. Here are the main steps:

Step 1 — Is the software a medical device?

If not, it is out of MDR scope.

Step 2 — Does the software provide information used for a therapeutic or diagnostic decision?

If yes, you enter the first branch of Rule 11.

If no, you check whether it monitors physiological processes. If still no, it is class I.

Step 3 — Assess the severity of the impact

For decision-support software, two crossed criteria:

Criterion A — Clinical situation: severity of the health condition.

Criterion B — Impact of the information provided: major decision (surgery, risky treatment) or decision with a margin for correction?

Situation severity \ Info impact	Information driving a major decision (direct cause)	Contributing information
Critical (risk of death / irreversible deterioration)	III	IIb
Serious (surgical intervention, serious deterioration)	IIb	IIa
Non-serious	IIa	IIa

Step 4 — Software monitoring physiological processes

• Non-vital processes: IIa
• Vital, non-dangerous processes: IIa
• Vital processes whose variations are dangerous: IIb

Concrete classification examples

Class IIa — examples

• Radiotherapy planning software for cancers with a favourable prognosis
• Decision-support software for monitoring adherence to a chronic treatment
• Dermatological image analysis software for triaging suspicious cases (unconfirmed suspicion)
• Non-vital medication dose calculation software

Class IIb — examples

• Oncology diagnostic support software on biopsies (the decision directly guides treatment)
• Continuous respiratory parameter monitoring software (vital process, alert on deviation)
• Stroke pre-diagnosis software on brain imaging (the decision conditions thrombolysis)

Class III — examples

• Cardiac surgery planning software where an error can be fatal
• Imaging analysis software intended to detect very aggressive cancers where a false negative is fatal
• Standalone closed-loop insulin pump control software for diabetic patients

Special cases

Modules of a single software product

If software comprises independent modules with different purposes, each module is classified separately. The overall class is that of the highest module. But a non-device module may be out of scope.

Update vs new version

An update that changes the intended purpose or clinical performance may be a substantial modification requiring a new assessment by the notified body. MDCG 2020-3 details what constitutes a substantial modification.

Machine learning algorithms

Software incorporating machine learning must be handled according to MDCG 2019-11 but also according to the emerging principles of the AI Act (Regulation (EU) 2024/1689). Software that updates itself automatically after placing on the market raises specific questions (locked vs continuous learning) — see the MDCG 2025-XX guidance currently being drafted.

Implications for developers

Standards to know

• IEC 62304 — life cycle of software embedded in medical devices (classes A/B/C by risk)
• IEC 82304-1 — software as a medical device (SaMD), general requirements for safety
• IEC 62366-1 — usability engineering and human factors
• EN ISO 14971 — risk management
• EN ISO 13485 — quality system
• AAMI TIR45 / TIR57 — guidance on agile methods and cybersecurity

Cybersecurity

The MDR (Annex I 17.2) and the MDCG 2019-16 guidance require a structured cybersecurity approach: threat analysis, vulnerability management, security updates, communication with users. Regulation (EU) 2024/2847 (Cyber Resilience Act) strengthens these requirements for products with digital components.

Clinical evaluation of a SaMD

The principles of MDCG 2020-1 apply: you demonstrate scientific validity (the algorithm measures what it claims to measure), analytical performance (precision, recall, specificity), and clinical performance (impact on the medical decision and the clinical outcome).

Practical advice for publishers

1. Classify as early as possible — the classification determines the project architecture, budget and timeline
2. Document the classification assumptions — a file explaining why the software is IIa and not IIb will be challenged in audit
3. Anticipate PMCF — plan post-market data collection from the development stage (logs, performance indicators, user feedback)
4. Build a robust quality life cycle from the start — retrofitting an architecture that does not comply with IEC 62304 is very costly
5. Ensure consistency with the AI Act if the software uses AI — the AI Act classification stacks on top of the MDR classification

Conclusion

Rule 11 of the MDR reshaped the medical software market in Europe. Many small publishers disappeared, unable to absorb notified body costs. For those that remain, mastery of Rule 11 — and more broadly of the IEC 62304, ISO 14971, MDCG 2019-11 chain — is a clear competitive advantage.

MedQara follows developments in Common Specifications, MDCG notes and notified body decisions relating to medical software. This is a field where regulation evolves quarter by quarter.

Also read: Understanding the MDR 2017/745 · How to prepare for an ISO 13485 audit · QARA glossary