MDCG 2023-4 Rev.0
Medical Device Software (MDSW) – Hardware combinations
Guidance on MDSW intended to work in combination with hardware or hardware components
Disclaimer: This document is an interactive version of the original MDCG document. We will keep it up-to-date.
This document has been endorsed by the Medical Device Coordination Group (MDCG) established by Article 103 of Regulation (EU) 2017/745. The MDCG is composed of representatives of all Member States and it is chaired by a representative of the European Commission.
Table of Contents
1) Introduction
Software has become an increasingly important part of the medical device landscape. It is estimated that one in four medical devices either incorporate medical device software (MDSW) (1) or are MDSW in their own right. With the broad public use of smart phones and wearable digital products, certain MDSW make use of a broad range of technologies in order to fulfil their intended purpose. This use has enabled patients and clinicians to engage with health information in an unprecedented manner.
In many cases, MDSW can only achieve its intended purpose when it is used in combination with a hardware (2) or hardware component (e.g., sensor) generating or providing input data. For example, MDSW downloaded or available on wearables (e.g. bracelets, smartwatches, virtual/augmented reality goggles) to prevent, predict or manage a disease, achieve their intended purpose by receiving and analysing data provided by a hardware or hardware component. In these cases, relevant hardware often incorporate components such as sensors and cameras, the information from which may be used in a variety of MDSW, including so-called medical device applications (MDSW apps).
Sensors or other hardware components are in certain cases integral parts of general-purpose consumer electronics or wearable digital products. The interaction between the MDSW, hardware or hardware component (in particular integrated sensors) raise the question regarding the qualification and the appropriate regulatory pathway or conformity assessment of these hardware or hardware components.
2) Scope
Through the provision of information and/or signals, these hardware or hardware components play an essential role in contributing to the medical purpose of certain MDSW. It is important to consider how the manufacturer of the MDSW has to demonstrate conformity with the applicable regulatory requirements for the combination of the MDSW and the concerned hardware or hardware components.
This guidance intends to examine and provide clarifications on which specific regulatory considerations apply when the hardware or hardware component incorporating the data collection element (camera, electrical/optical sensors etc.) are a medical device or an accessory to a medical device. This guidance also outlines scenarios where the hardware or hardware component incorporating a data collection element are not medical devices or accessories to a medical device. This guidance does not intend to elaborate on aspects related to the clinical evaluation or cybersecurity for these products, as those are tackled in other guidance. (3)
3) Hardware or hardware component working in combination with MDSW
Many MDSW apps create diagnostic or therapeutic medical information by processing data or signals derived from hardware or hardware components. Those hardware or hardware components act as input and may also act as controls for the MDSW. Typically, both require a computing platform and/or an energy source to perform as intended which may be provided by for example, a smartphone. The intended medical purpose of such MDSW apps can only be achieved through the use of hardware or hardware components that demonstrate sufficient performance, accuracy and reliability, in light of the MDSW’s intended purpose and the state of the art. This section intends to describe, for illustrative purposes, different examples of how MDSW and hardware or hardware components work in combination to achieve a medical purpose and how they may be placed on the market.
A. External hardware component (e.g. sensor embedded in a dermal patch) providing input data to a MDSW app
1) Manufacturer of hardware component and MDSW app are the same entity
(4)
Example: Manufacturer X places on the market a dermal patch that incorporates a sensor intended to collect and relay data correlated to the user’s physiological parameters such as body temperature, oxygen saturation (SpO2) and heart rate. Upon purchase of the dermal patch, users download the MDSW app also placed on the market by Manufacturer X on a smartphone and connect the two (patch and smartphone app). Based on the sensor’s input data, the MDSW app calculates, further processes and analyses physiological parameters and other medical information about the user. The MDSW app may also provide the possibility to have the user’s collected data directly transmitted to a healthcare professional. The app displays the monitored medical information and conducted analysis to the user and/or may transmit this information directly to the healthcare professional.
2) Manufacturer of hardware component and MDSW app are different entities
Example: Manufacturer X places on the market a dermal patch that incorporates a sensor intended to collect and relay data correlated to the user’s physiological parameters such as body temperature, oxygen saturation (SpO2) and heart rate. Manufacturer Y places on the market a MDSW app claimed to be compatible with the dermal patch of manufacturer X (or claimed to use input data provided by patches or sensors similar to the patch of Manufacturer X). Collected data by the sensor are transmitted to the smartphone MDSW app for further analysis and calculations. The MDSW app may also provide the possibility to have the user’s collected data directly transmitted to a healthcare professional. The MDSW app displays the calculated and monitored physiological parameters and conducted analysis to the user and/or transmits this information directly to the healthcare professional.
B. Hardware component incorporated within a smartphone or wearable connected to a MDSW app on smartphone or wearable
1) Manufacturer of hardware component incorporated within a wearable and MDSW app are the same entity
Example: Manufacturer Z places on the market a wearable (e.g., watch) that incorporates a sensor that is intended to collect and relay data correlated to the user’s physiological parameters such as body temperature, oxygen saturation (SpO2) and heart rate. Upon purchase of the wearable, users are prompted to download (or activate) MDSW app also placed on the market by Manufacturer Z on their smartphone and/or wearable.
Based on the sensor’s input data, the MDSW app calculates, further processes and analyses physiological parameters and other medical information about the user. The MDSW app may also provide the possibility to have the user’s collected data directly transmitted to a healthcare professional. The app displays the monitored medical information and conducted analysis to the user and/or may transmit this information directly to the healthcare professional.
2) Manufacturer of wearable and MDSW app are different entities
Example: Manufacturer Z places on the market a wearable (e.g. watch) that incorporates a sensor intended or capable of collecting and relaying data correlated to the user’s physiological parameters such as body temperature, oxygen saturation (SpO2) and heart rate. Users can download a variety of MDSW apps placed on the market by different MDSW app manufacturers. Manufacturer D claims that their MDSW app achieves its intended medical purpose through receiving data from the sensor integrated in the wearable placed on the market by Manufacturer Z.
4) Regulatory considerations
In accordance with Article 2 of the MDR, the intended purpose of a medical device can be achieved either alone or in combination with other medical devices or accessories for a medical device. From the examples provided under sections 3.A and 3.B, it is evident that the MDSW and the hardware or hardware component are not able to achieve a medical purpose on their own. In order for the software to be qualified as a medical device, the manufacturer must claim a medical purpose and consequently provide evidence that the device in question is in compliance with the MDR. This includes the need to verify, validate and prove that the interaction between the MDSW and the hardware or hardware component leads to an effective, safe and performant MDSW.
There are several options for how devices or MDSW and other products requiring interaction to achieve the intended medical purpose can be placed on the market:
Option 1: the hardware or hardware component is placed on the market as an accessory to a MDSW. (5)
Option 2: the hardware or hardware component is placed on the market as a medical device either
a) as part of a system according to article 22 MDR or
b) as a combination with another medical device according to article 2(1), or
c) as an integral part of a medical device.
Option 3: the hardware or hardware component is an integral part of a general consumer product or wearable digital product and is not a medical device or an accessory to a medical device and has no intended medical purpose.
5) Placement on the market
The options listed below are applicable to the scenarios outlined in Sections 3.A and 3.B.
Options 1 and 2:
For options 1 and 2, the MDSW and the hardware or hardware component are qualified as either a medical device or an accessory to a medical device.
As such, manufacturers of MDSW must demonstrate compliance with the MDR, including e.g. MDR Annex I on general safety and performance requirements (GSPRs). Of specific importance, the MDSW manufacturer must verify, validate and demonstrate the safety, reproducibility, compatibility and interoperability of the medical device or accessory to a medical device that the MDSW works in combination with, including all various configurations and variants. The clinical evaluation (6) of the MDSW has to be considered in view of the intended medical purpose achieved in combination with medical device or accessory to a medical device. As the hardware or hardware component are medical devices or accessories to a medical device, the MDSW manufacturer may rely on the compliance of that hardware or hardware component with the MDR, in particular compliance with the GSPRs, when used in line with its intended purpose, under the intended normal conditions of use.
In terms of risk management and post-market surveillance, the MDSW manufacturer must establish and implement appropriate communication channels to ensure efficient notification mechanisms regarding changes or incidents related to the medical device hardware, hardware component or accessory.
Option 3:
In option 3, the MDSW manufacturer is not able to rely on the compliance and conformity of the hardware or hardware component with the MDR. In this case, it is not sufficient to verify the safety, performance, reproducibility, interoperability and compatibility. Moreover, the MDSW manufacturer becomes responsible for the safety, performance and reproducibility of the hardware or hardware component in its combined use with the MDSW in all intended configurations. The MDSW manufacturer must comply with the requirements under equivalent conditions to a situation where a manufacturer is combining a medical device with another product according to Article 22(4). (7)
The MDSW’s technical documentation must clearly identify and describe all other products (e.g., hardware or hardware component which are not qualified as a medical device or accessory to a medical device) that are intended to be used in combination with it. As part of the risk management, the MDSW manufacturer must establish and document a risk management plan for both the MDSW and the hardware or hardware component that may have an impact on the MDSW’s safety and performance. In addition, the MDSW manufacturer must demonstrate clinical evidence for all intended configurations (e.g., all platforms the MDSW is running on).
As part of the post-market surveillance system, the manufacturer of the MDSW has to actively and systematically monitor and assess all information from the market throughout the entire lifetime of the MDSW, as well as for the hardware or hardware component which may have an impact on the safety, performance, reproducibility, interoperability and or compatibility of the MDSW. The MDSW manufacturer has to put in place and implement adequate controls, by which the proper function of the hardware or hardware component can be monitored. Any identified risks pertaining to the hardware or hardware component must be appropriately mitigated. This is to ensure that the MDSW, in combination with the hardware or hardware component is safe and performant. For example, the MDSW manufacturer must assess and control the risk of hardware and hardware component malfunctions and use errors, monitor the proper functioning of the hardware, apply risk controls such as inherent safety by design.
Footnotes
(1): For more detailed information regarding software qualification and classification, refer to MDCG 2019-11.
(2): For the purposes of this document, hardware should not be understood to include desktop PC or cloud computing platform (server).
(3): MDCG 2020-1 on Clinical Evaluation (MDR) / Performance Evaluation (IVDR) of Medical Device Software; MDCG 2019-16 on Cybersecurity for medical devices.
(4): Reference to patch in this document refers to medical patches, not software patches.
(5): Where the risk classification of the hardware or hardware component follows Annex VIII of the MDR.
(6): MDCG 2020-1 on Clinical Evaluation (MDR) / Performance Evaluation (IVDR) of Medical Device Software.
(7): Article 22(4): where the system or procedure pack incorporates devices which do not bear the CE marking or where the chosen combination of devices is not compatible in view of their original intended purpose, or where the sterilisation has not been carried out in accordance with the manufacturer’s instructions, the system or procedure pack shall be treated as a device in its own right and shall be subject to the relevant conformity assessment procedure pursuant to Article 52. The natural or legal person shall assume the obligations incumbent on manufacturers.