Practical guidance based on the experience of the Johner Institute, Oliver Hilgers and Stefan Bolleininger
The discussion about class I software continues to rage. This article provides guidance regarding the MDR rules for the classification of medical software.
Whether or not medical software counts as class I software is significant for manufacturers as well as authorities and notified bodies:
The responsibility for class I software rests with the authorities and for software in the higher risk classes with the notified bodies. The latter are completely overworked despite transitional periods that have been extended once again. This means that manufacturers of medical devices struggle to bring innovative medical software to the market in timely fashion. This software is therefore not available for patient care.
If authorities unnecessarily classify software as higher risk, non-critical devices will “clog up” the bottleneck at the notified bodies even more. And manufacturer competitiveness will also suffer.
The authors have noticed a recent increase in this overregulation. If, on the other hand, software is unjustifiably classified as low-risk, it is not “monitored” by the notified bodies as intended by law.
Please note that the requirements for the software and its documentation are almost independent of the classification. For example, the general safety and performance requirements in Annex I (almost) do not differentiate between different classes.
This article is intended to provide more clarity and avoid unnecessary and time-consuming discussions as well as misclassification. It does not seek to undermine existing rules. Rather, in the spirit of the law it attempts to compensate for the errors, gaps and inconsistencies in the legal framework described in section 4.a).
The legal basis for the classification of software is found solely in Annex VIII of the MDR, in particular its Rule 11.
The MDCG has published guidelines on the classification of devices:
However, these guidelines are not legally binding. They give economic operators the flexibility to apply them or not:
Having regard to the status of guidance documents, economic operators and notified bodies should be allowed flexibility as to how to demonstrate compliance with legal requirements.
MDCG 2022-14, section 11
However, there may be legal ramifications if a guideline is referenced in a court decision. This happened, for example, in a court ruling of the European Court of Justice when it referred to MEDDEV 2.1/6.
MDCG document 2019-11 in turn references an IMDRF document on the qualification and classification of software. Thus, its classification system becomes indirectly relevant in decisions about class I software.
The following overview summarizes the legal requirements of MDR Annex VIII Rule 11 in a decision tree. According to this, some software does fall within class I.
The sections below discuss each step (indicated in the diagram by a number in parentheses).
This case constellation is found verbatim in the MDR. There it says:
“Software intended to provide information which is used to take decisions with diagnostic or therapeutic purposes is classified as class IIa [or higher].”
Usually, it is the responsibility of physicians to reach a diagnosis and decide on treatment. Merriam-Webster defines diagnosis as follows:
The art or act of identifying a disease from its signs and symptoms [by a physician]
A good rule of thumb is therefore: Software belongs in class I if it is intended to be used only by patients and does not monitor physiological processes.
Several circumstances may lead to the above condition (“decisions with diagnostic or therapeutic purposes”) not being met:
The following sections address these different case constellations.
Case constellation (2) clarifies whether the software is used for decision making at all - i.e., whether the information obtained is used in decisions. Since we decided “No” in case constellation (1), we know that this is not about diagnostic or therapeutic decisions.
However, the information could be used to make further decisions, such as prevention, prediction, prognosis, and support of conception.
If the software is used for contraception, Rule 15 applies, resulting in a class IIb classification.
The MDR differentiates explicitly between these matters and (unlike its predecessor MDD) expands the definition of the term medical device to include the purposes of “prediction” and “prognosis.” This clearly shows that the EU regulation differentiates between the terms diagnosis, prediction, and prognosis.
In the same way, it is important to differentiate between prevention and treatment. Merriam-Webster defines treatment as follows:
The action or way of treating a patient or a condition medically or surgically : [...] This may involve different approaches aimed at either eliminating the cause of the condition (causal treatment) or the symptoms (symptomatic treatment). The overriding goal of treatment is to restore the patient's normal physical and mental functions as closely as possible.
Prevention takes place at a time when the condition has not yet developed and thus its treatment is not (yet) possible.
for software not classified as software for “diagnostic or therapeutic purposes”:
In this case constellation, we know that the software does not provide information supporting decision making. This is the case when the software does not provide information at all or provides information serving other purposes than decision making.
Examples of software not used in decision making are applications that carry out treatment. The decision has already been made that treatment should be carried out and which treatment it should be.
Software guiding, supporting, or providing physical exercise to patients:
Here, too, the focus is on the patient as the user.
MDCG document 2019-11 explicitly mentions software for prediction in the context of support of conception as an example of class I software.
In stand-alone software not providing any information whatsoever, the question arises as to whether it is a medical device at all. For software not providing information and being part of a medical device, rules other than Rule 11 are likely to apply. It is therefore not “Medical Device Software” (MDSW).
The fourth case constellation clarifies whether the software serves to monitor physiological processes. In this case, the software belongs in class IIa or IIb.
If the software also does not provide any information serving diagnostic or therapeutic decision making (case constellation 1), the MDR assigns this software to class I.
In view of recital 60 of the MDR, devices belonging to class I should have only a “low level of vulnerability associated with such devices .” The MDR authors probably mean not the vulnerability of devices, as e.g. the German translation is “low risk of injury”. Probably meant is not just injury but also other harm to health.
Risk assessment should always include a verifiable analysis of the harm and (!) the likelihood of it happening, because severe harm is still possible even if the likelihood is very low.
Moreover, the classification should not yet take into account any design or protective measures within the software (purely a black box assessment; see also MDCG-2021-24, Note 1 in Rule 9). The decision tree of IEC 62304 Amendment 1 regarding initial safety classification provides preliminary guidance for such an assessment.
The discussions about the correct classification of software stem from the regulatory requirements. For instance, Rule 11 is not entirely satisfactory in several respects:
It has already been criticized elsewhere that the classification of software for diagnostic and therapeutic purposes hinges on severity rather than risk. MDCG document 2019-11 attempts to alleviate this situation.
But the MDCG document also leaves something to be desired. It would be particularly helpful if class I software were also discussed. The table in chapter 11, on the other hand, gives the superficial impression that all software belongs at least in class IIa. The reference to the IMDRF document cited there would still have to be fleshed out and supplemented.
The guidance on classification should, as intended by the lawmakers, be based only on the purpose of the software and not on its functionality (e.g., storing and transmitting data).
The regulatory documents prompt many discussions:
It would be ideal if Rule 11 were fundamentally revised. This could eliminate the gaps and inconsistencies and result in a risk-based approach. If harmonization with other fields of the law could be realized, many hopes would be fulfilled.
If such changes are not possible, it would be helpful for the MDCG to revise the 2019-11 document in a transparent peer-reviewed process.
It would be in the interest of the lawmakers that the authorities and manufacturers follow the risk-based idea of the MDR and do not selectively try to interpret the law as if class I software no longer existed.
Nevertheless, the recitals of the MDR should be respected, i.e., that class I should not include software with a reasonable likelihood of harm beyond low severity levels.
The authors hope that this article will contribute to this.
This article reflects the current state of knowledge, which may change as a result of future guidelines and court decisions.