DIGITAL HEALTH LEGAL4

MHRA seeks to clarify whether an app is a regulated medical deviceOn 25 August 2016 the Medicines and Healthcare Products Regulatory Agency (‘MHRA’) updated its guidance regarding standalone software including apps (‘Guidance’), which aims to assist developers and users in resolving the question of whether their software or apps classify as regulated medical devices. Raj Gathani and Brian Kelly, of Covington & Burling LLP, examine the implications of the MHRA’s Guidance.

The incorporation of health apps into patient care forms a part of UK Health Secretary Jeremy Hunt’s £4.2 billion plan, announced on 7 September 2016, to support “a fully digitised NHS” by 20231. Hunt’s plan seeks to implement independent recommendations by the National Advisory Group on Health Information Technology in England2.

Recent years have however seen controversies in the health software arena. In October 2015 the NHS had to suspend its Health Apps Library, a compendium of NHS-approved apps aimed at end users, following a report that a number of the library’s apps had put patient data at risk3. On the patient-facing side, 2015 also saw US regulators charge the makers of two melanoma screening apps called Mole Detective and MelApp for making deceptive health claims4. The apps claimed they could assess for melanoma risk based on photographs of skin moles.

From a policy perspective, many health and lifestyle apps are unlikely to need regulation as medical devices. Yet a sub-set that ventures into medical territory should have to conform to a higher, medical regulatory standard.

Regulatory backgroundCurrent EU law on medical devices and in vitro diagnostic medical devices (‘IVDs’), comprising three core Directives5 (the ‘Directives’), sets certain requirements for manufacturers of products (including software) that meets the definition of a medical device. These include: performing a conformity assessment; ‘CE’ marking the product; as well as meeting applicable harmonised standards. Given

the additional regulatory burden involved, some parts of the health software industry have called for greater clarity on the circumstances in which apps cross the boundary into medical device territory.

The Directives currently provide limited information on when software would fall within the definition of a medical device. Regulators have held that standalone software, such as apps, can fall within medical device classification to the extent they possess an “intended […] medical purpose,” as defined in the Directives.

The European Commission (‘EC’) has a guidance document on standalone software used in the healthcare setting (the so-called ‘MEDDEV 2.1/6’), which it updated in July 20166. MEDDEV 2.1/6 tends to focus on clinician-facing or hospital-based software, rather than patient apps. Another EC document, the Medical Devices Borderline Manual7, provides a handful of examples relating to standalone software. Some commentators have therefore criticised the EC for providing insufficient guidance to the mHealth sector.

It seems that the Guidance, an update to the MHRA’s previously published guide from 2014, is the UK’s interpretation of the updated version of MEDDEV 2.1/6, and is looking to fill this gap. Neither the EC’s nor the MHRA’s guidance is legally binding. However, both documents provide an insight as to how regulators would interpret the Directives in respect of certain types of software.

The MHRA GuidanceWhat’s new? The MHRA produced the guidance in response to industry developments.

The MHRA’s Director of Medical Devices, John Wilkinson, said on the launch of the guidance, “We live in an increasingly digital world, both healthcare professionals, patients and the public are using software and stand-alone apps to aid diagnosis and monitor health […] developers should make sure they are complying with the appropriate medical device regulations.”

STANDALONE SOFTWARE

Raj Gathani Attorney rgathani@cov.com

Brian Kelly Partner bkelly@cov.com

Covington & Burling LLP, London

A Cecile Park Media Publication | October 2016 5

1. https://www.gov.uk/government/news/new-plans-to-expand-the-use-of-digital-technology-across-the-nhs

2. https://www.gov.uk/government/publications/using-information-technology-to-improve-the-nhs/making-it-work-harnessing-the-power-of-health-information-technology-to-improve-care-in-england

3. Unaddressed privacy risks in accredited health and wellness apps: a cross-sectional systematic assessment - Huckvale et al. BMC Medicine 2015 13:214, http://bmcmedicine.biomedcentral.com/articles/10.1186/s12916-015-0444-y

4. https://www.ftc.gov/news-events/press-releases/2015/08/melanoma-detection- app-sellers-barred-making-deceptive-health

5. Directive 90/385/EEC regarding active implantable medical devices; Directive 93/42/EEC regarding medical devices; and Directive 98/79/EC regarding IVDs.

6. http://ec.europa.eu/DocsRoom/documents/17921/attachments/1/translations/en/renditions/pdf

7. http://ec.europa.eu/DocsRoom/documents/12867/attachments/1/translations/ en/renditions/pdf

8. https://www.gov.uk/government/news/is-your-app-a-medical-device-its-healthy-to-know-regulator-issues-updated-guidance

9. Medical Devices: http://data.consilium.europa.eu/doc/document/ST-9364-2016-REV-3/en/pdf; IVDs: http://data.consilium.europa.eu/doc/document/ST-9365-2016-REV-3/en/pdf

The MHRA’s Director of Medical Devices, John Wilkinson, said on the launch of the Guidance, “We live in an increasingly digital world, both healthcare professionals, patients and the public are using software and stand-alone apps to aid diagnosis and monitor health […] developers should make sure they are complying with the appropriate medical device regulations8.” The Guidance is significantly more detailed than its predecessor and includes an interactive flowchart. This facilitates a step-by-step analysis as to whether a piece of software would fulfil the medical device or IVD criteria. Note that the Guidance applies only to standalone software. Software that is built-in to hardware at the time that the manufacturer puts the product onto the market falls outside the scope of this guide.

At various points along the flowchart, the Guidance provides interpretative glosses on the text of the Directives, as well as illustrative examples to assist developers in navigating the process of deciding whether their software qualifies as a medical device. Many of these explanations and examples (discussed further below) address consumer-facing apps, and are worthy of further examination.

Intended purposeThe Directives define ‘intended purpose’ as ‘the use for which the device is intended according to the data supplied by the manufacturer on the labelling, in the instructions and/or in promotional materials.’ As a result, relatively basic software can become a medical device based on the developer’s product claims.

The Guidance clarifies that app store categorisation and description as well as material on a developer’s social media channels, for example, would fall within the remit of ‘promotional materials.’ Further, the Guidance confirms the general position of regulators that disclaimers from developers (such as “for information only,” or “this is not a medical device”) are unlikely to absolve the manufacturer from responsibility if the software otherwise meets the intended use criteria.

Medical purposeBroadly speaking, ‘medical purpose’ under the Directives covers: the prevention of disease; compensation for a handicap; investigation of the anatomy or a physiological process; and the diagnosis, monitoring, treatment or alleviation of disease, injury or handicap. These concepts can be interpreted differently across the EU and hence can cause clarification issues. The Guidance attempts to tease out some of their nuances.

In the context of diagnosing a disease, the Guidance focusses on software that performs, or provides information so as to perform, a diagnosis. The MHRA illustrates this with the example of an app that claims to assess the risk of melanoma based on images of moles, or of UV skin photographs, which would be a medical device. Apps that simply record such images and transmit them to a clinician for review, without enhancement, would not qualify. The crux seems to be the role of the software in the eventual diagnosis. The example is apt given the Mole Detective and MelApp controversies in the US.

DIGITAL HEALTH LEGAL6

continued

The MHRA Guidance arrives during a time of change in the regulatory landscape for medical devices.

In reality, a number of apps do not provide a final diagnosis, but rather make recommendations (e.g., to see a healthcare professional) and/or support a final decision by a clinician (so-called decision support software). On this point, the Guidance says that ‘apps or software intended to make a recommendation to seek further advice based on user entered data […] are likely to be medical devices.’ Those that ‘are intended to make general recommendations to seek further advice […] are unlikely to be devices.’ Developers should note the linkage between user data and the recommendation made. The Guidance does not elaborate on the meaning of ‘general recommendation.’ This might frustrate developers of certain lifestyle apps that border on health topics (e.g., weight loss apps that discuss BMI) as to the types of recommendations they can make.

In terms of disease monitoring, the Guidance confirms that lifestyle apps (e.g., those that monitor heart rate for fitness) would in general not be medical devices, though they may fall into the classification ‘where the intention is to investigate physiological processes.’ An app that ‘monitors a patient and collects information […] may qualify as a medical device if the output is intended to affect the treatment of an individual.’ However, such an app is unlikely to be a medical device if it simply ‘replaces a written diary/log of symptoms that can be used when consulting with the patient’s doctor. However, the addition of features that enhance the data

presented may bring it into the remit of the directive.’ Many of these analyses get to the core of the distinction. Is there a specific disease, injury or handicap involved? Is the app merely a receptacle for data, or does it enhance the data?

The function relating to treating a disease may also lead to some interesting outcomes. The Guidance concludes that this function includes software that ‘enable[s] a treatment to be performed’ or ‘claim[s] that the output from a physical device can be used [for treatment].’ The Guidance provides a fairly clear example: software would be a medical device if ‘ [...] intended to calculate the dose of insulin a diabetic needs to treat their diabetes based on carbohydrate in a meal.’ Extending this concept creates ramifications for a number of categories of health app, particularly those in the mental health space. There are several currently available smartphone apps for depression sufferers. Some, for example, produce blue light through the smartphone screen for mood regulation; others offer instructional exercises in mindfulness or cognitive behavioural therapy. According to the Guidance, these might all be medical devices to the extent that they claim to treat depression.

More change imminent?The Guidance arrives during a time of change in the regulatory landscape for medical devices. Since 2012, the EC has led efforts to modernise the Directives. The EC has proposed a package of legislative change to replace the Directives with two regulations, one

on medical devices, the other on IVDs. On 15 June 2016 the European Council published agreed draft texts of both9. The Council expects the draft Regulations to become law, subject to final ratification, around Autumn 2016 and to become effective in 2019 (2021 for IVDs).

The draft Regulations do not fundamentally alter the ‘medical purpose’ requirement. Recital 18a of the draft for medical devices does contain an important clarification for app developers that ‘software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being application is not a medical device.’ It remains to be seen how regulators adapt their guidance in light of this Recital.

The draft Regulations generally impose a tighter regulatory regime on manufacturers of medical devices. This involves a more robust framework for pre-marketing assessment of medical devices and additional obligations on manufacturers of medical devices in respect of device registration, traceability, and post-marketing oversight. Since the regulatory burden is set to increase for software that is a medical device, developers should start thinking through the current guidance in respect of their products.

Commentators therefore expect the EC to revise its MEDDEV guidance once again before 2019. The MHRA also expects to revise its guidance in light of the new Regulations, to the extent these might continue to apply pending the outcome of the UK’s negotiations to leave the EU.

STANDALONE SOFTWARE