Go to Client Portal
NAMSA

MDCG 2023-4: Medical Device Software (MDSW) – Hardware Combinations

MDCG 2023-4 (“Medical Device Software (MDSW) – Hardware combinations, Guidance on MDSW intended to work in combination with hardware or hardware components”) was published in October 2023 to address the regulatory compliance of Medical Devices Software (MDSW) applications (Apps) that run on commercially available, off-the-shelf hardware such as smartphones and watches.

Many App designers want to claim a medical purpose but fear the regulatory burden, and in recent years, we have seen medical device functionality applied to smart watches, such as Irregular Rhythm Notifications as part of heart rate monitoring.

In this blog, we assess if this new guidance lessens the regulatory burden and clarifies the route to conformity for medical device Apps.

The following tables provide a graphical summary of the software and hardware combinations covered by the guidance.

A.      External hardware component providing input data to an MDSW app.
1)      The same manufacturer produces the App and Sensor.
Off-the-shelf Smart Device Medical Device Software running on the Smart Device Sensor connecting to the Smart Device
Manufacturer X Manufacturer X

2)      Different manufacturers produce the App and Sensor.
Off-the-shelf Smart Device Medical Device Software running on the Smart Device Sensor connecting to the Smart Device
Manufacturer Y Manufacturer X

 

B.      Hardware components incorporated within Smart Device.
1)      The same manufacturer produces the Smart Device and the App.
Off-the-shelf Smart Devices with built-in sensors, e.g., heart rate, ECG, SpO2, motion, etc. Medical Device Software running on the Smart Device and utilizing the sensors embedded within the Smart Device.
Manufacturer Z Manufacturer Z
2)      Different manufacturers produce the Smart Device and the App.
Off-the-shelf Smart Devices with built-in sensors, e.g., heart rate, ECG, SpO2, motion, etc. Medical Device Software running on the Smart Device and utilizing the sensors embedded within the Smart Device.
Manufacturer Z Manufacturer D

In all the examples presented above, the MDSW cannot achieve a medical purpose without the hardware components (i.e., the Smart Devices and Sensors).

To qualify as MDSW, the manufacturer must claim a medical purpose and comply with the EU Medical Device Regulation (MDR). An example of an MDSW medical purpose may be using a Smart Watch’s EEG monitoring capability to diagnose heart arrhythmias. The manufacturer must demonstrate that the MDSW and the hardware meet the MDR performance and safety requirements.

The guidance provides three compliance options as follows:

  • Option 1 – The hardware or hardware component is placed on the market as an accessory to the MDSW.
  • Option 2 – The hardware or hardware component is placed on the market as a medical device in its own right.
  • Option 3 – The hardware or hardware component is an integral part of the general consumer product, is not a medical device or accessory to a medical device and has no medical purpose.

What does this mean in practical terms?

Options 1 and 2 – The MDSW and the hardware qualify as medical devices or accessories to medical devices. Therefore, they must all meet the applicable requirements of the MDR, including Annex I general safety and performance requirements. The guidance goes on to state:

As the hardware or hardware components 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 [General Safety and Performance Requirements], when used in line with its intended purpose, under the intended normal conditions of use.

So, if the Smart Device complies with the MDR (CE-marked as a medical device), the manufacturer can leverage this. However, third-party, off-the-shelf Smart Devices are unlikely to meet the requirements of the MDR. Therefore, in practice, Options 1 and 2 are only suitable for MDSW manufacturers, who are also the legal manufacturers of, or have substantial control over, the hardware design and manufacture.

Option 3  – This option cites Article 22 System and Procedure Packs—specifically Clause 4, which states that a system or procedure pack incorporating devices that do not bear the CE mark shall be treated as a device in its own right and subject to the relevant conformity assessment procedures per Article 52.

The guidance continues to convey that the manufacturer must establish and document a risk management plan for the MDSW and the hardware that may impact the MDSW’s safety and performance. However, the guidance does not say that the hardware has to meet the relevant requirements of the MDR, only that the manufacturer must have clinical evidence for all intended configurations (all Smart Device platforms) and establish a suitable post-market surveillance (PMS) system for the MDSW and the hardware.

Thus, it can be assumed that as long as the MDSW manufacturer has carried out a risk assessment and has the relevant controls in place, off-the-shelf third-party Smart Devices do not have to meet the relevant GSPRs of the MDR., e.g., the off-the-shelf third-party Smart Devices don’t have to be submitted for electrical safety and electromagnetic compatibility (EMC) testing because the MDSW utilizes its hardware and sensors as long as the manufacturer’s risk management justifies the decision.

If this is the case, there is a route to compliance for MDSW that runs on third-party, off-the-shelf Smart Devices via Article 22, and MDSW manufacturers are encouraged to pursue it with their Notified Body.

The use of Article 22 seems to be an excellent pragmatic approach for MDSW for MDR, and it will be interesting as submissions begin to see how this route is applied and becomes more common with Notified Body feedback.

It should also be noted that Article 22 is also referenced in Option 2 (a). However, in this context, it relates to the hardware or hardware component being placed on the EU market as a medical device.

Overall, although the MDCG requires detailed scrutiny to determine the pathway for compliance for Apps that run on commercially available hardware such as smartphone and watches, it is a welcomed guidance that may provide pragmatic solutions via the use of Article 22.

How Can NAMSA Help?
NAMSA is the industry leader in driving successful regulatory outcomes through effective interactions with the EU Commission and Notified Bodies. Our internal teams of medical device and IVD development experts communicate with EU entities nearly every day and are the most experienced in industry at accelerating regulatory submissions and approvals for manufacturers. In fact, many of our Associates have previously held positions within these organizations, which provides Clients the benefit of a clearer understanding on how to proactively plan for international requirements and expectations.

NAMSA’s extensive MDR expertise, including specialized software knowledge, can help navigate your route to MDR compliance. To learn about NAMSA’s full suite of Regulatory and Quality services and solutions, please visit: https://namsa.com/services/regulatory-and-quality-consulting/.

Or, if you are interested in meeting with one of our regulatory experts, please visit: https://namsa.com/namsa-expertise/subject-matter-experts/.

Paul Risborough

Paul Risborough

Paul Risborough holds the position of Principal Regulatory Consultant at NAMSA. Until recently, Paul worked as the Global Head of Active Implantable Medical Devices at BSI, Notified Body, overseeing the Medical Device compliance of Active Implantable Medical Devices. Before becoming a Manager at BSI, Paul was an Active Implantable Device Technical Specialist, Scheme Manager and ISO 13485 Auditor. Previously, Paul worked as an electronics design engineer, project leader, and engineering manager involved in designing and manufacturing syringe pumps, large volume pumps; RF, ultrasonic, and gas plasma surgical tools; needle-free injectors, and SpO2 meters. Paul has an education in Systems Engineering, BEng (Hons).