MHRA releases updated guidance on medical device software and apps

United KingdomScotland

On 4 June 2020, the Medicines and Healthcare products Regulatory Agency (“MHRA”) published its updated guidance on medical device stand-alone software, which is intended to clarify the types of software and apps which are likely to be regulated as medical devices in the UK.

The updated guidance sets out new or expanded interpretation on specific types of software, such as clinical calculators or symptom checkers. It also clarifies the MHRA’s interpretation of certain aspects of medical device legislation, for example the concept of software which “drives or influences the use of a device” in the context of third party software intended to be used in connection with other manufacturers’ devices.

These updates provide helpful insight into the MHRA’s approach in this area, recognising the growing importance and accessibility of software and apps in the healthcare sector for both consumers and healthcare professionals.

A summary of the updated content is set out below:

1. Prescribing assistance software

The guidance now includes a reference to the CJEU’s ruling in Snitem v Philips France (C-329/16), from December 2017. That case concerned prescription assistance software for use by healthcare professionals to help issue prescriptions for specific patients by providing an automated analysis of potential contraindications, drug interactions and excessive dosages. The CJEU held that software of this nature would be classified as a medical device.

The CJEU also confirmed that the intention of the legislation is to focus on the purpose of the device, and not the effect it has on the human body. This means there is no need for any action directly in or on the human body in order for software to be considered a medical device.

This case was consistent with the approach already taken in the UK and therefore its addition to the guidance provides helpful clarification rather than a change of approach by the MHRA.

2. Control of conception

The guidance provides additional information on devices intended to control conception, either by facilitating conception or enabling contraception. This area of ‘Femtech’ represents a growing portion of the healthcare technology market, and companies should be aware of the sometimes narrow differences in features which can lead to an app being regulated as a medical device. For example, the updated guidance states that apps which simply track data related to a woman’s menstrual cycle to aid ovulation prediction are unlikely to be considered a medical device.However, an app which facilitates conception based on basal body temperature may constitute medical device functionality.

3. Clinical calculators

The MHRA has released a new appendix on clinical calculators, providing examples of the types of clinical calculators which are likely to be considered medical devices. In this context, the complexity of the calculation undertaken by the calculator is important. Software which performs simple calculations which can be easily verified is unlikely to require CE marking as a medical device. However, if a calculation cannot be easily verified by the intended user, for example because of its complexity or because the calculator uses linked lookup tables which are not displayed to the user, the underlying software is likely to be considered a medical device. This would be the case for software which calculates cardiovascular disease risk scores, for example. MHRA’s expectation is that manufacturers of calculators will have conducted user testing to evidence that the expected user can verify the calculation.

This is in line with the MHRA’s existing approach to “decision support software”, which recognises that software and apps are increasingly being used by healthcare professionals who rely on the output but do not review the raw data. This makes it even more important to ensure that the design and operation of such software is tightly regulated.

4. Classification rules

The risk classification of medical device software is determined by the rules set out in Annex IX of directive 93/42/EEC on medical devices.

Stand-alone software will be classified as either Class I, IIa or IIb, depending on the intended purpose of the device. In particular, software which is intended to “allow direct diagnosis” will fall into Class IIa (unless such software is specifically intended for monitoring vital physiological parameters, where the nature of variations is such that it could result in immediate danger to the patient, in which case it will be Class IIb). Further detail is given on what it means to “allow direct diagnosis” in the context of software. In particular, software which “provides decisive information for making a diagnosis” will fall into this category. For devices which are intended to be used by consumers, providing even an “indicative diagnosis” may be enough to imply that the device is allowing direct diagnosis. Companies not intending medical device status for their software products should therefore avoid any form of diagnostic functionality.

5. Software which “drives a device or influences the use of a device”

Software which “drives a device or influences the use of a device” falls into the same risk class as the device itself. The updated guidance contains a new Appendix with helpful examples of how software of this type will be classified. In particular, software which influences a device outside of its intended purpose will take the same classification as the other device.

This new guidance is important for manufacturers of third party software which is intended to interact with, or influence use of, another manufacturer’s medical device, not just in relation to risk classification but also because the guidance flags the need for both manufacturers’ respective post-market surveillance systems to take account of any interactions between standalone software products and other medical devices. The European Commission’s February 2020 report on the safety and liability implications of AI, IoT and robotics focuses on how these things are transforming the characteristics of many products and services. This obviously includes medical devices, hence the MHRA’s flag to manufacturers concerning the need to ensure post-market surveillance systems and plans are appropriately updated in order to keep pace with the entry of new interactive technologies into the market if manufacturers are to continue to meet the requirements of the medical devices legislation.

Comment

The updated guidance provides helpful insight into the MHRA’s approach to various types of healthcare software and apps. This sector is growing rapidly, and the impact of COVID-19 will only increase the demand for technology which can provide services such as diagnosis or monitoring remotely. Tech companies should think carefully whether they are prepared to take on the responsibilities of a medical device manufacturer when designing software and apps of this nature, and if not, ensure the technology is designed and marketed to fall outside of the scope of medical device regulation.