To help determine when software constitutes a medical device, the body responsible for regulation in the UK, the Medicines and Healthcare products Regulatory Agency (MHRA) updated its guidance on when certain software, including apps, should be regulated as a medical device. We examine this guidance and the judgment in the Court of Justice of the EU in the SNITEM case, which looked at the regulatory status of clinical decision making software. Both the guidance and the judgment help explain the regulatory framework and should be considered by producers at an early stage in the development of their products.
The structure of the regulatory regime: an overview
Regulations covering medical devices require that before being placed on the market, they must be assessed as belonging to one of four classes (I, IIa, IIb, or III), broadly reflecting the risk level posed by the product. "Placement on the market" occurs not only when a product is sold but can happen when a product is supplied free of charge if that is in the course of a commercial activity. The device must meet essential general, design and construction requirements to ensure safety and quality. Compliance is generally demonstrated if harmonised standards are met e.g. ISO standards such as EN 62304:2006, which defines the lifecycle requirements for medical device software.
The definition of software is defined extremely broadly, and includes the following:
- Internet, server and cloud-based software;
- Traditional executable programs, including "uncompiled" software and, notably, freeware and open source software; and
- Functional documents, including spreadsheets with complex functionality, pdfs or word processing documents featuring macros.
In the context of software including apps, the MHRA will expect, amongst other things:
- A consistent user interface and clear, readable text and graphics;
- Evidence gathered through clinical evaluation to support benefits claimed in promotional literature;
- Objective assessment of those benefits outweighing any risks; and
- Validation of the software according to the "state of the art".
Depending on which class the device is considered to fall into, self-declaration of compliance by the manufacturer may be possible, otherwise an external notified body assesses compliance. The product is then CE marked and may be placed on the market.
Post-market surveillance rules require monitoring and reporting of serious adverse incidents to the MHRA.
How does the MHRA assess whether software is a regulated device?
While the question of whether any given software qualifies as a medical device will be clear in many cases, the unpredictable and disruptive nature of innovation prohibits an overly prescriptive approach to identification. The MHRA guidance, issued in September 2017, therefore refers to both concrete examples on the one hand, and seeks to cover novel situations on the other hand, by outlining principles as to whether the product has an intended medical purpose and whether there are "indicative words and phrases" that may be associated with regulated software. Medical purposes include:
- Prevention of disease;
- Diagnosis, monitoring, treatment or alleviation of a disease, injury or handicap;
- Compensation for a handicap; or
- Investigation, replacement or modification of the anatomy or of a physiological process.
In each case, the guidance details factors weighing in favour or against qualification as a device. In determining whether the software has an intended medical purpose, the MHRA will give significant weight to promotional materials, including app store description and categorisation. Technical disclaimers such as "for information only" are not determinative. The regulator will also consider the way the software is labelled and its instructions for use. The MHRA are at pains to say that simple changes to descriptions can make the difference between whether a product is considered a device or not. Importantly, the developer's social media channels and comments on app stores ought to be closely monitored, as quotes and testimonials are considered to be "implied claims".
Focus on decision support software
The MHRA guidance provides that decision support software is usually considered a medical device when it applies automated reasoning such as simple calculation, an algorithm or a more complex series of calculations. Software that performs calculations, or interprets or interpolates data without review of raw data by the healthcare professional, is likely to be considered a device. By contrast, software that merely provides paper documentation in a digital form or reference information and leaves the clinician to make the clinical decision is unlikely to be classified as a device, as the clinician exercises their own judgment based on their own knowledge.
In SNITEM (Case C 329/16), the Court of Justice of the European Union agreed with this approach. It considered whether decision making support software used by prescribers, which used patient-specific data to detect contraindications, drug interactions and excessive doses, constituted a medical device. The court held that software that cross-references patient-specific data with the drugs that he or she is contemplating prescribing, and automatically provides the doctor with an analysis intended to detect possible contraindications, drug interactions and excessive dosages, had the intended purpose of prevention, monitoring, treatment or alleviation of a disease. It was thus a device within the meaning of Directive 93/42/EEC concerning medical devices.
By contrast, software used in a medical context but that has the sole purpose of archiving, collecting and transmitting data, for example patient medical data storage software, would not be a device. The same would apply to software limited to indicating the name of the generic drug associated with the one the doctor plans to prescribe, or that merely states the contraindications given by the drug manufacturer in its instructions for use.
Action required
It is imperative for developers to establish the regulatory status of their software as early as possible in the design and manufacture process for many reasons:
- Minimisation of wasted costs: Costs can be wasted if late consideration of regulatory status causes re-evaluation of the design and concept stage of development;
- Contractual clarity: Purchasers of software, both at a corporate and individual level, will need clarity on regulatory status and due classification of the product. To avoid issues either during negotiations or after a contract has been concluded, manufacturers need to know and communicate to potential purchasers precisely what it is they are offering.
- Avoidance of regulatory enforcement action: Where the authorities believe software has been placed on the market without the necessary CE marking, they will investigate. This may include exercising powers of search and seizure, and serving notices requiring the withdrawal of a device from the market or restrictions on its distribution or use. Failure to comply with a notice or order can carry with it various penalties including an unlimited fine or a period of imprisonment.
- Civil litigation and judicial scrutiny: The application of such software brings with it a risk of its implication in civil claims for negligence or breach of statutory duties on the part of the developer leading to injury or loss, or indeed scrutiny by Coroners at inquests if a death has occurred. The regulatory status of the software and thus the applicable standards will likely be a key issue affecting liability and the extent of any criticism.
- Commercial attractiveness: While compliance can prove costly and time-consuming, for lay and professional users, safety is paramount. Guidance issued by the Royal College of Physicians advises doctors to check apps for CE marking and to stop using any that should be so marked, but are not. Professionals will be mindful that knowingly to act contrary to this guidance could not only compromise patient safety, but also result in professional disciplinary issues and wider governance issues for the institutions in which they deliver treatment. Software that has been subject to litigation or criticism will have a diminished value along with that of the developer.
Medical technology is changing rapidly but developers and manufacturers need to stay aware of the regulatory status and obligations that apply to their products and software. Difficult questions may still arise but the regulators are seeking to provide the necessary guidance. As patient safety is at stake, scrutiny is inevitable. Potential users will naturally avoid software that has been subject to litigation or public judicial criticism, and will be duly wary of the manufacturer. Software developers, and those with wider roles in the medical device market, must navigate these compliance issues.
For more about our MedTech offering or if you would like to discuss any aspect of this alert, please contact:
