Tree Model for Classification

Medical Device Classification: The Software Special

Software for medical purposes is a medical device. Medical devices are strictly regulated and for good reason. They have to be safe and must not harm patients. Therefore, the European Medical Device Regulation (EU MDR) includes a medical device classification according to Art. 51 (1). The classification into risk classes I, IIa, IIb, or III (low to high risk) depends on the intended purpose and the risks associated with the respective software. The risk class has a considerable influence on the subsequent certification by a Notified Body. This also involves the type of conformity assessment, clinical evaluation, or even clinical investigation. It is therefore important to set the right course from the outset. For this, we provide information in this article on how a manufacturer can carry out a medical device classification.

How to Start With Medical Device Classification

At first, the manufacturer must describe the intended purpose of the software and, thus, decide whether the software is a medical device. Determining the intended purpose is thus the necessary prerequisite for a medical device classification. Furthermore, the manufacturer must clarify whether the software is an integral part of a medical device (embedded software), an accessory or a medical device on its own (stand-alone software). We have written an in-depth article on this aspect: “Stand-Alone Software as Medical Device“. There you will find a detailed consideration and examples under which conditions software is a medical device. Embedded software, i.e. software that controls a medical device or influences the use of a medical device, belongs to the same class as the medical device itself (Annex VIII 3.3). This is not the case for stand-alone software and software as accessories. Here an independent classification is made (Annex VIII 3.3). Article 2 (4) EU MDR states (simplified) that an “active device” has an external energy source. Software is also an active device according to EU MDR. Note, however, that active devices are subject to stricter classification rules.

Medical Device Classification of Stand-Alone Software

The assignment of a stand-alone software to a risk class depends basically on its impact on the patient’s health status and on the importance of the subsequent medical decision (Annex VIII 6.3, rule 11). The following figure guides you through the rule 11. The left side shows software for diagnostic and therapeutic purposes and the right side shows software for monitoring of physiological processes.
Rule 11 does not apply to software that controls a medical device but is physically separate from it. This type of software is not considered “independent of another device” despite physical separation (Annex VIII (3.3)).
Monitoring does not only refer to vital processes. Moreover, monitoring can occur over the course of time or can be a measurement against limit values.

How to Apply the Classification Rules?

According to rule 11 software belongs to class IIb if it provides information for diagnostic or therapeutic decisions and, furthermore, such decisions can cause serious deterioration of the patient’s state of health or surgical intervention. Thus, almost all stand-alone software will fall in a risk class higher than I. One of the few examples of a class I software would be a software used to treat aphasia patients. Let’s take a look at a diagnostic medical app as an example. The app can display the probability for a patient’s mole to be a melanoma. For this, the app compares a photo of the mole with a database of diagnosed melanomas. Obviously, this app provides information for the diagnosis of melanoma in humans and, thus, you have to follow the left part of the figure shown above. The app could produce false negative results. In this case, the app would classify the mole as benign and the attending physician would not use skin cancer therapy. In the most serious case, this could lead to the death of the patient. Therefore, such an app corresponds to risk class III.
Rule 11 does not differentiate between an application of the software by a lay person or a professional user. Therefore, software products for self-diagnosis often assigns to class IIa.
Another example: A medical app tracks sleep depth, duration and quality using data from a smart-watch. The attending physicians use the app to monitor a patient’s sleep apnea syndrome. With this example of software that monitors a physiological process, you need to follow the right part of the figure above. If the app were to measure or transmit the patient’s vital signs incorrectly, the health risk to the patient would obviously be low. The software belongs to risk class IIa.

What Have You Got to Do now?

Finally, check the following points for medical device classification:
  • Is your software a medical device on its own (stand-alone) or part of a medical device (embedded)?
  • Have you carried out a risk classification according to Art. 51 and Annex VIII?
  • Have you documented the “risk class of the device and the justification for the classification rule(s)” in the technical documentation (Annex II (1.1.f))?
  • If your software is already on the market: does the risk class change according to the EU MDR?
  • For medical devices of class IIb or III: Have you taken sufficient account of the additional work involved in clinical evaluation and conformity assessment, including the involvement of a notified body?
  • In the case of class III medical devices: have you examined the possibility that a clinical investigation is necessary because the use of clinical data of equivalent medical devices under the EU MDR (Art. 61) has been significantly impeded?
We recommend to monitor the implementing legislation of the EU commission.

Write a comment or suggest a term!

Your email address will not be published. Required fields are marked *