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:
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
„Any instrument, apparatus, software, etc. intended by the manufacturer to be used for one of the following purposes:
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.
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|
|Stand-alone 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|
Only the following purposes justify a class I classification:
This article describes another proposal as a way out discussing a separation of data and information. Accordingly, PACS would not provide any information.
As soon as software is no longer classified as class I, manufacturers must
Thereby, manufacturers' expenses and costs multiply. Particularly smaller companies such as app developers, start-ups and university spin-offs are highly affected.
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").
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.
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.
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:
|Significance of Information|
| || || |
|Disease type / Patient condition||Intervention type||Treat or diagnose||Drive clinical mgt.||Inform clinical mgt.|
| || ||Critical||IMDRF IV|
| || ||Serious||IMDRF III|
| ||Non-serious||IMDRF II|
There is hope that Brussels is starting to take countermeasures. This new approach brings advantages, but does not solve all the problems:
There was no good news at the end of 2018 either:
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.
Please note: The MDCG does not restrict the application of Rule 11 to standalone software. This means that software in a physical device has to be assigned to its own class, at least when this software does more than simply control the device. If this software is classified into a class that is higher than that of the “other” device, the manufacturer would have to classify the device higher.
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:
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.