How to get wearables and companion apps regulatory approved

Wearable devices, such as bracelets, patches, smartwatches, and virtual reality goggles are taking centre stage in the digital healthcare revolution. In this article, we take a look at how wearables and associated apps are regulated in the EU.

Wearable medical devices rely on components like sensors and cameras to collect health or biometric data. This data is then processed and analysed by medical device software, typically in a smartphone app, to prevent, predict, or manage various medical conditions, making them a medical device by definition. However, the interplay between hardware, software, and medical purposes raises important questions regarding their regulation, especially if different manufacturers are making the wearable and the app.

To address these issues, the Medical Device Coordination Group (MDCG) has released new guidance. This guidance aims to clarify the regulatory considerations when wearables are part of the medical device software ecosystem, depending on who manufactures which component, and what each component is intended to do. This helps provide clarity to developers wanting to know - “Is my app or wearable a medical device, or is it an accessory, or a non-medical device?”

Wearables and App Combinations

Wearable devices and their associated apps use hardware components to collect and process medical information intended for diagnosis, treatment or monitoring of diseases or conditions. The wearable serves as the input device and the app serves as a processor of the data. The wearable may also control the app, and vice versa.

To illustrate this, the MDCG lays out example scenarios where a stand-alone wearable (like a blood glucose monitor or dermal patch) and an app are either manufactured by the same company or different companies. Alternatively, the wearable could be something like an Apple watch which has a hardware component within it that measures biometric data. Either Apple or a third party can make an app that reads and processes that data.

Configuration	Who makes the wearable?	Who makes the app?	Your regulatory options
Stand-alone wearable (with medical purpose) + app (with medical purpose)	You	You	Your wearable can be an accessory to your medical device app OR Your wearable can be a medical device as part of a system including your app according to article 22
	You	Someone else	Your wearable is a medical device in its own right
	Someone else	You	Your app is a medical device as a combination with another medical device according to article 2(1), or part of a system according to article 22
Sensor component within a consumer wearable (no medical purpose) + app (with medical purpose)	You	You	Your app is a medical device combined with another product according to article 22(4) OR Your app is a medical device as part of a system including your wearable according to article 2(1)
	You	Someone else	The sensor/wearable is not a medical device
	Someone else	You	You 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)

Regulatory Considerations

Any app or wearable combination that is intended for a medical purpose is a medical device. This guidance is therefore aiming to clarify which components of a wearable/app combination are subject to the medical device regulations.

The MDR states that a medical device's intended purpose can be achieved either alone or in combination with other medical devices or accessories. That means that an app can be a medical device whether it’s working with a wearable which is also a medical device, or a wearable which is not a medical device, i.e. an accessory.

It’s important to understand the definition of an accessory here, under article 2(2) of the MDR 2017/745:

“Accessory for a medical device” means an article which, whilst not being itself a medical device, is intended by its manufacturer to be used together with one or several particular medical device(s) to specifically enable the medical device(s) to be used in accordance with its/their intended purpose(s) or to specifically and directly assist the medical functionality of the medical device(s) in terms of its/their intended purpose(s)”

In most of the scenarios outlined above, both the app and the wearable cannot achieve their medical purposes independently. Therefore the developers need to verify, validate and prove that the interaction between their app and the wearable leads to an effective, safe and performant medical device as a system.

Finally, in the example of a wearable containing a sensor that is not a medical device, we must also take into consideration the definition of embedded software in IEC 82304-1:2016:

Health software that is intended to run on dedicated hardware is to be considered as part of a physical device, sometimes also called "embedded" software. Such software is not considered a product in its own right. This holds true for software in a product that is regulated as a medical device as well as for software that is part of a specific physical device which is not regulated as a medical device.

Manufacturers of apps that use third party wearables will also need to take into account any susceptibility to unintended influence by other software using the same hardware resources, as well as additional privacy and security requirements addressing areas such as authorised use, person authentication, health data integrity and authenticity, and protection against malicious intent.

Placing on Market

There are three options for placing wearable/app combinations on the market:

Option 1: The wearable is marketed as an accessory to the app which is regulated as a software medical device.

Option 2: The wearable is marketed as a medical device, either as part of a system, in combination with another medical device (the app), or as an integral part of a medical device (wearable + app combined).

These options are fairly straightforward. The app manufacturer can rely on the wearable's regulatory compliance when used as intended.

Option 3: The hardware component is an integral part of a general consumer product or wearable digital product, with no intended medical purpose.

Here it gets trickier since the app manufacturer cannot rely on the wearable's regulatory compliance since the wearable is not intended to be a medical device, and as such the supplier will not necessarily be able to provide the medical device manufacturer with documentation to demonstrate compliance with medical device regulations. In this scenario, the app developer becomes responsible for ensuring the safety, repeatability, reproducibility, performance and cybersecurity of both their app and the hardware component in all intended configurations.

This will involve extensive testing to demonstrate clinical evidence for all configurations, and detailed documentation of which versions of the hardware wearable, and its software components, such as application programming interfaces (APIs) and human-machine interfaces (HMIs), are compatible with the app. This includes the need to establish and implement robust risk management and post-market surveillance processes that ensure effective monitoring of the wearable’s safety, performance and cybersecurity.

Conclusion

The new MDCG guidance for wearable medical devices helps us to focus on considerations in architecting and documenting software-hardware combination medical devices. It outlines the regulatory considerations and provides options for manufacturers to ensure the safe and effective use of wearable medical devices and their associated apps. As technology continues to advance, this guidance will be invaluable for manufacturers and regulators alike, ensuring the highest standards of safety and performance in the rapidly evolving world of wearable medical devices.

Hardian Health is a clinical digital consultancy focused on leveraging technology into healthcare markets through clinical strategy, scientific validation, regulation, health economics and intellectual property.