Apps and traps: the regulation of software and apps used in healthcare

I use my smart phone as (amongst other things) a spirit level, a calculator, a camera, a web browser, a dictaphone, a radio, a sat nav, a diary, a clock, an address book, and a messaging device.  I also occasionally use it to make phone calls.  The remarkable processing power that we carry in our pockets provides a wonderful variety of services and opportunities, and a significant (and rapidly growing) number of applications for smart phones have a health-related dimension.

The number and variety of health applications (or apps as they are usually known) has risen dramatically over recent years, reflected in the fact that NHS Choices published a ‘Health Apps Library’, offering a list of “safe and trusted health apps to help you manage your health”.  However, the use of this type of software by medical practitioners for medical purposes has also increased, with anecdotal evidence suggesting that many doctors use apps in their day to day clinical practice.  This in turn gives rise to legal and regulatory considerations regarding liability, governance and compliance.  This article briefly considers some of these considerations in relation to both health apps and software more broadly.

UK Medical Device Regulation

It is perhaps understandable that few people are aware that when stand-alone software is used in a healthcare setting, it may constitute a medical device, an in vitro diagnostic (IVD) medical device, or an accessory to an IVD.  If it does qualify as such as device, it is an offence to sell or supply it unless it conforms with the relevant legal standards.  The classification criteria which are used to determine when stand-alone software attracts regulatory requirements are not, however, straightforward.  So when does software become a medical device?

Although the UK has its own laws governing medical devices, in reality the legal framework is European in origin.  The UK Medical Devices Regulations of 2002 (subsequently amended on a number of occasions) incorporated three EU Directives into UK law: the 1990 active implantable medical devices directive, the 1993 medical devices directive, and the 1998 in vitro diagnostic medical devices directive.

Medical devices are defined as being:
“…any instrument, apparatus, appliance, software, material or other article, whether used alone or in combination, together with any accessories, including the software intended by its manufacturer to be used specifically for diagnosis or therapeutic purposes or both and necessary for its proper application, which –
(a)     is intended by the manufacturer to be used for human beings for the purpose of—
(i)     diagnosis, prevention, monitoring, treatment or alleviation of disease,
(ii)     diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap,
(iii)     investigation, replacement or modification of the anatomy or of a physiological process, or
(iv)     control of conception; and
(b)     does not achieve its principal intended action in or on the human body by pharmacological, immunological or metabolic means, even if it is assisted in its function by such means”

It follows from this definition that, whilst the regulations specifically include software within their scope, it is also necessary to consider the intended use and purpose of the software to determine whether or not it constitutes a medical device.

Stand-alone software must have a ‘medical purpose’ to qualify as a medical device.  When considering this, it is necessary to look at the purpose of the software itself: the test does not include software which is incorporated into an existing medical device.  For example, built-in software which controls a CT scanner will be treated as a part of that device, not as stand-alone software requiring its own classification.  However, software which interprets CT scan results to aid diagnosis may well be a medical device.

When considering use and purpose in the context of classification, it may also be helpful to consider the function of the software and the action it performs on data.  For example, software that merely stores electronic patient records is unlikely to be categorised as a medical device, but if it incorporates modules which provide additional analysis that contributes to diagnosis or therapy (for example, a patient medication module), then this may be classified as a medical device.

Similarly, the purpose of the software itself must be medical, not just applied in a medical context.  For example, a clinical information system which records and stores data relating to patient identification and clinical observations will not usually be considered a medical device in itself.  However, if it incorporates a functionality which provides additional diagnostic or therapeutic information then it may qualify as a device.  This distinction between medical and non-medical purposes can be nuanced, depending on the circumstances.  An example given by the Medicines and Healthcare Products Regulatory Agency (MHRA) is the use of an application which uses an accelerometer in order to detect falls in epileptic patients.  This is likely to be regulated as a medical device because its purpose is medical, whereas the use of the same application to alert a carer when an elderly person gets up out of bed in the social care context would not be regulated as a medical device.

A further consideration is whether the software is used for the benefit of individual patients or for a cohort.  Stand-alone software which is used to interpret or evaluate data relating to the medical care provided to an individual may be a medical device, whereas software used to analyse population data or to create generic treatment plans will not be.

If it is decided that stand-alone software is indeed a medical device and is intended for diagnostic or therapeutic purposes, it will be a Class IIa device or, if potentially hazardous, Class IIb.  If it is used for other purposes, it will be a Class I device.  The compliance of Class I devices relies on self-declaration by the manufacturer, whereas Classes IIa and IIb require the intervention of a notified body (such as BSI) to assess compliance.

Health apps

As mentioned above, modern smart phones have the capacity and versatility to collect a vast array of personal data.  The advent of comparatively affordable genome sequencing and ready access to genetic data can also be fed into apps and software, creating an increasingly powerful and personalised source of what may be very valuable health information when properly processed and interpreted.

The MHRA has published useful guidance on the regulation of health apps, suggesting that there are a number of key words which are likely to contribute to the MHRA determining a health app is a medical device, including: amplify, analysis, interpret, alarms, calculates, controls, converts, detects, diagnose, measures, and monitors.  These of course reflect the provisions of the medical device regulations discussed above, and many of the same questions discussed above will arise in relation to classification.

There may be a tendency to assume that such apps – carried as they are on a personal phone or tablet – are even less likely to attract regulation than a hospital system or computer programme, but in fact they are regulated in essentially the same way, attracting the same liabilities.  The use of and integration of such apps into day to day practice therefore warrants careful consideration, and the development of a clear policy governing the use (or indeed prohibition) of apps in the workplace.

Conclusions

The burden of medical device regulation in the context of health software and apps will most commonly fall on the shoulders of the software producers – those companies which place the device or accessory on the market for sale or supply.  However, healthcare providers should seek to ensure that the software they purchase satisfies the relevant regulatory requirements.  One particularly powerful reason for doing so is because compliant manufacturers are responsible for implementing an effective post-marketing surveillance system for their devices, which is designed to make sure that any problems or risks associated with the use of the device are identified.  Related to this, the liability that may arise as a result of the use of health apps by medical staff necessitates at the very least a clear policy governing the use of such software.