Classification of software medical devices: MDR Guideline

“The use of my app is completely safe. It certainly falls into the lowest risk category.”– MDR probably sees it differently.

Anyone who wants to certify their software as a medical device in accordance with the Medical Device Regulation (MDR) must deal intensively with the question of the risk class. It is not for nothing that the MDR even defines a separate rule for software medical devices. An incorrect classification can lead to considerable additional work and legal consequences. For this reason, our guide supports you in this complex topic.

In the following, we guide you through the decision process for the MDR classification of your software. We will help you find the right class.

If you do not know yet whether your software is a medical device at all, read our article on the subject first.

Is your app a medical device?

The intended purpose determines whether your app should be classified as a medical device at all. Only if this is the case, you can deal with the risk classification. Article 2 (1) of the MDR clearly defines which products are to be classified as medical devices. For example, an app for analyzing cardiac performance can either be intended as a fitness tracker or support a cardiologist in diagnostics. Only in the second case is the app considered a medical device.

As a manufacturer, you decide yourself what purpose your software has. You want to know whether your software is a medical device? Then you will receive a more precise overview in our guide.

MDR risk classification: briefly and concisely

The bottom line of the MDR classification rules in a nutshell: The MDR differentiates between 4 risk classes: I, IIa, IIb III

Figure 1: the four risk classes of the MDR. As a rule of thumb, the greater the potential damage from the use of a medical device software, the higher the class tends to be. As soon as your software influences decisions about a patient’s therapy and diagnostics, or monitors physiological processes (e.g. sleep patterns), it already falls into at least class IIa (rule 11). If a patient is in grave danger, the risk class increases further (e.g. your app provides support after a heart attack). Software that monitors vital parameters (heart, lungs, etc.) also falls into a higher class. As soon as several rules apply to your software, the strictest rule (the highest risk class) applies.

The MDCG guidance document provides a particularly helpful supplement to this guide.

The purpose decides

Let’s start with an example that illustrates the impact that medical purpose has on the risk class.

Your app monitors a woman’s cycle to increase the likelihood of a wanted pregnancy. – Risk class I
Your app monitors a woman’s cycle to reduce the risk of unwanted pregnancy.. – Risk class IIb

An increase of two risk classes, even if it is one and the same product? Yes, in fact, purpose makes an immense difference. Accordingly, you should first think carefully about what the intended purpose of your app should be. You may well adjust your purpose after you finish reading this article. Our article on the purpose statement describes the exact contents and helps you with the wording. Find out if your app is even a medical device in this article.

Standalone, control software, and accessories

Any Software with a distinct medical purpose is classified separately. Overall, there are three different types of software that we would like to distinguish at the outset:

Standalone software / Standalone software
Software used in conjunction with another medical device
Software as part of a medical device

Important at this point for you is that you do not have to classify your software separately if

they are an integral part of another medical device (e.g., embedded software, such as firmware of a blood pressure monitor). This is almost never true for mobile apps.
they exclusively serves to control another medical device (e.g. UI for operating a defibrillator). Then it automatically falls into the same class as the controlled product. However, if the software has another purpose, you must check whether it falls into a higher class.

In all other cases, you need to find the right class for your software. Learn more about the types of software as a medical device here.

Which risk class does my app belong to?

As mentioned earlier, the intended purpose of your app provides the basis for determining which of the four risk classes it falls into. Once the intended purpose is clear, use the rules in Annex VIII to the MDR to find the right class for your software.

We recommend starting the search for the class at rule 11, as this specifically addresses software. At the same time, it is worth taking a look at the MDCG guidance document. Its core contents are summarized in this article.

The rule 11 of the MDR

For medical software, Rule 11 is decisive in most cases. Here, a distinction is made between software that provides information for therapeutic and diagnostic decisions and software that monitors physiological processes.

Of course, an app can have multiple purposes.

According to Rule 11, you must make the following decisions:

1. Is your app intended to provide information that will be used to make diagnostic or therapeutic decisions?

If so, answer these questions below:

Can these decisions cause death or irreversible deterioration of health? If so, your app falls into the Risk class III. Example:

Your software uses image analysis to provide an emergency doctor with the basis for deciding how to treat a patient with acute stroke.

Can these decisions cause serious deterioration of health or surgical intervention? If this is true, your app falls into the Risk class IIb. Example:

Your app provides the basis for a physiotherapist to decide at what point an injured knee can be loaded again. Overloading could lead to surgery.

If you can answer “No” to both questions, your app falls into risk class IIa for the time being. Example:

Their app uses questionnaires to measure the severity of ADHD symptomatology in adults.

Figure 2: Graphical representation of the decision tree of the first part of Rule 11.

2. Is your app intended for monitoring physiological processes?

If yes, answer these questions below:

Is the app intended to monitor vital physiological processes (heart, lung, brain function, etc.), where the nature of the change in these parameters may result in immediate danger to the patient? If so, your app falls for the time being into the Risk class IIb. Example:

Your app monitors a person’s heart rate while they are in a coma. In the event of health-critical readings, medical personnel are alerted so that they can intervene in good time.

If you can answer this question with “No”, your app falls into risk class IIa for the time being. Example:

Your app monitors a patient’s sleep rhythm at home to measure the success of a therapy for sleep disorders.

Figure 3: Graphical representation of the decision tree of the second part of Rule 11.

3. Does your app have another purpose?

Rule 11 clearly states in the last sentence: “All other software is assigned to Class I.” So you have your answer for this case as well – or do you?

Unfortunately no, because then the question arises whether another rule can be applied to your app. Rules 15 and 22 are particularly relevant here:

Rule 15 addresses active devices used for contraception or protection against sexually transmitted diseases. Software in this area falls within Class IIb.

Example:

Your mobile app is intended for contraception. To do this, it reminds a user to take the contraceptive pill every day. If the intake has not been confirmed by a certain time, the app generates a warning signal.

Rule 22 addresses active therapeutic devices with integrated or built-in diagnostic function that significantly determines patient management by the device, such as closed-loop control systems or automated external defibrillators. Software in this area falls within Class III.

Example:

Your software is intended for further accompaniment after psychotherapeutic treatment of depression. Through the built-in diagnostic function, the software adjusts the treatment and determines the need for renewed psychotherapy.

Important: If your software falls into risk class IIb or lower according to Rule 11, you need to look at all the other rules – because there may be a stricter one that increases the risk class. If several classification rules can be applied to your software, the strictest rule is always applicable!

What else falls into Class I anyway?

Under a strict interpretation of the MDR classification rules, most medical software products are classified in risk class IIa or higher. There seem to be few software products left that still fall into Class I under the MDR and that are not purely primary prevention offerings. However, with a look at the DiGA directory, it becomes clear that this strict interpretation is not always given in practice – some applications are already listed there that fall into class I according to MDR and do not represent pure primary prevention.

According to the MDCG, apps for conception support are also likely to fall into risk category I. As an example, the MDCG cites a mobile app that is supposed to predict a woman’s ovulation by entering her basal body temperature and menstruation days.

Case studies for determining the risk class

These case studies are intended to illustrate the decision-making process. They are fictitious examples.

Case study 1: App to accompany exposure therapy

Your app is intended to accompany the exposure therapy of a patient with fear of heights. For this purpose, a list of situations that scare the patient (e.g., standing on the balcony of his apartment for 5 minutes.) is developed together with his therapist. These situations are ordered from “not very scary” to “very scary”. Now he is to try independently at home to seek out and endure one of these situations. Afterwards, the app uses a questionnaire to record how the patient felt in the situation. Based on this data, the therapist decides on a weekly basis when is the right time to increase the level of difficulty.

We start with rule 11:

The app provides information that influences therapeutic decisions. We could argue that neither death nor irreversible or serious harm can result from these decisions. Accordingly, the product would be classified as class IIa.

Since no other rule applies, the app remains in Class IIa.

It could also possibly be argued that therapy recommendations could place the patient in a hazardous situation that could cause death (e.g., a steep cliff of a mountain). Thus, the product would fall into Class III. However, we explicitly decide not to make such recommendations in the app here. However, this shows well the scope for argumentation in the classification of a medical device.

Case study 2: App for therapy after a heart attack

They have developed an app that monitors a patient’s cardiac performance at home after a heart attack, once treatment has been completed. Based on the readings, the app informs the patient when it is necessary to take a vital medication and when to return for follow-up care.

We start with rule 11:

The app monitors vital physiological processes (cardiac output). Accordingly, the app would be a Class IIb medical device.

We also need to look at the other rules to see if a stricter rule needs to be applied as well.

In Rule 22, we see:

Your app adapts the therapy and decides for itself which therapeutic measures are necessary. In this way, it influences patient management.

Therefore, your product would fall into risk class III, because the strictest rule is always applied.

Caution: With both examples, it would certainly be possible to spend an entire afternoon discussing whether these assessments are ultimately correct. It is important for us here to give you some tangible examples for further understanding. A crystal clear classification into one class is not always possible, because the law can be interpreted in different ways. So there is room for argumentation. Therefore, enjoy these assessments with caution.

Who makes the final decision?

You.

The decision as to whether software is a medical device is made by the manufacturer. The classification into a risk class is also made by the manufacturer. However, you should proceed conscientiously, because the notified body can prevent certification if the product is incorrectly classified in class IIa or higher.

Find out more about medical device certification here: Approval Certification of Software Medical Devices (MDR)If your device is assigned to risk class I, you do not have a notified body, but here, too, the assigned supervisory authority can point out an incorrect classification and potentially demand that you withdraw your product from the market at a later date.

If you are unsure, it is best to get an expert opinion or third party assessment. The options for this are:

A specialized lawyer who will give you an expert opinion
A regulatory consultant who provides an assessment
the BfArM (unfortunately long response times and therefore hardly practicable)

Note: Neither an expert assessment, nor an expert opinion protects you legally! However, such documents can be decisive in the event of later legal proceedings.

Risk class I, IIa IIb = DiGA?

A Digital Health Application (DiGA) is an app that is prescribed by doctors and psychotherapists and whose costs are covered by statutory health insurance. For an app to be a DiGA, it must fall into risk class I, IIa or IIb. Does that mean that all apps in these risk classes are automatically DiGA? No!

To be included in the DiGA directory, apps must fulfill a thick catalog of requirements. DiGA should optimize care or create structural facilitation for patients. Apps whose users are primarily physicians, for example, are already excluded.

In addition, DiGA must not represent pure primary prevention. However, since risk class I predominantly covers such offers, this is another reason why many apps are exempt from the DiGA regulation. All criteria for a DiGA can be found in this article. Digital medical devices that are currently excluded from the DiGA definition in Germany due to risk class III are now being given a chance in France. You can find out all about DiGA in France in this blog article.

Conclusion

To find the right risk class for your app, it is best to start with rule 11 of the MDR. If your app does not fall into risk class III according to this rule, you should check all other rules again to find out whether a stricter rule should be applied to your product. In addition, it is worth taking a look at the MDCG’s Guidance document to get a feel for the classification of medical software based on further examples.

It is important to know that you, as the manufacturer, make the final decision on the question of the risk class of your product. Be aware of this responsibility and also seek opinions from experts.

If you are planning a medical app, DiGA or DiPA and need support with the development, please feel free to contact us and we will discuss the whole thing together without obligation. We develop medical apps for companies and research institutions on a contract basis.

Further questions? Please feel free to call us (+49 (0) 89 54998380) or send us an e-mail (kontakt@quickbirdmedical.com).

We look forward to hearing from you!