Software in the medical device field - definition and risk classification according to the MDR

The image that pops into mind when hearing the term “medical device” often has something to do with physical devices or machines, such as x-ray machines or pacemakers. In addition to these, however, software is an increasingly important part of the medical device spectrum, both as stand-alone devices and as part of other devices. As with all medical devices, the requirements of the EU Medical Devices Regulation (MDR) apply to software as a medical device. The regulatory requirements can affect the path to market and lifecycle operations of a software product. Therefore, it is important to determine whether your software is a medical device according to the MDR and which risk class it has.

Health care utilizes a wide variety of software products

The scale of software related to modern health care is vast: almost every workflow and procedure utilizes some kind of software. Software can be used by health care professionals or laypersons, such as patients or consumers. Software can be developed for example as mobile applications, cloud services, as a part of another device, or as a stand-alone system.

Examples of health care software applications include symptom assessment and monitoring, remote receptions, medical imaging and analytics, decision support, patient information systems, and various applications for care planning – possibilities increase continuously along digitalization and as for example artificial intelligence solutions become more and more common.

Possibilities to utilize software in health care increase along digitalization and for example artificial intelligence solutions.

The possibility to be under influence of the MDR brings some extra spice to health care related software. If this is the case, software must be certified in accordance with the relevant regulatory requirements. Defining whether the software you develop is a medical device is not always an easy task. However, there are ways to succeed in this: this article will help you find the right direction by introducing the criteria and considerations for software definition and risk classification under the MDR.

How to define whether a software is a medical device?

The manufacturer must determine whether the software is a medical device, i.e. whether it is covered by the MDR. The intended purpose of the software assigned by the manufacturer plays a key role in this definition and in risk classification. It is worth noting that not all software used in health care are medical devices. When starting to examine whether your software is a medical device, at least the following questions, among others, need to be considered:

Is the software related to clinical care and what are its target user or patient groups?
What kind of actions does the software make? What information does the software provide? Is it only about display and storage of data, or is inference, analysis, suggestions or even diagnosing included?

The answers to these questions are reflected with the medical device definition stated in the MDR, which can be found in Article 2 of the regulation. Shortly, a medical device is any device or software intended by the manufacturer to be used for human beigns for one or more specific medical purposes. The medical purposes mentioned in the definition include for example diagnosis, treatment, anticipation and control of a disease or an injury.

Software in the medical device field can be roughly divided into two groups:

Software as a Medical Device (SaMD), or in other words, Medical Device Software (MDSW))
Software driving or influencing the use of a medical device

Sofware as a medical device has a medical purpose mentioned in the medical device definition of the MDR: the software is intended to be used for this purpose alone or in combination. Having a medical purpose is definitive in terms of medical device qualification: if there is such a purpose, the software is a medical device regardless of it being independent or driving or influencing a (hardware) medical device. For example a software that calculates medicine dosage or amount of radiation therapy based on measured parameters of a patient’s health status, belongs into this group.

Software driving or influencing the use of a medical device does not perform or have a medical purpose of its own. It also does not create information on its own for a medical purpose mentioned in the medical device definition of the MDR. This kind of software can for example guide a medical device through an interface or it might be an accessory for a (hardware) medical device, in which case the same requirements apply as for a medical device. For example a software application that is only used for displaying MRI or ultrasound images, belongs into this group.

Not all health care related software or modules are medical devices

There is also software in healthcare that is not covered by the medical device regulation. Such software includes software that performs simple search functions, storing and archiving information, or communications such as e-mail, online, and voice messaging. However, be careful: software that processes, analyzes, creates, or modifies medical information may be a medical device.

The structure of software is often modular, meaning that software consists of many separate but interconnected parts. When defining the medical device status of the software, modularity should be considered. This means that a particular software module may be a medical device, while another module has no medical purpose, i.e. it is not a medical device. It is the responsibility of the manufacturer to clearly define the boundaries of the different modules in order to know which software modules are subject to the medical device requirements. It must also be ensured that the non-medical modules do not interfere with the operation of the medical device.

How to do the risk classification of software?

Risk classification is an integral part of determining the path of a product to CE mark and requirements associated with it. The risk classification is based on risk analysis performed for the software. The risk analysis assesses potential risks associated with the software and its use. The purpose of the analysis is to identify the parts of the software that may be related to hazardous situations and to determine their possible causes.

The MDR divides medical devices into four risk classes (I, IIa, IIb and III) according to the intended use of the device and the risks associated with it. The classification shall be made taking into account all the implementing rules listed in Annex VIII of the MDR. The risk classification of software is in particular subject to rule 11 in Annex VIII. According to the rule 11, software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes, is usually classified as class IIa.

However, the risk class can also be higher or lower according to the rule 11. The class is dependent for example on significance of the software output information and potential impact of an (incorrect) decision that was made using the software output information.

The software belongs to class III, if the decision has an impact that may cause death or an irreversible deterioration of a person’s state of health
The software belongs to class IIb, if the decision has an impact that may cause a serious deterioration of a person’s state of health or a surgical intervention

Rule 11 says the following about software that is intended to monitor physiological processes

This kind of software belongs to class IIa, except
If the software is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, the software is classified as class IIb.

All other software is classified as class I, but in practice there is few software left in this category.

Additionally, Annex VIII rules 3.3 and 3.5 say the following

Software, which drives a device or influences the use of a device, shall fall within the same class as the device.
If the software is independent of any other device, it shall be classified in its own right.
If several rules, or if, within the same rule, several sub-rules, apply to the same device based on the device’s intended purpose, the strictest rule and sub-rule resulting in the higher classification shall apply.

In the case where a software has its own medical purpose and also drives or influences use of another medical device, the software should be classified separately. However, the risk class of the software must not be lower than the risk class of the device.

When developing and modifying software and its features, the intended purpose and risk class of the software must be kept in mind. Major changes or additions to functionality may affect the intended purpose and even result in a higher risk classification, which may not be desirable or purposeful.

Tips to succeed in definition and risk classification of software in the medical device field

Carefully read the medical device definition in Article 2 of the MDR.
Utilize also other available sources and examples: for example the MDCG guidance document provides support for qualifying software as a medical device and for risk classification.
Think through the intended purpose of the software. Know what the software does and what information it provides. Risk classification can be affected by narrowing down the intended purpose.
Clearly design the structure of your software and the modules it includes: it is possible that only some of the modules are medical devices.
Write down justification concerning why your software or part of it is a medical device or why it is not a medical device. Justification is particularly important in borderline cases.
Perform a risk analysis for the software: the analysis functions as a basis for the MDR risk classification. The risk analysis also supports specifying the intended purpose.
Continuously foster active communication between software development and regulatory experts to ensure that software functionality is aligned with the risk class

Additional information and sources

Are you interested in this topic?

Get to know our service offering about CE-mark and certification and risk management. If you have any questions, you can also contact us.

Text: Kristiina Mäki, Kimmo Vauhkonen

Software in the medical device field – definition and risk classification according to the MDR