MDR Classification Rule 11: The classification nightmare?

The MDR contains the Classification Rule 11. This rule is especially for software. The Rule 11 has serious implications: it bears the potential to further undermine Europe’s innovation capacity.

Manufacturers should familiarize themselves with the MDCG‘s interpretation to avoid misclassifying software and to be able to follow the reasoning of notified bodies and authorities. This article will explain this interpretation.

1. What does MDR Rule 11 say?

Rule 11 of Chapter III in Annex VIII of the MDR contains the following provisions:

“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
• 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 are classified as class I.”

Rule 11 again raises the question of what “physiological processes” are. The MDR does not define the term.

2. Which standalone software does NOT fall into class I according to Rule 11?

a) Definition of medical device

According to the MDR, medical devices are still any instrument, apparatus, software, etc. intended by the manufacturer to be used for one of the following purposes:

• diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease
• diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability
• investigation, replacement or modification of the anatomy or of a physiological or pathological process or state
• providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations […]“

b) Consequences

Collating this list with the provision of Rule 11, one thing becomes clear:

(Almost) any software used for the purpose of diagnosis, monitoring, prediction, prognosis, or treatment also provides information which is used to take decisions with diagnosis or therapeutic purposes. Exactly this type of software is classified as class IIa or higher under Rule 11.

The EK-Med also sees the risk of a higher classification. Specifically, it writes:

“This regulation will tend to result in a higher classification – especially for apps – and as a result, among other things, will increasingly require the involvement of notified bodies and the conduct of clinical trials.”

EK-MED 1934/16

The former Rule 10a has now been adopted almost word for word in Rule 11.

c) Exceptions

Only the following purposes justify a class I classification:

• Prevention, e.g., a cardio training app offering workout recommendations
• Monitoring, if not used for diagnosis or if there is no vital threat, e.g., if a software monitors a physiological parameter based on which no diagnosis is proposed and which only indicates non-therapeutic actions. A rather far-fetched example would be software monitoring the fluid balance and reminding to consume fluid.
• Prognosis not intended for decision making
• Alleviation, e.g., biofeedback systems not considered as therapy since they “solely” easy symptoms

This article describes another proposal as a way out discussing a separation of data and information. Accordingly, PACS would not provide any information.  

3. What are the consequences of Rule 11?

In general, software will be classified in higher classes. Here are some examples:

product	class according to MDD	class according to MDR
app supporting the selection and dose calculation of cytostatic drugs	I	III
standalone software application for AMTS	I	III (depending on the medication)
software suggesting diagnoses based on test results	I	IIb or higher (up to III)
PDMS	I or IIa	IIb or III
app to diagnose sleep apnoea	I	IIa (or higher)
therapy or radiation planning software	IIb	IIb or III, depending on the argumentation

a) Consequence no. 1: Non-critical applications’ costs and expenses explode

As soon as software is no longer classified as class I, manufacturers must

1. involve notified bodies.
2. in general, establish a certified quality management system.

Thereby, manufacturers’ expenses and costs multiply. Particularly smaller companies such as app developers, start-ups and university spin-offs are highly affected.

b) Consequence no. 2: The classification does not always mirror the risk

While previously, even highly critical software calculating the dose of cytostatic drugs fell within class I, we can now observe the contrary: Due to Rule 11, it could be that even non-critical applications fall within class III.

The reason is that the classification either considers only severity (e.g., “might lead to death”) or duration (“irreversible”).

• Does every product have to fall within class III, even if product failure results only in highly unlikely cases in death?
• Does each irreversible damage, however small, require the same classification?

The classification should reflect the risk. Risks are combinations of degrees of severity and probabilities. This is exactly what Rule 11 does not take into account.

Software used to calculate dosages of drugs, to select drugs, or to schedule therapies such as radiation and surgeries will probably all fall within class III.

c) Bottom line: Rule 11 will dampen innovation

Patients’ safety has first priority. The same goes for patients’ health. Rule 11 will impede software development to an extend which makes it hardly possible for small manufacturers to overcome regulatory obstacles.

Products not entering the market will not endanger safety. But products which cannot enter the market cannot contribute to diagnosing diseases and injuries or to alleviating or treating them.

Medical devices can lead to the death of humans. But the same goes for the absence of medical devices. Rule 11’s authors will be measured by this.

4. MDCG on Rule 11

a) Applicability of Rule 11

The MDCG defines the term “medical device software.” It also states:

Medical device software is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device.

Source: MDCG 2019-11

The addition “regardless of whether the software is independent or is driving or influencing the use of a device” could give the impression that Rule 11 applies to both standalone and control software.

However, this is not the case: the fact that both types of software are classified as medical devices does not mean that Rule 11 applies to both. Rather, two cases must be distinguished for classification according to MDR (not classification as a medical device):

1. The software “drives a device or influences the use of a device”: the classification of the software corresponds to that of the “influenced medical device independent of Rule 11.
2. “Independent of any other device” is: The classification of the software is done by users of Rule 11.

The classification, according to MDR, is therefore not “regardless of” but “depends on whether the software is independent or is driving or influencing the use of a device.”

b) Consequences for the classification

From the MDCG document follows:

The idea behind this is probably the following: software in hardware that has nothing to do with controlling the hardware, and therefore, the device is to be regarded as standalone software. It “accidentally” runs in hardware but should, therefore, not be regulated as embedded software. Judges may have to decide whether this is in line with the meaning of the law or even contradicts it.

A “minor question” to the German government on whether the stricter requirements of the MDR could be weakened or postponed, especially for digital medical devices, was answered negatively (response from the German government).

Considerations of the MDCG

The MDCG emphasizes that the highest rule always applies. However, Rule 3.5 already specifies this. More interesting is the example that the MDCG gives:

If software controls an infrared scanner (class IIa) that also examines the images recorded by this scanner for a melanoma, two rules apply:

1. Rule 3: The software controls and influences the scanner. They would, therefore, also fall into class IIa.
2. Rule 11: Because it is used for cancer detection, the MDCG assumes a classification in class III.

Because the higher rule applies, this software would have to be assigned to class III!

The MDCG also indirectly heralds the (feared) end for all class I software. It writes the following with regard to the sentence “Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa”:

Therefore it will be necessary to consider this sub-rule for all MDSW.

Draft of the MDCG document on “Medical Device Software” (MDCG)

This means that all software would then fall into classes IIa, IIb or, III.

Interestingly, the MDCG adds the word “serious” to Rule 11:

“death or an irreversible serious deterioration of a person’s state of health, in which case it is in class III; or”

Draft of the MDCG document on “Medical Device Software” (MDCG)

This addition should be welcomed. At the same time, the question has to be asked as to why a correction is possible in the law, but the classification itself has not been improved and reference is made to the IMDRF guidance document (see above).

c) Interpretation of Rule 11 by MDCG 2019-11

Brussels has recognized that Rule 11 is not one of the most successful parts of the MDR. The fact that its classification only takes into account severity but not risk means that too many software applications are classified as class III. After all, in the worst case, something bad can always happen. That renders the idea of risk-based classification absurd.

A table referring to an IMDRF classification has been added to page 26 of the MDCG document. This may make it possible to classify software lower.

			Significance of Information
			Treat Provide therapy to human body Diagnose Detect Screen Prevent Mitigate Lead to an immediate or near-term action	Aid in treatment Provide enhanced support To safe and effective use of medicinal products Aid in Diagnosis Help predict risk of a disease or condition Aid to making a definitive diagnosis Triage / Identify early signs of a disease or condition	Inform of options for treatment Inform of options for diagnosis Inform of options for prevention Aggregate relevant clinical information Will not trigger immediate or near-term action
Disease type / Patient condition	Intervention type		Treat or diagnose	Drive clinical mgt.	Inform clinical mgt.
Life threatening Fragile in consideration to the disease in question	Requires major therapeutic interventions Sometimes time critical Vital to avoid death, serious deterioration of health, mitigating public health situations or conditions	Critical	IMDRF IV MDR III	IMDRF III MDR IIb	IMDRF II MDR IIa
Moderate in progression Often curable Non-fragile in consideration to the disease in question	Does not require major therapeutic interventions Not expected to be time critical Vital to avoid unnecessary interventions	Serious	IMDRF III MDR IIb	IMDRF II MDR IIa	IMDRF I MDR IIa
Slow with predictable progression of disease state Minor chronic illnesses or states May not be curable Can be managed effectively		Non-serious	IMDRF II MDR IIa	IMDRF I MDR IIa	IMDRF I MDR IIa

This new approach brings advantages but does not solve all the problems:

Advantages

• This classification is again risk-based and not (solely) based on the severity of potential harm. The inclusion of health conditions and potential interventions helps here.
• This will significantly reduce the number of devices that would have to be classified, absurdly, as class IIb or III. This is good, as well as being the correct approach.
• The classification follows a logic. It is comprehensible.

(New) challenges

Inadequate problem solving

Rule 11 is simply not fit for purpose. It doesn’t make sense that this error is not corrected but, instead, the rule has been partially undermined by a “guideline.” Errors in laws have to be corrected in laws, not in explanations. Manufacturers wouldn’t get away with this kind of mess.

Confusing examples

The examples raise new questions: When is software used for “diagnosis” and when is it an “aid in diagnosis”, when is “aid to making a definitive diagnosis” and when is it used to “inform of options for diagnosing”?

What software provides a direct diagnosis in the sense of an ICD code? (Almost) all software applications in the context of diagnoses provide information that is more or less crucial for a diagnosis. Why were the definitions of the term “direct diagnosis” not even adopted in the MDR? It can be found in Annex VIII 3.7.

A new problem is created

The first revision of MDCG 2019-11 extends the applicability of Rule 11 a) to prognosis. It states:

a device intended to prevent the risk of illnesses or pathologies by analysing physiological parameters […] can be considered as a device providing information which is used to take decisions with diagnosis purpose (potential detection of pathologies) and in this case is in class IIa.

The MDR clearly distinguishes between “diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease.” It is, therefore, difficult to understand why the MDCG reinterprets prognosis as a diagnosis.

A major problem remains unresolved

The IMDRF deliberately introduced a class I for completely non-critical devices. However, the MDR categorizes these non-critical devices as class IIa. This leaves a major problem: There is hardly any software left that falls under class I according to the MDR. Even for non-critical devices, conformity assessment is no longer possible without a notified body, and a certified quality management system is required.

While the FDA is deregulating, we Europeans are weakening our competitiveness by stifling small, innovative companies that develop non-critical devices with regulations. Brussels has clearly not done the homework it has set manufacturers: weighing up the risks and benefits in risk management. How many people will we save with the new rules? How many lives will we endanger by preventing innovative devices from reaching the market?

d) Complete confusion due to MDCG 2021-24

With the MDCG 2021-24 guideline, Brussels is making another attempt to create clarity in classification. This is not entirely successful in the case of software:

• The new guideline does not resolve Rule 11 and MDCG 2019-11 contradictions. It does not even address them.
• It also gives examples that do not help.
• Examples even seem to contradict MDCG 2019-11.
• The new guideline does not address the actual problem, namely that Rule 11 is severity-based and not risk-based. How should manufacturers deal with the fact that, in the worst and unlikely case, patients always have “irreversible deterioration”? How should manufacturers argue against an obviously inappropriate class III classification?

The following table comments on the MDCG’s examples.

class	Rule 11	examples	comment
IIa	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:	MDSW intended to rank therapeutic suggestions for a health care professional based on patient history, imaging test results, and patient characteristics, for example, MDSW that lists and ranks all available chemotherapy options for BRCA-positive individuals.Cognitive therapy MDSW where a specialist determines the necessary cognitive therapy based on the outcome provided by the MDSW.	The examples are in accordance with MDCG 2019-11. However, it remains unclear why a BRCA-positive patient, i.e., a person who is highly likely to suffer from a highly aggressive cancer, would not suffer a “serious deterioration” if the wrong chemotherapy was proposed. This would promote the software to class IIb.
III	— death or an irreversible deterioration of a person’s state of health, in which case it is in class III; or	MDSW intended to perform diagnosis by means of image analysis for making treatment decisions in patients with acute stroke.	This example is one of the few clear and understandable ones, at least if wrong treatment decisions based on the software would kill or seriously harm vulnerable patients.
IIb	— a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as class IIb.	A mobile app intended to analyse a user’s heartbeat, detect abnormalities and inform a physician accordingly. MDSW intended for diagnosing depression based on a score resulting from inputted data on patient symptoms (e.g. anxiety, sleep patterns, stress etc.).	It is unclear whether this concerns one or two examples. The layout suggests that it concerns two, but the missing bullets suggest that it’s one. If there are two examples, understandable reasons are missing. If the MDCG 2019-11 is followed, the first case would be classified as ” aid in diagnosis” and “often curable” and thus in class IIa. Or Rule 11 is applied, in which case the software would be in class III, as death is always possible with any degree of probability. The fact that Rule 11 is a severity-based classification and not a risk-based classification is precisely the criticism. Unfortunately, MDCG 2021-24 does not help here. Similar considerations also apply in the second case. Suicide would be the worst case here.
IIa	Software intended to monitor physiological processes is classified as class IIa,	MDSW intended to monitor physiological processes that are not considered to be vital. Devices intended to be used to obtain readings of vital physiological signals in routine check-ups including monitoring at home.	This is not an example but a rephrasing of the text. Now, the authors switch to devices(?), so the role of software becomes unclear. Software that only stores data is not qualified as a medical device by the MDCG 2019-11.
IIb	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.	Medical devices including MDSW intended to be used for continuous surveillance of vital physiological processes in anaesthesia, intensive care or emergency care.	These examples are obvious. The assessment is consistent with MDCG 2019-11.
I	All other software is classified as class I.	MDSW app intended to support conception by calculating the user’s fertility status based on a validated statistical algorithm. The user inputs health data including basal body temperature (BBT) and menstruation days to track and predict ovulation. The fertility status of the current day is reflected by one of three indicator lights: red (fertile), green (infertile) or yellow (learning phase/cycle fluctuation).	This is not an example but a rephrasing of the text. Now, the authors switch to devices(?), so the role of software becomes unclear. Software that only stores data is not qualified as a medical device by the MDCG 2019-11.

5. Planned new Rule 11

a. Context of the revision

In December 2025, the EU Commission published the results of its evaluation of the MDR and IVDR together with a proposal for revising the MDR and IVDR. This proposal is often referred to as MDR 2.0 or IVDR 2.0.

The Commission has recognized that the regulation in its current form could be detrimental to innovation. It has therefore decided, under “Topic 1: Simplification and Proportionality,” to revise the classification rules of the MDR in Annex VIII:

Some classification rules are adapted resulting in lower risk classes for certain devices, such as reusable surgical instruments, accessories to active implantable devices, and software.

No further recitals are mentioned.

b. Planned wording of Rule 11

The EU plans to completely reword Rule 11 as follows:

Software which is intended to generate an output that confers a clinical benefit and is used for diagnosis, treatment, prevention, monitoring, prediction, prognosis, compensation or alleviation of a disease or condition is classified as class I, unless the output is intended for a disease or condition:

• in a critical situation with a risk of causing death or an irreversible deterioration of a person’s state of health, in which case it is classified as class III;
• in a serious situation with a risk of causing a serious deterioration of a person’s state of health or a surgical intervention, or to drive clinical management in a critical situation, in which cases it is classified as class IIb;
• in a non-serious situation, or to drive clinical management in a serious situation or to inform clinical management in a critical or serious situation, in which cases it is classified as class IIa.

c. Approach

The EU Commission is clearly guided by the IMDRF document on the classification of software as a medical device (SaMD), although the scope of Rule 11 is not limited to SaMD.

The IMDRF takes a risk-based approach in that not only the severity of harm (as in the previous Rule 11) but also its probability can play a role. This is because this probability is influenced both by the “state of healthcare” and the ‘directness’ with which the software is used within the scope of its intended purpose and is referred to as the “significance of information” (see Fig. 1).

d. Interpretation/explanation of the new Rule 11 (an attempt)

Rule 11 contains case distinctions that can be visualized as follows:

It is noticeable that the case where the software does not generate output with a “clinical benefit” is not covered.

The opposite case (like the IMDRF) defines the class depending on two dimensions.

1. Purpose
2. Criticality of patients / severity of possible damage

Purpose → Criticality and severity ↓	Treat or diagnose (not mentioned, though)	Drive clinical management	Inform clinical management
Critical situation with risk of causing death or an irreversible deterioration	III (1)	III (1), IIb (2)	III (1), IIa (3)
Serious situation with risk of causing serious deterioration	IIb (2)	IIb (2), IIa (3)	IIb (2), IIa (3)
Non-serious situation	IIa (3)	IIa (3)	IIa (3)

However, the EU Commission selects higher classes than the IMDRF. The IMDRF allows the lowest class I.

Purpose → Criticality and severity ↓	Treat or diagnose	Drive clinical management	Inform clinical management
Critical situation with risk of causing death or an irreversible deterioration	IV	III	II
Serious situation with risk of causing serious deterioration	III	II	I
Non-serious situation	II	I	I

e. Assessment

Praise

• The EU Commission has understood that the current Rule 11 needs to be revised.
• The proposed classification is more risk-based than the previous one.
• Class I has not been abolished, which will hopefully encourage the authorities to return to a legally compliant interpretation.
• The loophole has been closed for software that is used directly for treatment (e.g., for psychotherapy) but “does not provide information that is used to make decisions for diagnostic or therapeutic purposes.” Previously, such software fell into Class I, regardless of the risk it posed.

Criticism

Lack of formal precision, correctness, and completeness

• It is always difficult when rules do not cover all cases. For example, what about software that has no clinical benefit? What happens, for example, if the software has no clinical benefit but can still kill patients? For example, software designed to detect whether maintenance is necessary can lead to the failure of the medical device in the event of a malfunction.
• The proposal confuses the vulnerability of patients (e.g., “critical situation”) with the possible severity of damage (“death or irreversible deterioration”). Strictly speaking, with the dimension of “purpose,” there is a three-dimensional classification space that the rules do not fully cover.

Insufficient clarity and comprehensibility

• There will be further discussion as to whether the output of software that controls a dialysis pump has a clinical benefit. It is unclear how directly this output must have a clinical benefit. Even a PACS does not claim to have a clinical benefit.
• It is unclear what is meant by “intended for a disease.” The treatment of this disease? But then why was it included in the first place?
• It is unclear whether “intended for a disease” also refers to diagnosis and prediction. At least the latter would contradict the IMDRF. This would negate the hoped-for harmonization.

Lack of internal consistency and lack of harmonization with the IMDRF

• This contradiction also exists for the classification in IIa for all non-critical situations (see colors in tables above). Here, the IMDRF explicitly distinguishes the purpose and allows Class I.
• By no longer choosing only the criticality of the situation as a classification criterion, but also the severity of possible damage, the Commission is undermining the entire attempt at risk-based classification. One only has to consider sufficiently improbable cases, and “serious deterioration” can no longer be ruled out. The problem is the word “or,” especially in the first indent.
• Criteria such as “critical” are not defined. Here, one would have to fall back on the IMDRF or wait for MDCG documents. However, a law should be complete on its own.
• Why are diseases and injuries treated differently? Does this mean that software for critically injured patients is classified differently than software for critically ill patients? Or does “condition” refer to injuries? It would have been good to stick with the terms used in the definition of “medical device,” such as ‘injury’ and “disability.”

f. Solution

A relatively elegant solution to most of the problems could be to insert the text “treat or diagnose” at the beginning of each of the three indents. This would result in a classification that is more deserving of the attribute “risk-based” and in which no indents override each other.

Purpose → Criticality and severity ↓	Treat or diagnose	Drive clinical management	Inform clinical management
Critical situation with risk of causing death or an irreversible deterioration	III (1)	IIb (2)	IIa (3)
Serious situation with risk of causing serious deterioration	IIb (2)	IIa (3)	IIa (3)
Non-serious situation	IIa (3)	I	I

Even if this change seems minor, its impact is significant. “Words matter.”

Thanks to Robert Dick-Hambeck for this suggestion!

g. Conclusion

It is regrettable that, once again, it has not been possible to establish classification rules for software-based products that exhibit the most important quality characteristics:

• Comprehensibility
• Completeness
• Internal consistency
• International coordination
• Risk-based approach

And this despite the fact that the IMDRF provided a good template. It’s like a soccer player who manages to hit the post from 2 meters in front of an empty goal.

However, this article at least offers a possible solution.

6. Summary and conclusion

All attempts by the EU Commission and the MDCG to classify software-based medical devices using comprehensible, traceable, complete, risk-based, and internationally coordinated rules have been unsuccessful.

This leads to uncertainty, discussions, (mostly) overregulation, injustice, unnecessary effort, and innovation-hostile conditions in Europe, and harms the business location and patients.

---

Change history:

• 2026-01-21
  • Chapter 5.f) supplemented with the solution approach
  • Key takeaways added at the beginning of the article
  • Chapter 5 on the planned revision of Rule 11 added
  • Summary and conclusion rewritten and renumbered
• 2025-06-25: Chapter 4.c) revised to reflect the revision of MDCG 2019-11
• 2023-03-03: Link to technical article on class I software added
• 2021-10-11: Chapter 4.d) with a discussion of the MDCG 2021-24 added