Pharmaceutical products and software medical devices are converging at an increasing rate – reflecting a trend towards personalised medicines. In some cases, this is relatively uncontroversial, such as the use of an App to track treatment regimens. In others, it is more complex, such as the use of sophisticated technology to determine and target medicinal treatments for individual patients. In any case, it is evident that traditional pharmaceutical companies need to be aware of developments in the regulation of software medical devices.
Against that background, the EU Medical Devices Regulation (2017/745) (EU MDR) was intended to come into full effect on 26 May 2020, repealing and replacing the Medical Devices Directive (MDD).
Software under the EU MDR
The EU MDR takes a far more direct (and strict) approach to classifying software than the MDD. In part, this reflects the increased sophistication and prevalence of software. Under the EU MDR, nearly all software medical devices will be up-classified from class I (the lowest risk class) to class IIa or above. This will require the involvement of a Notified Body for the first time. The source of this dramatic up-classification is Rule 11, Annex VIII of the EU MDR.
The phrasing of Rule 11 is very wide. First, it classifies all software medical devices which are “intended to provide information which is used to take decisions with diagnosis or therapeutic purposes” as at least class IIa. Most software medical devices on the market are clearly intended to provide information of this kind. For example, even software that operates as a thermometer would be captured, as the information generated is used to take diagnostic or therapeutic decisions.
In many cases, these devices will be further up-classified to the highest risk class: class III. Rule 11 of the EU MDR provides that if the decisions taken “may” cause death or an irreversible deterioration of a person’s state of health, the relevant device is class III. The term “may” in this context is very broad – to escape it, one would presumably have to prove that these events could not occur. In the case of medical devices, it is very difficult to identify a decision made on the basis of information from a device which could never cause death or permanent deterioration. To return to the example above, even a decision made on the basis of information provided by a simple software-based thermometer could cause death, if the decision was to delay treatment.
As such, there has been concern in the medical devices industry that many (or even all) software medical devices could be classified as class III. Compounding that concern, there was no formal guidance available until very recently on how Rule 11 would be applied.
The MDCG Guidance
On 11 October 2019, the Medical Device Coordination Group (MDCG) released Guidance on Qualification and Classification of Software (Guidance). The Guidance appears to attempt to soften the effect of Rule 11. It does so by reference to the position adopted by the International Medical Device Regulators Forum(IMDRF). The IMDRF approach is based on the significance of the information the software provides to an eventual healthcare decision, in combination with the condition of the patient.
The Guidance suggests that in classifying a device, a manufacturer should assess the influence of information provided by the device. For example, will it be determinative in a patient’s treatment, or just one factor. It also allows for assessments to be made as to the seriousness of the patient’s condition. For example, is the software influencing the treatment of cancer or a cold? These distinctions would allow manufacturers and Notified Bodies to be more pragmatic in classifying software medical devices than a strict reading of Rule 11 alone, although the Guidance is not legally binding.
Compounding the problems raised by an initial lack of guidance, manufacturers have faced a severe limitation on Notified Body capacity. All Notified Bodies are required to re-certify under the EU MDR. At the time of writing, however, only seven Notified Bodies have achieved this – by contrast, there were nearly 60 Notified Bodies actively assessing against the MDD. This combination of more manufacturers needing Notified Bodies with fewer Notified Bodies being available has given rise to an ‘approval bottleneck’, which could lead to serious shortages of devices if it continues.
In response, the Environment, Public Health and Food Safety Committee of the European Parliament recently approved a corrigendum to the EU MDR (Corrigendum), which provides a four-year ‘grace period’ for class I medical devices which are up-classified by the EU MDR. The Corrigendum, which was approved on 17 December 2019, provides devices that had a declaration of conformity issued under the MDD prior to 26 May 2020, and that require a Notified Body for the first time (i.e. most software medical devices), to continue to be placed on the market until 26 May 2024. This will afford more time for affected software medical device manufacturers to obtain a Notified Body and achieve compliance with EU MDR requirements.
While the regulatory requirements for software medical devices are increasing, the Guidance and the Corrigendum provide for more flexibility and time than originally anticipated. In light of this, perhaps the forecast for software medical devices is not as stormy as it was six months ago. Indeed, in September, Biotronik’s ‘Renamic’ programming software, which is a device that allows clinicians to program implanted cardiac devices, received certification under the EU MDR from German Notified Body TÜV SÜD. As far as we are aware, this is the first software medical device approved under the EU MDR. Hopefully, it heralds many more.
 This article does not address ‘Brexit’ but for completeness, we note that the EU MDR will be incorporated into UK law (with necessary amendments) in the event of a no-deal ‘Brexit’, including at the end of the transitional period under the envisaged Withdrawal Agreement between the UK and EU (dated 21 October 2019)
Since this article was written it has been confirmed that implementation has been delayed by 12 months due to the COVID-19 pandemic
 Council Directive 93/42/EEC