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) Weakening of Rule 11 by MDCG 2019-11

Brussels has by now realized that Rule 11 is not one of the more successful parts of the MDR. The fact that its classification only takes into account severity, and not risk, means that too many software applications would have to be classified in class III. After all, something bad can always happen in the worst case. This makes the idea of a risk-based classification absurd.

The MDCG document has added a table on page 26 that refers to a classification of the IMDRF. 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 is, instead, partially removed via an “explanatory document” (MEDDEV?). Errors in laws have to be corrected in laws, not in explanations. They wouldn’t let us manufacturers 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 to 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 used in the context of diagnoses provide information that is important for the diagnosis to a greater or lesser extent. Why have they not even used the definition of the term “direct diagnosis” contained in the MDR? This can be found in Annex VIII 3.7.
• A major problem remains unsolved
  The IMDRF has deliberately introduced a class I for the completely non-critical devices. However, the MDR assigns these non-critical devices to class IIa. This leaves a major problem: there is hardly any software left that falls into class I according to the MDR. Even for non-critical devices, a conformity assessment can no longer be performed without a notified body and a certified quality system is necessary.
  While the FDA deregulates, we Europeans weaken our competitiveness by suffocating small innovative companies that develop non-critical devices with red tape. Obviously, Brussels has not done the homework that it demands from manufacturers: Risk management weighs up the risks and benefits: How many people do we save with the new rules? How many lives do we put at risk through the new rules preventing innovative devices?

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. Conclusion

So it remains the same: the legislator apparently wants to classify software higher and thus goes the opposite way of the FDA, which deliberately deregulates digital products.

---

Change history

• 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