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.
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:
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.
Further information
Read more about vital bodily functions here. This article provides the missing definition.
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:
Collating this list with the provision of rule 11, one thing becomes clear:
Note the consequences
There will be hardly any stand-alone software left being classified as class I!
Please read our article on Class I software. It lists the exceptions.
(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."
The former Rule 10a has now been adopted almost word for word in Rule 11.
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.
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 |
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.
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.
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 stand-alone 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):
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."
From the MDCG document follows:
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 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).
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).
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 | |||||
|
|
| |||
Disease type / Patient condition | Intervention type | Treat or diagnose | Drive clinical mgt. | Inform clinical mgt. | |
|
| Critical | IMDRF IV
MDR III | IMDRF III
MDR IIb | IMDRF II
MDR IIa |
|
| Serious | IMDRF III
MDR IIb | IMDRF II
MDR IIa | IMDRF I
MDR IIa |
| 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
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 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. |
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.
If you are unsure how to classify your software, our micro-consulting service will gladly help you with free tips.
Change history