---
title: How to Apply MDR Classification Rule 11: Software as a Medical Device
description: MDR Annex VIII Rule 11 classifies most medical device software as Class IIa or higher. Here is how to apply Rule 11 correctly and when Class IIb or III applies.
authors: Tibor Zechmeister, Felix Lenhard
category: Device Classification & Conformity
primary_keyword: MDR Rule 11 software classification
canonical_url: https://zechmeister-solutions.com/en/blog/mdr-classification-rule-11-software
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# How to Apply MDR Classification Rule 11: Software as a Medical Device

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **MDR Annex VIII Rule 11 classifies medical device software by the consequence of the decisions it supports. Software intended to provide information used for diagnostic or therapeutic decisions is Class IIa by default, Class IIb if the decisions could cause serious deterioration of health or surgical intervention, and Class III if they could cause death or irreversible deterioration. Software intended to monitor physiological processes is Class IIa, or Class IIb if it monitors vital physiological parameters where variations could result in immediate danger. All other software is Class I — but that bucket is narrower than most founders hope, and getting to it requires an intended purpose that genuinely does not inform clinical decisions.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- MDR Rule 11 lives in Annex VIII of Regulation (EU) 2017/745 and governs the classification of medical device software (MDSW) that has qualified as a medical device under Article 2(1).
- Rule 11 has two decision branches: software that provides information used for diagnostic or therapeutic decisions, and software that monitors physiological processes. A catch-all third branch sends "all other software" to Class I.
- The decision-making branch starts at Class IIa and escalates to IIb or III based on the severity of the clinical consequence if the information is wrong.
- The monitoring branch starts at Class IIa and escalates to IIb when the parameters are vital and variations could cause immediate danger.
- Under the former MDD, most medical software fell into Class I. Under MDR Rule 11, most of that same software is Class IIa or higher. This is the up-classification reality and it is the single biggest regulatory change for SaMD companies.
- MDCG 2019-11 Rev.1 (June 2025) is the definitive guidance and contains worked examples across multiple clinical domains. Read it in full before finalising any Rule 11 argument.
- Rule 11 is not the software lifecycle standard. EN 62304:2006+A1:2015 handles the lifecycle, EN ISO 14971:2019+A11:2021 handles the risk management, and Rule 11 handles the device class under MDR. You need all three, consistently.

---

## Why Rule 11 is the hinge for every software startup

Classification is the most consequential regulatory decision a founder makes under the MDR, and for a software-only company Rule 11 is the decision. Every downstream obligation — the conformity assessment route under Article 52, the clinical evidence burden, the Notified Body cost, the technical documentation depth, the timeline — flows from the class that Rule 11 assigns. Classify wrong and the project is the wrong project.

Most of the founders we meet arrive with a Class I assumption. They have read Article 2(1), concluded that their software is probably a medical device, and stopped there. Then someone — a notified body, an investor's diligence team, a future advisor — opens Annex VIII to Rule 11, reads it carefully, and the Class I assumption collapses within thirty seconds. We have watched this conversation happen dozens of times. It always ends the same way: the team now has a Class IIa project on their hands, and the plan they built last quarter is no longer the plan.

This post is the operating manual for that conversation. We walk through the actual text of Rule 11, decode each branch, apply it to the cases founders care about, and flag the up-classification reality that catches MDD veterans off guard. The goal is that by the end of this post you can apply Rule 11 yourself, reach a defensible class, and know exactly where the borderline cases are so you can escalate them deliberately rather than stumble into them.

## The text of Rule 11, decoded

Rule 11 sits inside Annex VIII of Regulation (EU) 2017/745, under "Rules for active devices". In substance — and we are summarising the legal text, not quoting it verbatim because the exact wording is the legal text that governs you and must be read in full at the source — Rule 11 works in three layers.

**Layer 1 — the decision-making branch.** Software intended to provide information which is used to take decisions with diagnostic or therapeutic purposes is in Class IIa. It is in Class IIb if those decisions could cause a serious deterioration of a person's state of health or a surgical intervention. It is in Class III if those decisions could cause death or an irreversible deterioration of a person's state of health.

**Layer 2 — the monitoring branch.** Software intended to monitor physiological processes is in Class IIa. It is in Class IIb if it is intended for monitoring vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient.

**Layer 3 — the catch-all.** All other software is in Class I.

Read the three layers in order and the structure of the rule becomes clear. Rule 11 assigns a class based on what the software is doing and how bad it is if the software is wrong. The "all other software" bucket is the residual — it picks up the software that neither drives clinical decisions nor monitors physiological processes. That bucket is small in practice. (Regulation (EU) 2017/745, Annex VIII, Rule 11.)

Two words in the rule are load-bearing and routinely under-read. "Information" is broad — it covers any output the software produces that a clinician or patient uses as an input to a clinical decision: risk scores, severity gradings, priority flags, classifications, recommendations, alerts, thresholds. "Decisions" includes decisions made by a clinician who uses the software output as one input among several. You do not need autonomous decision-making for Rule 11 to apply. Decision support is in scope.

## Branch 1 — the decision-making purpose

Most medical device software lands in the decision-making branch. If the software takes patient-specific data and produces an output that informs a diagnosis, a prognosis, a treatment choice, a dosing decision, a referral decision, a screening decision, or a monitoring follow-up, you are in this branch.

The baseline is Class IIa. To stay at IIa, the clinical consequence of the software being wrong has to be bounded — the wrong output could cause harm, but not serious deterioration of health, not surgical intervention, not death, and not irreversible deterioration.

**The escalation to Class IIb** is triggered when the decisions the software informs could cause:

- a serious deterioration of a person's state of health, or
- a surgical intervention.

"Serious deterioration" is the language of the MDR vigilance framework as well — it refers to clinical consequences significant enough that the patient's trajectory is materially worse, not a minor or reversible set-back. "Surgical intervention" includes both immediate intervention triggered by a wrong output and intervention avoided incorrectly because of a false reassurance.

**The escalation to Class III** is triggered when the decisions the software informs could cause:

- death, or
- an irreversible deterioration of a person's state of health.

Class III is the ceiling and it is rare for software alone, but it is not empty. Software that drives dosing calculations for high-risk therapies, software that interprets imaging for conditions where a missed finding is fatal, and software that controls the behaviour of life-critical therapy are all candidates. If the worst plausible consequence of the software being wrong is a death or a permanent, non-recoverable harm, the class is III — not IIb.

The question that drives this branch is not "how likely is the software to be wrong" but "if it is wrong, what is the worst plausible clinical consequence". Rule 11 is about the ceiling of harm, not the probability. Risk controls do not reduce the class under Rule 11 — they reduce the residual risk inside the class. This is a point MDD veterans get wrong repeatedly.

## Branch 2 — the monitoring branch

The monitoring branch covers software intended to monitor physiological processes. This is the branch for continuous-monitoring software, for wearable data streams that produce clinical outputs, for ICU-adjacent monitoring tools, and for anything that watches a physiological parameter over time and does something with it.

The baseline is Class IIa. The single escalation to Class IIb depends on two conjunctive conditions that both have to be met:

1. The parameter being monitored is a **vital physiological parameter**, and
2. The nature of the variations is such that they could result in **immediate danger** to the patient.

Both conditions matter. Monitoring a vital parameter where slow drift has no acute consequence stays at IIa. Monitoring a non-vital parameter where rapid changes could be inconvenient stays at IIa. To reach IIb in this branch you need vital plus immediate danger. Software that monitors heart rhythms for arrhythmias that could cause sudden cardiac events, software that monitors respiratory parameters for apnoea in a setting where minutes matter, and software that monitors haemodynamic parameters in acutely unwell patients are candidates.

The monitoring branch does not have a Class III escalation in Rule 11. A pure monitoring function maxes out at IIb. If a monitoring software also drives therapeutic decisions that could lead to death or irreversible deterioration, it is in the decision-making branch and classified under Layer 1, not Layer 2.

## Branch 3 — "all other software" → Class I

The catch-all exists but is narrower than founders hope. To reach Class I under Rule 11, the software must qualify as a medical device under Article 2(1) — meaning the intended purpose is medical — but must not provide information used for diagnostic or therapeutic decisions and must not monitor physiological processes.

In practice, the Class I candidates under Rule 11 are things like patient diaries that do not interpret or score the entries, pure data-capture tools without clinical output, medical reference databases without patient-specific output, and communication or administrative tools whose medical purpose is narrow. These exist, but if your product ingests patient data and produces any output that a clinician or a patient uses to decide something about care, the catch-all is not your bucket.

The rule we give founders: if you think you are Class I under Rule 11, write down the sentence that explains why, and then try to falsify it against MDCG 2019-11 Rev.1. The falsification attempt usually succeeds.

## MDCG 2019-11 Rev.1 — the worked examples are the calibration tool

MDCG 2019-11 Rev.1 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR — was first issued in October 2019 and revised to Revision 1 in June 2025. Revision 1 is the current version. Anything older is superseded. (MDCG 2019-11, Revision 1, June 2025.)

For Rule 11 specifically, MDCG 2019-11 Rev.1 does three things the MDR text does not.

First, it provides a decision algorithm. The MDR text gives you the definitions; the MDCG guidance gives you a repeatable walk-through that produces the same class when two different people apply it to the same software. This is the algorithm Notified Bodies and Competent Authorities use themselves.

Second, it provides worked examples across clinical domains — imaging, cardiology, diabetes management, decision-support tools, laboratory software, ophthalmology, dermatology, and others. These examples are how you calibrate a borderline case. Find the example that most closely resembles your software and the classification argument largely settles.

Third, it addresses modules and changes — how to classify software that contains both medical and non-medical modules, and how to handle changes to software that is already placed on the market. This is where most founders get stuck on their second classification and where MDCG 2019-11 Rev.1 is indispensable.

We cover MDCG 2019-11 Rev.1 in full in post 374. For Rule 11 work specifically, post 085 walks the decision-making branch deep-dive and post 086 walks the monitoring branch deep-dive, including borderline cases that need expert judgment.

## A real classification conversation — the HW/SW case

We have worked with founders building combined hardware-software devices where the classification discussion splits cleanly down the middle. In one case the device was a combined hardware-plus-software product where the software component was clearly Class IIa under Rule 11 — it produced diagnostic-decision-support information from patient data — but the hardware classification was arguable because the hardware alone could be read under either a lower or higher rule depending on how the intended purpose was written. The software class was the easy part of the conversation. The hardware was where the real debate sat. This is a pattern we see repeatedly: Rule 11 often delivers a fast, defensible software class while the hardware argument still needs work.

The lesson is not "software is always easy to classify" — borderline software cases exist and they are hard. The lesson is that Rule 11 is usually more determinate than founders expect once it is applied properly. If your software passes through the decision-making branch, the class is IIa at minimum, and the debate is only about whether IIb or III applies. That is a narrower debate than trying to argue for Class I.

## Common misapplications of Rule 11

These are the recurring mistakes we see when a founder's classification argument reaches a Notified Body or a second-opinion review.

**"Clinicians are always in the loop, so it is not decision-support."** Rule 11 explicitly covers information used by clinicians to take decisions. The presence of a clinician in the loop does not drop you out of the decision-making branch.

**"Our output is informational, not diagnostic."** The word "information" in Rule 11 is exactly what covers informational outputs. If clinicians or patients use the information to take a decision with a diagnostic or therapeutic purpose, the branch applies.

**"Our software only stores and displays data."** Pure storage and display is outside the scope of qualification as MDSW under MDCG 2019-11 Rev.1 — it does not perform an action on data. But if the software calculates, interprets, scores, alerts, flags, or classifies, the action test is crossed and Rule 11 applies.

**"We added risk controls, so we dropped a class."** Rule 11 is indifferent to your risk controls. Risk controls under EN ISO 14971:2019+A11:2021 reduce the residual risk within the class you are in. They do not move the class.

**"We are in research use only, so Rule 11 does not apply."** Research-use-only positioning can keep software outside the MDR entirely if the intended purpose is genuinely non-medical and the claims match. But if any part of your public positioning or clinical use pattern says "diagnostic" or "therapeutic", Rule 11 applies and the research label will not save you at the vigilance stage.

**"Similar software on the US market is Class II, so we are IIa."** FDA and MDR classifications diverge. A Class II FDA product can be IIa, IIb, or III under Rule 11 depending on the intended purpose and the clinical consequence. Never assume mapping.

## The up-classification reality — MDR vs the former MDD

Before the MDR, software was classified under the old Directive 93/42/EEC using rules that frequently defaulted software to Class I. A large fraction of medical software on the EU market was MDD Class I self-declared. The MDR rewrote Rule 11, and the rewrite changed the default from "Class I unless escalated" to "Class IIa unless residual". The same software, under the same intended purpose, frequently moved from MDD Class I to MDR Class IIa overnight on the regulatory clock.

For a founder today this matters for two reasons. First, if you are comparing yourself to a competitor who has been on the market since before 26 May 2021, their historical Class I status is not a benchmark for your MDR classification. Second, if you are taking over or acquiring software that was on the market under the MDD, the transitional provisions under Regulation (EU) 2023/607 allow legacy certificates to remain valid for specified periods, but the MDR-class question still arrives eventually and the up-classification is waiting.

The practical consequence is that most medical software under the MDR is IIa at minimum, and the IIa path requires a Notified Body. There is no self-declaration route for MDR Class IIa software. The cost, timeline, and obligations are meaningfully different from MDD Class I — and that change is the reason the SaMD category is harder under the MDR than it was under the MDD.

## The Subtract to Ship angle for Rule 11

Rule 11 looks like a one-way escalator, but the lever you have is the intended purpose. Article 2(12) of the MDR defines the intended purpose as what the manufacturer states in labelling, instructions for use, promotional materials, and the clinical evaluation. The Rule 11 branch and the Rule 11 class both depend on what the intended purpose actually is. That is the lever.

Subtract to Ship, applied to Rule 11, means writing the narrowest intended purpose that still describes the product you are actually building and the market you are actually serving. If you genuinely do not need to make a surgical-intervention claim, do not make one. If the software does not need to inform a decision that could cause irreversible harm, scope it so it does not. If the monitoring function is not genuinely for vital parameters, do not describe it as such. The goal is not to game the rule — that fails at the Notified Body — but to match the claim exactly to the product, so the classification reflects the reality and no more.

The converse trap is also common. A founder who writes an expansive, aspirational intended purpose in the pitch deck and then copies it into the technical documentation has just written themselves into a higher class. Marketing text and regulatory text are not the same text. Keep them consistent, but keep the regulatory text tight.

This is the lean approach to Rule 11. Scope the intended purpose honestly and narrowly. Let the class fall where it falls. Build for the class. Do not over-claim to impress investors and do not under-claim to escape the Notified Body — both fail at different stages of the same project. Post 065 covers the Subtract to Ship framework as it applies to MDR work as a whole.

## Reality Check — Where do you stand on your Rule 11 classification?

1. Have you written down your software's intended purpose in one paragraph, matching the form Article 2(12) expects, covering labelling, IFU, and promotional materials?
2. Walking Rule 11 branch by branch, does your software land in the decision-making branch, the monitoring branch, or the catch-all? Can you defend that choice in writing?
3. In the decision-making branch, what is the worst plausible clinical consequence if the software output is wrong — bounded harm (IIa), serious deterioration or surgical intervention (IIb), or death or irreversible deterioration (III)?
4. In the monitoring branch, are the parameters genuinely vital, and can variations genuinely result in immediate danger? If not both, you are IIa, not IIb.
5. If you believe you are in the catch-all (Class I), can your intended purpose survive the MDCG 2019-11 Rev.1 decision algorithm without collapsing into a decision-support claim?
6. Have you cross-checked your classification against the worked examples in MDCG 2019-11 Rev.1 and found an example that resembles your software?
7. Is your EN 62304:2006+A1:2015 software safety class (A, B, C) consistent with your MDR class under Rule 11 and with your EN ISO 14971:2019+A11:2021 risk management output?
8. Does every public claim — website, app store, marketing — match the intended purpose you are relying on for Rule 11? Mismatches will be found.

Any question you cannot answer with a clear yes is a gap. Close it before the engineering team builds another sprint on assumptions that may not hold.

## Frequently Asked Questions

**Is Rule 11 the only classification rule that applies to software?**
Rule 11 is the primary rule for MDSW and in most cases it drives the class. Other rules can apply in specific situations — for example, software that drives a hardware medical device is typically classified together with the hardware under the rule that applies to the hardware, not under Rule 11. MDCG 2019-11 Rev.1 covers these interactions. When in doubt, walk Rule 11 first and then check whether a device-specific rule overrides it for your case.

**Can software be Class I under MDR Rule 11?**
Yes, but rarely. The Class I catch-all in Rule 11 applies only to software that qualifies as a medical device but neither provides information used for diagnostic or therapeutic decisions nor monitors physiological processes. Patient diaries without interpretation, pure data-capture tools without clinical output, and certain reference and administrative tools are candidates. If your software processes patient data and produces any decision-relevant output, assume IIa until MDCG 2019-11 Rev.1 proves otherwise.

**What is the difference between Class IIb and Class III under Rule 11?**
Class IIb applies when the decisions the software informs could cause serious deterioration of health or a surgical intervention. Class III applies when those decisions could cause death or irreversible deterioration of health. The distinction is the ceiling of harm: serious but recoverable versus fatal or permanent. For borderline cases, the worked examples in MDCG 2019-11 Rev.1 are the single best calibration tool.

**Does adding risk controls let me drop a class under Rule 11?**
No. Rule 11 is indifferent to risk controls. Risk controls under EN ISO 14971:2019+A11:2021 reduce the residual risk within the class you are in; they do not move the class. The class is set by the intended purpose and the ceiling of harm, not by how well you mitigate that harm. This is one of the most common misconceptions among founders arriving from an MDD background.

**How does Rule 11 interact with the EN 62304:2006+A1:2015 software safety class?**
They are different classifications that must be consistent. Rule 11 sets the MDR device class (I, IIa, IIb, III) which drives the conformity assessment route with the Notified Body. EN 62304:2006+A1:2015 sets the software safety class (A, B, C) which drives the specific lifecycle activities required by the standard. Both flow from the same risk analysis but they answer different questions. You need both, documented consistently, and traceable back to the risk management file under EN ISO 14971:2019+A11:2021.

**Is Rule 11 different for AI/ML software under the MDR?**
Rule 11 itself does not treat AI or ML differently — the qualification and classification depend on intended purpose and clinical consequence, not on the underlying algorithmic method. What AI changes is the lifecycle discipline, the clinical evaluation expectations, the PMS obligations for model drift, and the transparency the Notified Body expects. The EU AI Act adds a separate regulatory layer on top of the MDR for AI systems. The Rule 11 class itself is determined the same way.

## Related reading

- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology pillar that governs how we approach Rule 11 scoping.
- [MDR Device Classification Explained](/blog/mdr-device-classification-explained) — the hub post for the classification cluster, covering all four classes and the structure of Annex VIII.
- [MDR Classification Rules Overview — Annex VIII](/blog/mdr-classification-rules-annex-viii) — the spoke covering Rules 1–22 structure, including where Rule 11 sits.
- [Rule 11 Decision-Making Branch — The Deep Dive](/blog/mdr-rule-11-decision-making-deep-dive) — the advanced walk-through of the IIa/IIb/III escalation.
- [Rule 11 Monitoring Branch — The Deep Dive](/blog/mdr-rule-11-monitoring-deep-dive) — the advanced walk-through of the vital-parameters escalation.
- [What Is Software as a Medical Device (SaMD)?](/blog/what-is-software-as-medical-device-samd-mdr) — the SaMD pillar covering qualification before classification.
- [MDCG 2019-11 Rev.1 — What the Software Guidance Actually Says](/blog/mdcg-2019-11-software-guidance) — the full reading of the definitive guidance document.
- [The MDR Software Lifecycle and EN 62304:2006+A1:2015](/blog/mdr-software-lifecycle-iec-62304) — the lifecycle obligations that follow from Rule 11.
- [EN 62304:2006+A1:2015 Software Safety Classification A, B, C](/blog/software-safety-classification-iec-62304) — the software safety class, distinct from the MDR device class.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 51 (Classification of devices) and Annex VIII (Classification rules), Rule 11. Official Journal L 117, 5.5.2017.
2. MDCG 2019-11 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR. First published October 2019; Revision 1, June 2025.
3. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015).
4. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.

---

*This post is a spoke in the Device Classification & Conformity Assessment category of the Subtract to Ship: MDR blog, and a cross-cluster reference for the Software as a Medical Device Under MDR category. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — MDCG 2019-11 Rev.1 is the authoritative interpretation, and EN 62304:2006+A1:2015 and EN ISO 14971:2019+A11:2021 are the tools that provide presumption of conformity with the software-lifecycle and risk-management requirements of the MDR, not independent authorities. For startup-specific regulatory support on Rule 11 classification and software conformity assessment, Zechmeister Strategic Solutions is where this work is done in practice.*

---

*This post is part of the [Device Classification & Conformity](https://zechmeister-solutions.com/en/blog/category/classification) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*