Investment in artificial intelligence (AI) and digital health technologies has increased exponentially over the last few years. In the United Kingdom, the excitement and interest in this space has been supported by NHS policies, including proposals in the NHS Long Term Plan, which set out ambitious aims for the acceleration and adoption of digital health and AI, particularly in primary care, outpatients and wearable devices.
Although these developments are encouraging to developers, there is still no clear framework for reimbursement or tariffs for digital health tools and AI.
At the same time, the plethora of new technologies has led to increased calls for regulation and oversight, particularly around data quality and evaluation. Many of these concerns may be addressed by the new Medical Device Regulation (MDR) and other regulatory developments. In fact, there is some risk that while regulatory landscape is moving quickly, the pricing environment is still a way behind.
In May 2020, the new MDR will change the law and process of certification for medical software. The new law includes significant changes for digital health technologies which are medical devices. In March 2019, the National Institute for Health and Care Excellence (NICE) also published a new evidence standards framework for digital health technologies. The Care Quality Commission (CQC) already regulates online provision of health care, and there are calls for wider and greater regulation. The government has also published a code on the use of data in AI.
Digital Health Technologies and the MDR
The new MDR will mean a significant change to the regulatory framework for medical devices in the European Union.
As with the previous law, the MDR regulates devices through a classification system.
The new regime introduces new rules for medical software that falls within the definition of device. This will mean significant changes for companies that develop or offer medical software solutions, especially if their current certification has been “up-classed” under the MDR.
Key Takeaways for Investors in Digital Health Tools
Companies and investors in digital health should:
- Check whether their digital health tool is a medical device and caught by the MDR.
- Review whether their proposed or current certification has changed under the new MDR.
- Assess the new requirements on certification and general safety in the MDR as those apply to digital health tools.
- Ensure that development programmes have taken into account the likely time period for certification, which may be lengthy due to shortages in Notified Bodies.
- Build in the cost of any increased certification requirements and costs of compliance.
- Take into account the CQC guidance for digital and online health care, and check whether the health tool and service will require CQC registration.
- If the digital health tool is to be marketed and sold to NHS organisations, understand and take into account the NICE evidence standards framework for digital health technologies. Whilst these are stated to be complementary to the new MDR, the framework has different assessments and evidence requirements.
- Have a clear strategy about access to market and reimbursement of technologies.
- Consider the government’s Code of Conduct for data driven health and care technology.
- Understand the implications of a “no deal” Brexit, especially if the technology is marketed across Europe.
Medical Devices Regulation 2017: FAQ
When is software a medical device?
The MDR sets out clear rules on this, which are broadly similar to the previous position but provide helpful clarification.
The key test relates to the purpose of the software. The MDR states:
- Software in its own right, when specifically intended by the manufacturer to be used for one or more medical purposes, is a medical device.
Example: software used for diagnosis, or predicting disease
- Software for a general purpose, even if used in a health care setting, is not a medical device.
Example: medical records software used as a storage or retrieval system
- Software for lifestyle or well-being purposes is not a medical device.
Example: apps which monitor fitness levels, diet and wellbeing
Many companies offering medical software will be familiar with the existing rules, but it is important to know that whilst the MDR principles are broadly similar to the old rules, the MDR introduces new requirements on classification of devices. These new classification requirements will affect many companies offering online health care tools, diagnosis and prediction tools, and software and AI.
What are the new classification rules?
The MDR sets out some specific criteria around the classification of medical software, which is likely to mean that many devices which currently qualify as class I under the existing regime (MDD) may move up a class under the MDR.
The new rules are as follows:
- Software intended to provide information used to take decisions with diagnosis or therapeutic purposes are Class IIa.
- Software where these decisions have an impact that may cause a serious deterioration of a person’s state of health or a surgical intervention are Class IIb.
- Software where these decisions have an impact that may cause death or an irreversible deterioration in a person’s health are Class III.
- All other software is Class I.
Whilst some software may remain as Class I, many devices are likely to move up a class level.
This will mean more onerous responsibilities and increased rigour (and time) in relation to the certification of the device.
When do the new rules come into force for medical software?
The MDR came into force on 25 May 2017 but does not apply fully until May 2020.
The MDR includes transition provisions for existing devices. The general principle is that certificates issued by Notified Bodies under the MDD will remain valid, but for varying periods depending on the certification.
Many digital health tools are currently self-certified as Class I devices. If medical software continues to be a Class I device under the MDR, there is likely to be little practical difference for manufacturers, although manufacturers will need to comply with the increased obligations under the MDR.
However, for current Class I devices which are “up-classed” under the MDR, the position is a little less clear. There are no express provisions in the MDR which deal with up-classing, and the express transitional provisions protect certificates “issues by Notified Bodies” rather than to self-certified devices.
The prudent interpretation is that self-certification does not survive an up-class. This means that manufacturers of up-classed medical software will need to comply with the MDR and obtain certification from the MDR from May 2020.
What is the position of Notified Bodies and the timing of certification?
Notified Bodies are the organisations responsible for the issue of certificates for medical devices under both the MDD and the MDR.
There are currently serious concerns about the workloads of Notified Bodies and the impact this may have on the timing of certification. Some estimates suggest that the workload of Notified Bodies has increased seven-fold as a result of MDR changes.
This issue is exacerbated because certain Notified Bodies have also announced their intention not to pursue designation under the MDR, and no new organisations have applied to be Notified Bodies under the MDR.
What are the new data, safety and evaluation requirements under MDR?
Manufacturers must, of course, be mindful of data protection laws that apply to the development, trialling and use of medical devices.
The MDR sets out greater rigour about the evaluation of software and the datasets used to verify and validate medical devices. Manufacturers will need to be able to show how their device has been tested to demonstrate conformity, in particular with regards to safety. For software, this includes detailed information about test design, study protocols, methods of data analysis in addition to data summaries and test conclusions, in particular about software verification and validation (describing the software design and development process and evidence of the validation of the software, as used in the finished device).
For clinical evaluations, the manufacturer also must ensure that the data is evaluated and relevant to the risks and purpose of the device in question.
In addition to the general safety requirements that apply to all medical devices, the MDR sets out some specific requirements for medical software. These new requirements include instructions for use of the software, which must contain minimum requirements for hardware and IT security measures and protections against unauthorised access.
When does software qualify as an accessory?
In some cases, software may also be an accessory (and therefore must comply with the certification rules for accessories). To qualify as an accessory, the software would have either (i) to enable the medical device to function, or (ii) to specifically and directly assist the medical functionality of the device.
This consideration is especially relevant to the interoperability of software used as components or in conjunction with medical devices. There is no guidance on how these new rules in the MDR will work in practice, and it may sometimes be difficult to assess whether software is a device itself or an accessory.
It is also possible that where different medical devices are offered on the market as a single system, multiple certifications may be required.
How will a “no-deal” Brexit affect digital health regulation?
Under the terms of the current proposed withdrawal agreement, the European Union and the United Kingdom will continue to operate under the existing recognition of certifications across Member States.
However, if there is no deal, those transitional mutual recognition provisions will not apply. This is relevant to UK digital health providers that rely on their UK certification across Europe. From the date of Brexit, a UK manufacturer of a medical device will need to ensure that its device is certified by an EU Notified Body before it is placed on the EU market.
