Class I software

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

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 section 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:

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.

b) Case constellation (1)

This case constellation is found verbatim in the MDR. There it says:

Usually, it is the responsibility of physicians to reach a diagnosis and decide on treatment. Merriam-Webster defines diagnosis as follows:

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:

1. The information is intended to serve for other decisions.
2. The information is not intended to be used for decision making.
3. 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.

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:

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, Doccheck):

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

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.