MDR Classification Rule 11 for Medical Device Software

The MDR introduces a new 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.

EK-Med (expert exchange group consisting of the notified bodies) perceives a stricter classification of software, particularly of apps. The EU commission is even considering revisiting this rule.

Rule 11 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."

First, rule 11 addresses stand-alone software that is a medical device (SaMD). If the software serves diagnostic or therapeutic purposes, it falls under rule 11. You may wonder: Which SaMD does not serve these purposes? 

Medical Device Definition

Source: MDR

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

There will be hardly any stand-alone software left being classified as class I!

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

Software that will be classified higher 

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

Software that might remain in class I

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.  

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.

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.

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.

a) Stricter classification

Even the EK-Med recognizes the risk for stricter classification: The organization considers this provision, generally speaking, will lead to stricter classification of software, particularly of apps, inter alia resulting in increased involvement of notified body and execution of clinical trials.

The document "EK-MED 1934/16“, also discussing further impacts of the MDR, can be downloaded here.

b) Brussels is countering! But is it enough?

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.

Now something seems to be changing behind the scenes: IMDRF Document N12 on “Software as a Medical Device” is being considered for use for classification purposes:

There is hope that Brussels is starting to take countermeasures. 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?

c) No hope for Rule 11 victims

2018: A disaster is looming

There was no good news at the end of 2018 either:

1. The EU considered making Rule 11 applicable to software in medical devices, as well as for stand-alone software. This would always be the case if the software goes a long way beyond controlling the medical device. If, for example, software for calculating contraindications was encapsulated in hardware, Rule 11 would still apply.
   The idea behind this is probably that software in hardware that does not have anything to do with the control of the hardware, and therefore of the device, must be considered standalone software that runs “randomly” on hardware. Therefore, it should not be regulated as embedded software. Judges may have to decide whether this is in keeping with the spirit of the law or contrary to it.
2. A “small inquiry” to the German government as to whether the stricter requirements of the MDR, particularly regarding digital medical devices, could be weakened or postponed was answered negatively (response from the German government).

2019: Fears come true

Our fears seem to be coming true. The MDCG has created a draft document in which it presents its ideas on how to handle (and how to classify) medical device software.

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

The MDCG does not give an example of “all other software” assigned to class I.

So things stay as they were: The legislator seems to want to classify software higher and thus do the opposite of the FDA, which is deliberately deregulating digital devices.