Software as a medical device in light of the new MDR: 12 points of consideration for developers (part 1 of 3).

On May 26, 2021, the time had finally come. More than four years after its adoption, the Medical Devices Regulation (EU 2017/745) (“MDR“) became applicable. The fact that it took so long for the MDR to become applicable was in part due to the corona crisis. As a result, it was decided to delay the applicability of the MDR by one year.

The MDR builds on old rules regarding medical devices (Directive 90/385/EEC and Directive 93/42/EEC). Those old rules were in need of a major overhaul to create, according to recital 1 to the MDR, a “robust, transparent, predictable and sustainable regulatory framework for medical devices which ensures a high level of safety and health whilst supporting innovation.” The goal of the MDR is thus to enhance patient safety and also to ensure that innovative medical devices remain available to patients.

The MDR is much more than the result of simply polishing up two old European directives. The MDR brings change. Especially for developers of medical software (including, among other things, apps). In a series of three in-depth blogs, we will list 12 important points to take into consideration.

Structure of the blog series

In this first blog we focus on two points of consideration: the qualification of software as a medical device and determining the risk class.

In the second blog, we discuss six points of consideration: obligations for manufacturers (the term for software developers used in the MDR), the EU Declaration of Conformity and CE marking, general safety and performance requirements, technical documentation, clinical evaluation, UDI and Eudamed.

In the third blog, we discuss the final four points of consideration: post-market obligations, vigilance (following up on incidents and calamities), the so-called Person Responsible for Regulatory Compliance (“PRRC“) and transitional provisions.

The qualification of software as a medical device

The MDR only applies when a medical device is involved. It is therefore important to first consider the question: when does software qualify as a medical device within the meaning of the MDR? The answer to that question is not always easy to give.

Software qualifies as a medical device if it is intended by the manufacturer to be used, alone or in combination, for human beings for one or more specific medical purposes. Medical purposes include, for example, the diagnosis, prevention, monitoring, prediction, prognosis and treatment of disease, injury or disability.

Software can be stand-alone (that is, software that functions independently) or control or influence another medical device (software that functions by interacting with another medical device). The intended medical purpose described by the manufacturer is (also) relevant for the qualification and classification (see below) as a medical device.

To make it easier in practice to determine whether software is a medical device within the meaning of the MDR, the Medical Device Coordination Group (“MDCG“) has drawn up a guidance document. In the document numerous examples are given and relevant assessment criteria are provided.

For example, software qualifies as a medical device if it:

• directly controls a medical device (for example, radiotherapy treatment software);
• provides decision-advancing information (for example, software that supports the timing of discharge of patients from the ICU or software that supports the pre-operative screening of a patient and helps determine whether a patient should be seen in the hospital prior to surgery); or
• provides support to healthcare professionals (think of software that allows ECG images to be better interpreted).

At the same time, not all software used in healthcare qualifies as a medical device. For example, software that is used for “simply” searching, storing, archiving or exchanging patient data is not a medical device. Also, software that is only intended for lifestyle and wellness purposes (and not for medical purposes) does not qualify as a medical device.

Where the software “runs” (e.g., as a Software-as-a-Service (“Saas“) solution in the cloud, locally on a computer (on premise) or cell phone) and the existence of the risk of harm to patients or users of the software does not affect the qualification of software as a medical device.

In summary, software intended to process, analyze, create or modify medical information for a medical purpose determined by the manufacturer (diagnosis, prevention, prediction or treatment of injury, impairment or disease) is a medical device within the meaning of the MDR. Once it has been determined that software is a medical device, the next step is to determine which risk class the software falls into. The higher the risk class, the more obligations the MDR imposes on the manufacturer.

Risk class

Once it has been established that the software is a medical device, the risk class must be determined. This is done by the manufacturer. The classification rules are included in Annex VIII of the MDR. There are four classes of risk: I (the lightest risk class), IIa, IIb, and III (the most severe risk class). The risk class determines, among other things, whether it is possible to self-certify the medical device (risk class I) or whether a notified body must be involved (risk classes IIa, IIb, and III).

The purpose intended by the manufacturer and the inherent risks are decisive in determining the risk class to which the software belongs. In addition, the (possible) impact of the medical device on the health of the patient is important in determining the applicable risk class. As a starting point, the strictest classification rule applies. In case of doubt or borderline cases, the software should therefore be assigned to the higher risk class.

Software that generates information used in making decisions for diagnostic or therapeutic purposes belongs in principle to risk class IIa. If the decisions made on the basis of the information generated can lead to a serious deterioration of a person’s health condition or a surgical procedure, the software falls into (the higher) risk class IIb. If the decisions can lead to death or irreversible deterioration of the patient’s health condition, the software falls into the highest risk class (III). In other words, both the importance of the information in making decisions by healthcare professionals and the health condition of patients being treated play a role in determining which risk class the software falls into.

Software that measures physiological processes will often have a diagnostic or therapeutic purpose and for that reason fall in risk class IIa. If the software measures vital physiological processes that can lead to immediate danger for the patient (such as breathing, heart rate, blood pressure, body temperature), then the software falls into risk class IIb. An example is a mobile app that measures (deviations in) the heartbeat, informs the healthcare professional about the (deviations in) the heartbeat on the basis of which the healthcare professional (partly) bases his diagnosis or treatment.

All other software – that is not used for diagnostic or therapeutic purposes or to measure (vital) physiological processes – falls under risk class I. The MDCG guidance document gives as an example an app that is intended to support conception by calculating the woman’s fertility status using (health) data provided by the woman and based on a validated statistical algorithm.

Does the software control or influence the use of another medical device, then the software falls into the same risk class as that medical device. Stand-alone software is considered an active medical device for which the classification rules must be followed separately to determine the risk class.

Under the MDR, the risk classes have remained unchanged. The classification rules, however, have become stricter. As a result, medical software that fell into risk class I under the old rules may fall into a higher risk class (with associated rules) under the MDR. For example, software that generates information to support medical decision making and for diagnostic and therapeutic purposes often fell into risk class I under the old rules. Under the MDR, this software falls (more) quickly into risk class IIa or higher. For manufacturers of medical software who were already placing there device on the market and putting it into service before May 26, 2021, and then fell into risk class I, it is therefore important to pay attention.

It is also important to pay attention when new functionalities are added to existing software. As a result of these new functionalities, the software may fall into a higher risk class. It is good to keep this in mind when developing software.

Conclusion

The obligations for manufacturers under the MDR are more numerous and far-reaching than under the old directives. For example, we discussed in this blog that:

• the definition of medical device has been expanded so that more software qualifies as a medical device;
• software falls more quickly in a higher risk class, with the corresponding obligations; and
• numerous additional (information) requirements for manufacturers have been added, both prior to placing the medical device on the market and afterwards (which are the subject of the second and third blog in this series).

In addition, the rules in the MDR apply to all medical device manufacturers. Medical device manufacturers that complied with the old rules must take action to ensure that their medical device also complies with the new rules in a timely manner (we will address the so-called transitional rules in the third blog). For software developers who are currently developing medical software, it is important to start taking into account the obligations of the MDR during the design process. Moreover, for all manufacturers of medical devices, there is now an obligation to continuously monitor and control the safety and quality of the software during its entire life cycle.

Want to know more?

Would you like to know more about the MDR, or advice on what the MDR specifically means for you or your organization? Please contact Huub de Jong or Marijn Rooke