The life sciences sector in the UK has proved economically robust over recent years, growing in strength and diversity. In particular, healthcare technology has seen the largest growth with turnover reaching £17.6bn in 2013.1 Within this has come an exponential rise in mobile medical applications, known as ‘healthcare apps’ or ‘medical apps’, which focus on health, fitness and medical issues.
Thousands of medical apps are now readily available. They cover a broad spectrum of issues from providing information on illnesses, diseases or treatment options, assisting with diagnosis of conditions such as colour blindness or abnormal heart rhythms, giving tips on how to manage conditions (to both doctors and patients) and helping to monitor conditions such as high blood pressure.
The benefits of using such innovative technology apply to both healthcare professionals and their patients; treatment can be administered more efficiently and accurately and the time spent in clinics can be reduced by patients who use apps to help manage their own conditions.
With such a rapid increase in the number and range of apps available, it is inevitable that various concerns have been raised as to the relative benefits and risks that these apps pose. Many such concerns relate to their provenance, whether they are approved by clinicians and what, if any, steps are being taken to ensure the accuracy and safety of such apps and how the regulators would deal with any potential safety issues that emerge.
HOW ARE CONCERNS BEING ADDRESSED?
Alison Newstead, product liability specialist with Shook, Hardy & Bacon International, examines the regulatory approaches currently being taken in two large marketplaces for medical apps: the UK and the USA.
Whether, and how rigorously, a mobile medical app is regulated in either of these jurisdictions depends largely on whether it is considered to fall within the definition of a ‘medical device’. Falling within such a definition triggers certain obligations; in particular, requirements need to be met before the product can be placed on the market, and stringent post-market vigilance obligations need to be followed to ensure that any potential safety issues are swiftly identified and addressed.
The regulators in the UK, the Medicines and Products Healthcare Regulatory Agency (the MHRA), and the USA, The Food and Drug Administration (the FDA), have recently taken steps to address some of the developing issues surrounding medical apps. Both regulators want to achieve the same end result: the safety of end users, but equally, they seem to recognise that a sensible balance needs to be achieved, that does not hinder innovation in these burgeoning industries.
THE USA APPROACH
The US FDA issued guidance ahead of the MHRA on 25 September 2013.2 What is clear from the guidance is that the FDA is taking a pragmatic, hands-off, risk-based approach. This is unsurprising due to the number and range of medical apps available on the market.
In the US, consideration is primarily given as to whether the app falls within the applicable definition of a medical device, as set out in the Federal Food Drug & Cosmetic Act 1938 (FD&C Act). According to the FD&C Act, a medical device is intended for ‘… use in the diagnosis of disease or other condition, or in the cure, mitigation, treatment or prevention of disease’ or ‘intended to affect the structure or function of the body… not through chemical action’. (ss201 h(2) and (3)).
The FDA looks at the functionality of the app and evaluates whether the app could pose a risk to patient safety if it did not function as intended. If it is considered that the particular app poses ‘a lower risk to the public’ the FDA will exercise what it calls ‘enforcement discretion’, meaning that it will not enforce the obligations under the FD&C Act. This may prove confusing to some manufacturers as the FDA has indicated in the guidance that manufacturers for whom they intend to exercise enforcement discretion should still maintain a quality management system that incorporates some of the elements of its quality system regulation such as risk management strategies, good design practices and adequate verification and validation.
The guidance helpfully sets out some examples of the types of apps which would be regulated by the FDA. These include:
- apps which perform patient specific analysis and diagnosis or treatment recommendations;
- apps which are an extension of a medical device by connecting to the device to control, display or analyse patient’s data eg apps which could control inflation of blood pressure cuffs;
- apps which transform the mobile platform into a medical device by using attachments or display screens to perform medical device functions eg attaching a sensor to monitor electrical signals to the heart.
Apps which would, strictly speaking, fall within the definition of a medical device, but which the FDA do not intend to regulate are those that pose a ‘lower risk’ to patients. Examples given include apps which:
- help patients manage their own conditions without providing specific treatment recommendations or suggestions;
- automate simple tasks for healthcare providers eg calculations;
- provide patients with tools to organise and track health information without recommending changes to prescribed therapies;
- help asthmatics track inhaler usage; or
- help patients cope with anxiety.
There are some types of apps which clearly fall outside the definition of medical devices such as medical e-books, education tools for medical training or patient information or education. The FDA intends to create a website where it will post examples of apps that it does not intend to regulate. No doubt this list will expand as new apps are developed.
The FDA has approved approximately 100 mobile medical apps in the last decade; 40 in the last two years – showing the pace of innovation; but as the FDA acknowledges, this also demonstrates the ‘very small subset’ of medical apps it intends to regulate compared to the thousands available on the market.
The FDA guidance helpfully set outs a summary of those who should be mindful of regulation. In short, it is ‘manufacturers’ who should be aware of their potential obligations.
Manufacturers are defined as any person or entity who:
‘… creates, designs or labels a mobile app system from multiple components or initiates specifications to mobile medical apps or processes product development/manufacturing services from another party’.
Software developers who ‘merely put together the nuts and bolts of the app’ for the product inventor will not be covered. Also excluded from regulation will be manufacturers of smartphones, content distributors, internet service providers, doctors who produce apps for their own practice and non-commercial apps for teaching and research. With regard to content distributors, such as the various online app stores, uncertainty remains regarding the scope of their role in post marketing obligations such as a product recall.
THE UK APPROACH
The UK regulator, the MHRA, has not taken a radically different approach in the guidance that it issued in March 2014.3
As with the US, the UK uses the existing definition of a medical device as a starting point. In the UK, the definition emanates from the Medical Device Regulations 2002. This defines a medical device as an: ‘… instrument, apparatus, appliance… intended… for the purposes of diagnosis, prevention, monitoring, treatment or alleviation of disease… or compensation for an injury or handicap… investigation, replacement or modification of the anatomy or of a physiological process, or control of conception’ which ‘does not achieve its principal intended action… by pharmacological, immunological or metabolic means’.
To this end, the UK definition is broadly similar to that which is contained in the relevant US legislation and one would expect that a similar range of apps would be caught by its provisions.
In addition to the definition of a medical device as contained in the UK Regulations, the UK guidance also suggests that the intended audience of the guidance (healthcare and software developers) review the existing EU guidelines on standalone software used in healthcare.4
What is clear from the guidelines is that the intended purpose of the app is key: how this is construed will be assessed in light of all claims made in relation to the app, including claims made in promotional material such as brochures and webpages.
Interestingly, while the MHRA do not give such an exhaustive list as the FDA regarding which apps may be covered by the regulations, the guidance sets out a list of words and phrases that would prompt the MHRA to conclude that the app was a medical device. These words include ‘amplify, analysis, interpret, alarms, calculates, controls, converts, detects, diagnose, measures, monitors’.
The guidance also recognises that apps could be classified by function and indicates that the types of software that are likely to fall within the ambit of the regulations are those which act as ‘decision support software’, either for clinicians or patients. This includes ‘decision support or decision making software that applies some automated reasoning, such as a simple calculation, a decision support algorithm or a more complex series of calculations eg dose calculations/symptom tracking, clinician guides’. In particular, it is recognised that software which provides ‘personalised guidance’ (based on personal data entered by the end user) is likely to be regulated.
While examples are limited, the guidance does specifically confirm that apps acting as accessories to medical devices such as those that measure temperature, heart rate, blood pressure and blood sugars, could be medical devices. So could programmes for prosthetics, as well as apps which monitor a patient and collect information entered by the user (but only if the output affects the treatment of an individual).
As could be expected from the definition of a medical device – and largely in line with the US position – software that provides general information (even though it may be targeted at a particular group), or used to book appointments, request prescriptions or have virtual consultations, is unlikely to be considered as an app requiring regulation.
The UK guidance largely refers back to obligations under the regulations if the app should be deemed to be a medical device. However, there is also some additional useful guidance specifically aimed at software developers for post-market surveillance obligations, instructions for use, and disclaimers. In particular, in the case of a recall, the MHRA advise that ‘a system of registration/activation may aid the manufacturers trace devices that have been distributed by third party distributors or app-stores’. The actual obligations of third parties, over and above those specified in the regulations, is not elaborated upon.
There are also a number of specific software considerations commented upon by the MHRA, such as advice on viruses and anti-virus protection and the use of disclaimers which may potentially attempt to avoid regulation.
While there are striking similarities between the two sets of guidelines, the UK regulator has not gone as far as the US FDA in terms of ‘enforcement discretion’. There has been no indication that any such discretion will be exercised in relation to those placing products on the UK market whether the app may pose a ‘low risk’ or not. US developers should therefore beware as these apps which may not attract attention in the USA may do so in the UK.
In conclusion, the guidelines issued by the FDA and MHRA provide welcome guidance to those developing software apps in the US and UK marketplace. However, as the complexity of technology develops and the functions that apps can perform increase, the guidelines, and the reach of the regulators may well intensify.
By Alison Newstead, partner, Shook, Hardy & Bacon International LLP.
E-mail: anewstead@shb.com.
Notes
- Strength and Opportunity 2013: The landscape of the medical technology, industrial technology and biotechnology and pharmaceutical sectors in the UK. Annual update 2014.
- Mobile Medical Applications, Guidance for Industry and Food and Drug Administration Staff, 25 September 2013, US Department of Health and Human Services, Food and Drug Administration.
- Guidance on medical stand-alone software (including apps), MHRA, 19 March 2014.
- MEDDEV 2.1/6 – Guidelines in the qualification and classification of standalone software used in healthcare within the regulatory framework of medical devices, January 2012.