New European Guidance Clarifies Medical Device Software Requirements

By Annette Van Raamsdonk

The European Commission (EC) and the Medical Devices Coordination Groups (MDCG) tried to tackle the ongoing confusion on medical device software and hardware compatible with or embedded with the software. This new guidance addresses medical device software compatible with or embedded in hardware devices (such as smartphones, smartwatches or apps that are required to be installed on those watches/phones) as well as standalone medical device software. The guidance does not address aspects related to clinical evaluation and cybersecurity. Guidance on cybersecurity and guidance on clinical evaluation (MDR) / Performance evaluation (IVDR) of medical device software are given respectively in MDCG 2019-16 and MDCG 2020-1.

What is the guidance about?

MDCG 2023-4 provides examples and clarifications on which requirements apply when hardware or hardware components incorporate and collect data, which serves as input for the software. And more importantly, it describes how these devices are regulated, according to the Medical Device Regulation (EU) 2017/745 (MDR)/In Vitro Medical Devices Regulation (EU) 2017/746 (IVDR) or as “wearable digital product” devices.

Several examples are provided, giving different options for placing a combination of hardware and software on the market. Taking into account that there are quite often two or more manufacturers of software, claiming compatibility with the hardware of several other manufacturers. Below we will summarize two out of the four examples given by the EC.  

Hardware or hardware components working in combination with MDSW

Most apps that you can download rely on input data received from the smartphone, smartwatch, or other hardware device, such as a sensor containing a patch placed on the skin (amongst others used in diabetic care). We share two examples below of what applies in different situations.

Example 1.

There is a single manufacturer (X) that places on the market a patch with a sensor (hardware) and software that uses input data from the patch.

The patch is intended by X to collect data related to the patient’s physiological parameters such as body temperature and heart rate. The software, downloaded on a smartphone, is intended by X to calculate, process, and analyze the input data collected via the sensor in the patch. The outcome (output) of the analysis is provided to the patient and the patient can decide to directly transmit the output to a healthcare provider.

In the situation above, the software and hardware cannot work without each other. The manufacturer must claim a medical purpose for the software to qualify as a medical device (Article 2 (1,2) MDR). The software and the patch are required to be compliant with the MDR.

The hardware or hardware component is placed on the market as a medical device either:

1. as part of a system according to article 22 MDR
2. as a combination with another medical device according to article 2 (1) or
3. as an integral part of a medical device

The smartphone is just the medium that displays, in this case, the outcome. As such, the smartphone isn’t covered by the MDR.

Here, the manufacturer must verify, validate and confirm that the interaction between software and hardware or hardware components produces safe and functional medical device software.

Example 2.

In many cases, there are two manufacturers. Manufacturer X only places on the market the patch (with or without its own software). Manufacturer Y decides to market software that has a medical intended purpose and is claimed to be compatible with the patch of X and similar patches.

In this case, manufacturer Y claims its software is compatible with a range of patches from different manufacturers. Manufacturer Y needs to provide evidence and verify, validate and prove the compatibility between the software and all types of hardware. And that the combination of the two devices leads to an effective, safe, and performant medical device software.

Outcome and regulatory requirements

There are three options for how manufacturer X can place the devices on the market (taking into account that a medical intended purpose is claimed):

1)    The hardware is an accessory to the software. Both devices are classified in their own right.

2)    The software is a medical device, and the hardware is placed on the market:

a.    As a part of a system, according to Article 22 MDR

b.    As a combination with other medical devices according to Article 2(1) or

c.     As an integral part of a medical device (the hardware would be a component/part of a medical device)

3)    The hardware is an integral part of a general consumer product (i.e., a smartwatch) and is not a medical device or an accessory to a medical device. In this situation, no medical intended purpose can be claimed. The software itself, downloaded on the hardware, is qualified as a medical device.

Once the qualification of the hardware and software are determined, these would fall within the scope of the MDR, and the manufacturer(s) should be compliant prior to placing the devices on the European Union (EU) market.

For points 1 and 2 above, this implies that the manufacturer of the software must “verify, validate and demonstrate the safety, reproducibility, compatibility and interoperability of the medical device or accessory to a medical device that the software works in combination with, including all various configurations and variants. The clinical evaluation of the software has to be considered in view of the intended medical purpose achieved in combination with the medical device or accessory to a medical device.”

The software manufacturer may rely on the hardware for compliance with the MDR since the hardware is a medical device accessory (Article 2(2) MDR).

In the above-described point 3, the hardware is not a medical device accessory, but a consumer product. As such, the hardware does not (need to) comply with the MDR. Therefore, the software manufacturer cannot rely on compliance of the hardware with the MDR. Therefore, the software manufacturer becomes responsible “for the safety, performance and reproducibility of the hardware or hardware component in its combined use with the software in all intended configurations.”.

Additionally, the guidance gives a summary of regulatory requirements that need to be fulfilled by the manufacturers of the software.

Conclusion

When developing or planning to place software on the market, the first step is to determine the qualifications of the software and the hardware it is used with. Once the qualification of the software and hardware are determined, the manufacturer(s) can start looking into regulatory pathways on how to show compliance with the MDR and which conformity assessment route can be taken.