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”.
Clinicians are thought to be increasingly using apps and other software when diagnosing and treating patients. 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 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
Few people are aware that when stand-alone software –such as that in an app – 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 standalone 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” (my emphasis)
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.
Some software will be incorporated into an existing medical device – for example, CT scanners include software which control their use. This software will be treated as part of the device and covered by its classification as a medical device.
Other software, however, will be standalone and may need to be treated as a medical device in its own right. For example, software may be used to interpret CT scans and aid diagnosis is likely to be treated as a medical device.
The function of the software can be helpful in determining whether it is likely to be treated as a medical device software that merely stores electronic patient records is unlikely to be categorised as a medical device. By contrast, 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.
Some of these may be viewed as medical devices and will be regulated as such. 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.
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.
Trusts need to be aware of the dangers when such software is used by staff. These words include 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.
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, and 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. This might cover, for example:
a) Post-marketing surveillance
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. Proper software registration may therefore help ensure that users are notified in the event of problems. Conversely, the use of unregistered apps may not involve full postmarketing surveillance and so users may be unaware of errors or failures with the software.
b) Adverse Incident reporting
Manufacturers of medical devices are obliged to follow MHRA guidance on reporting adverse incidents, but it would be sensible to address how a trust will incorporate the use of health apps within its own governance and reporting structure.
c) Approval and registration
Trusts may wish to implement some form of register of health apps so that staff are encouraged to declare the apps they are using, and this could be developed into an approval process.
It is vital to ensure that patient confidentiality is respected in the use of software which sometimes involves the transfer of data to a remote server or processor. This may not involve the disclosure of patient names or addresses, but deductive disclosure may be made through the release of certain personal medical data.
e) Viruses and support
If a trust does allow staff to use health apps at work, what – if any – degree of support will it provide for their use, maintenance and support? Will the trust IT department assist with problems, virus protection, or installation? If not, where should staff turn for such support?
f) Medical records
If staff use health apps in the context of diagnosis or patient care, it will be important that the use of such apps is documented, along with the results, data, diagnosis or guidance that the app produces. It is not difficult to envisage circumstances where staff may overlook the need to make a paper-based record of an electronic assessment, but this could be specifically addressed in the trust’s policy.
If patients are to be given health apps for use at home (whether on their own device or on a trust device), the liability for the use of such a device will need to be addressed, together with the practical considerations of how they are instructed, monitored and maintained.
Full articles: Agreement at last on the junior doctors’ contract; Spotlight: Innovation Partnership procurement process; New care models: is it time to talk about organisational form?; Unlocking hidden value – maximising the value in your intellectual property; Super partnerships.