Digital Health - The new regulation of medical software and apps

The new Medical Devices Regulation 2017/745 (“MDR”), which comes into force in May 2020, represents a huge overhaul of the regulatory framework governing medical devices in the EU. The compliance burden for manufacturers and other entities in the supply chain will be modified and intensified, and preparatory measures are already well underway to ensure that the industry is ready for the new regime come May 2020.

However, while manufacturers of “traditional” medical devices may be up to speed with the impending changes to the law, the scope of MDR stretches beyond this. In particular, companies which offer medical software or apps may also be affected if these products fall under the definition of a medical device. This will include not just medical device companies, but also pharmaceutical, healthcare and technology companies.

Software is already considered to be a type of medical device under the current legal framework (the Medical Devices Directive 93/42/EEC (“MDD”)). However, MDR contains much more detail on medical device software and introduces some key changes to the current regulatory regime. It is therefore important for any players operating in this space to ensure they are up to speed with their regulatory obligations and can comply with these once the new law enters into force.

This article sets out some of the key changes under MDR which will impact the regulation of medical device software in the EEA.

1. The definition of a medical device

Recital 19 of MDR neatly summarises the overarching approach to the regulation of medical device software:

“It is necessary to clarify that software in its own right, when specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device, qualifies as a medical device, while software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being purposes is not a medical device. The qualification of software, either as a device or an accessory, is independent of the software's location or the type of interconnection between the software and a device.”

This makes it clear that it is the intended purpose of the software which is relevant in determining whether software amounts to a medical device, rather than the setting in which the software is used. So not all software which is used in a healthcare setting or which interacts with medical devices will in itself be considered a medical device.

This is consistent with the current approach under MDD, which defines medical device software as any software intended by the manufacturer to be used for human beings for a medical purpose such as diagnosis, prevention, monitoring, treatment or alleviation of disease. These same medical purposes are retained in MDR, with the addition of the “prediction” and “prognosis” of disease. This means that software which is designed to e.g. predict a patient’s likelihood of developing a particular disease will now fall squarely within the definition of a medical device.

Importantly, the distinction between medical purpose software and “wellness” software is retained under MDR, so software which is simply intended to monitor general fitness and wellbeing will not be considered to be a medical device.

Overall there will probably be limited cases of software or apps which are not currently regulated as medical devices suddenly coming within the scope of the new definition. However, it is possible that the medical device classification of existing products could change under MDR (see below for further details).

2. Software as an accessory to a medical device

If your software or app does not fall under the definition of a medical device, you should also assess whether your product could be considered an “accessory” to a medical device. Accessories to medical devices also fall under the scope of the regulatory regime and need to be CE marked, so carry their own compliance burden.

Under MDD, an accessory is something which enables a device to be used in accordance with its intended purposes. However, this has changed under MDR. While the concept of enabling is still there, the definition of accessory now also covers articles which are intended to “specifically and directly assist the medical functionality of the medical device(s) in terms of its/their intended purpose”.

As yet there is no guidance on how this new definition will be interpreted, but it seems that the concept of “specifically and directly” assisting with medical functionality is inherently broader than the idea of enabling the device to be used. This could therefore have the effect of pulling certain software which is not currently regulated under MDD within the scope of MDR as an accessory to a medical device.

3. General safety and performance requirements and technical documentation

Annex I of MDR specifies the general safety and performance requirements for medical devices, including some new requirements which are specific to software.

For example, software which is intended to be used in combination with a mobile platform must take into account the specific features of the mobile platform, such as the size and contrast ratio of the screen, in their design and manufacture. This means these considerations will need to be specifically addressed in order to validly CE-mark the software.

There are also specific requirements regarding the instructions for use of the software, which must contain the minimum requirements for hardware and IT security measures necessary to run the software as intended, including protection against unauthorised access.

Finally, the technical documentation required to be drawn up by the manufacturer under MDR must contain detailed information on software verification and validation, describing “the software design and development process and evidence of the validation of the software”. This is expected to include summary results of all verification, validation and testing performed prior to release of the software. The technical documentation will form part of the Notified Body assessment of the device (where relevant).

The documentation associated with medical device software should therefore be carefully considered in order to ensure this is in line with the requirements of MDR.

4. UDI System

One of the key changes under MDR is the introduction of the UDI (Unique Device Identification) system, to increase the traceability of devices. This will of course also apply to medical device software.

In particular, it should be noted that a new UDI Device Identifier – which is specific to that particular device – will be required whenever there is a modification which changes the original performance; the safety or intended use of the software; or the interpretation of data. Examples of such changes include new algorithms, operating platforms or user interfaces. So changes to the aesthetic design of the software or app could give rise to an obligation to change UDI information.

In addition, minor software revisions such as bug fixes will require a new UDI Production Identifier, which identifies the unit of device production.

5. Classification

Under MDR there are new rules for determining the risk classification of medical devices, including a new rule (Rule 11) which specifically addresses software.

Software classification can range from Class IIa, for software intended to provide information used to take decisions with diagnosis or therapeutic purposes, up to Class III, where such decisions have an impact that may cause death or an irreversible deterioration of a person’s state of health. All other software which is not specifically addressed in the rule will be classed as Class I.

This means that it is possible that the risk classification of existing medical device software could change under MDR.

An increase in device classification brings with it additional obligations for manufacturers. In particular, this change is likely to be felt most acutely by manufacturers who find their products increasing from Class I under MDD to Class IIa under MDR, which would result in the need for Notified Body involvement in the conformity assessment procedure. Given the shortages of Notified Bodies currently faced by the industry, which has been compounded by Brexit, this could present a real challenge for manufacturers who find themselves in need of a Notified Body for their software products. In addition, the transition period under Article 120 MDR which enables MDD-certified products to continue to be placed on the market until May 2024 does not apply to Class I devices which are “up-classified” under MDR. This means the timeline for ensuring such products are MDR-compliant is even more compressed.

Manufacturers should therefore consider as soon as possible how both their existing and pipeline software products will be classified under MDR.

Comment

This article discusses just some of the changes under MDR which are likely to be most relevant to manufacturers of medical device software. However, other general provisions under MDR will also of course be applicable and may present issues in the context of software rather than “traditional” medical devices.

For example, the concepts of “importer” (being the EEA-established person or entity which places the device on the market in the EEA) and “distributor” (any person in the supply chain other than the manufacturer or importer that makes a device available on the market) can be harder to apply to intangible software, particularly apps launched by companies outside of the EEA which may be downloaded directly onto a patient’s mobile device without ever being physically “imported” into the EEA. Assessing the practical impact of certain obligations in relation to medical device software will therefore require close analysis of MDR.

Manufacturers of medical device software from all sectors would be encouraged carefully consider the requirements of the new legislation and how this applies to their business to ensure they have a clear strategy underway of how to achieve MDR-compliance within the timeframe available.