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.
1. Background
a) Relevance of the issue
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 a timely manner. 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 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.
b) Objectives and limits of this article
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 chapter 4.a).
2. Legal framework for class I software
a) MDR
The legal basis for the classification of software is found solely in Annex VIII of the MDR, in particular its Rule 11.
b) MDCG guidelines
The MDCG has published guidelines on the classification of devices:
- MDCG 2019-11 on the classification of software
- MDCG 2021-24 on the classification of medical 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.
c) IMDRF
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.
3. Classification of class I software
a) Overview
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).
b) Case constellation (1)
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.
Caution
- The reverse is not true: If the intended purpose designates physicians as users, it does not automatically follow that the software belongs to a higher class.
- This rule of thumb does not apply if primarily medical responsibilities are delegated to patients. For example, software “prescribing” medication to patients based on their symptoms, including its dosage, would not belong in class I.
Several circumstances may lead to the above condition (“decisions with diagnostic or therapeutic purposes”) not being met:
- The information is intended to serve for other decisions.
- The information is not intended to be used for decision making.
- The software does not provide any information.
The following sections address these different case constellations.
c) Case constellation (2)
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.
Examples
For software not classified as software for “diagnostic or therapeutic purposes”:
- Software calculating scores aimed at predicting the likelihood or course of a disease
- Software designed to suggest measures to minimize the likelihood of future disease. Examples of such suggestions include exercise, diet, contacting healthcare professionals, and participating in screening – but not the screening itself.
While the MDR uses the term “prevention,” it does not define it. It probably only uses it in the sense of primary prevention. There are different types of prevention (see BMG [German]):
- Primary prevention: prevent disease or injury before it ever occurs by eliminating (exposure to) hazards
- Secondary prevention: reduce the impact of a disease or injury that has already occurred, e.g., by screening and early detection of disease
- Tertiary prevention: Limiting or compensating sequelae of a disease
d) Case constellation (3)
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.
Examples
Software guiding, supporting, or providing physical exercise to patients:
- Software for eye exercises
- Pelvic floor exercise software in erectile dysfunction
- Software for practicing behavioral changes, e.g., in addictive behavior
- Software for instructing specific strength and movement exercises
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 standalone 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).
e) Case constellation (4)
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.
f) Case constellation (5)
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.
4. Conclusion & summary
a) Rule 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 is incomplete: It seems to assume that all critical software is used either in diagnostic or therapeutic decision making, or to monitor physiological processes. As pointed out above, this is not true.
- This opens up the possibility that software with a “potentially high risk of injury” and not belonging to either of these two categories could fall into class I, i.e., be assigned a classification that is too low.
- On the other hand, it is not justifiable that all software serving diagnostic and therapeutic decision making has to be classified as class IIa and higher. Even the IMDRF document referenced by the MDCG provides differentiated examples of such class I software. In other words: In these cases, the software classification is too high.
- Moreover, Rule 11 is inconsistent with other rules: Why are diagnosis and treatment grouped together, whereas the rules for the other devices explicitly separate the two? Software is therefore penalized.
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).
b) Consequences of these rules
The regulatory documents prompt many discussions:
- Looking into the DiGA directory, the decisions of authorities and notified bodies do not always appear to be consistent and understandable.
- Higher risk classification creates insurmountable obstacles for some manufacturers and affects their competitiveness and innovation.
- Devices classified as high risk will be late to market or not available at all, thus denying state-of-the-art patient care.
- In their rulings, judges base their decisions on idiosyncrasies in MDCG documents, thus reinforcing them.
- EU regulations are no longer harmonized with regulations in countries such as the United States and Australia, which explicitly focus not only on patient safety, but also on patient care with innovative devices and on market competitiveness.
c) Hopes and recommendations
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.
Disclaimer:
This article reflects the current state of knowledge, which may change as a result of future guidelines and court decisions.
Change history
- 2022-12-20: The solid line after the box “probably not MDSW…” replaced by a dashed line because the process must be canceled if it is not an MDSW
