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, whose revision 1 was published in June 2025, 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 (summary of safety and clinical performance, Article 32) for class III and implantable devices: class III software is subject to it
• Markedly higher cost and time to market, because of the notified body assessment

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

• Monitoring physiological processes: IIa
• Monitoring vital physiological parameters whose variations could result in immediate danger to the patient: IIb

Software that drives a device or influences its use falls within the same class as that device (Annex VIII, implementing rule 3.3).

Concrete classification examples

These examples illustrate the reasoning; the actual class always depends on the intended purpose declared by the manufacturer.

Class IIa — examples

• An app that analyses a user's heartbeat, detects abnormalities and informs the physician
• Skin lesion triage software whose every result is reviewed by a dermatologist, in a non-critical situation
• Software monitoring physiological parameters outside critical care

Class IIb — examples

• Software monitoring vital parameters in critical care, where their variations could result in immediate danger
• Software whose output is the basis on which a specialist chooses a cognitive therapy
• Diagnostic support software whose error could lead to surgical intervention or serious deterioration

Class III — examples

• Image analysis software on which treatment decisions for acute stroke are based
• Software that ranks the available chemotherapy options for a BRCA-positive patient
• More generally, any software whose wrong decision could cause death or irreversible deterioration

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. Such a change must be reported to the notified body, which decides whether a new assessment is needed. For software still covered by a certificate issued under the Directive, MDCG 2020-3 specifies which changes are "significant" and end the benefit of the transition period.

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) — MDCG 2025-6, published in June 2025, addresses the interplay between the MDR, the IVDR and the AI Act.

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. The Cyber Resilience Act (Regulation (EU) 2024/2847), for its part, excludes devices covered by the MDR and the IVDR from its scope: the cybersecurity of medical device software remains governed by MDR Annex I and MDCG 2019-16.

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. For small publishers, mandatory notified body involvement profoundly changed the economics. 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