The EU’s regulatory rules for medical devices are due to change on 26 May 2020, when the new Medical Device Regulation (“MDR”) comes into effect. The regime for in vitro diagnostic devices will change two years later from 26 May 2022 when the In Vitro Diagnostic Devices Regulation (“IVDR”) will apply.
In advance of these changes, the EU Medical Device Coordination Group (“MDCG”) has recently published guidance on the Qualification and Classification of Software in the MDR and IVDR (the “Guidance”).
The aim of the Guidance is to assist manufacturers with interpreting the new Regulations to assess whether their software meets the definition of a medical device or an in vitro diagnostic device (i.e., “qualification”); and if so, what regulatory class the software would fall under (i.e., “classification”).
The MDCG is a coordination group established under Article 103 of the MDR, comprising up to two medical device experts from each EU Member State. Its key functions include contributing to the development of guidance to ensure effective and harmonized implementation of the EU’s new medical device rules. The Guidance is not legally binding nor does it necessarily reflect the official position of the European Commission. However, given the MDCG’s important role in the regulatory landscape, the Guidance is likely to be highly persuasive.
The Guidance continues to reflect the position that software intended by its manufacturer to have a medical purpose will be a medical device, as will software that meets the definition of an “accessory” for a medical device. The Guidance provides some commentary on how to qualify software that “drives or influences” medical devices (such as software for closed-loop insulin delivery systems that calculates the required insulin dose and drives the pump to administer it to the patient). For software that is independent of other devices and is not an accessory (e.g., medical or patient-facing apps), the key questions will be whether the software performs an action on data that is more than storage, archiving, communication or simple search and whether the action performed is for the benefit of individual patients. Much of that reflects current European Commission guidance.
The Guidance also provides a decision tree for manufacturers to assess whether or not their software falls within the scope of the MDR. There is a follow-up decision tree to help determine whether software falls under the MDR or IVDR. The Guidance is clear that software must first satisfy the definition of a medical device under the MDR, before it can fall within the scope of the IVDR.
Medical devices fall under one of four regulatory classifications (Class I, IIa, IIb and III). Class I is the lowest-risk classification and as a consequence there is a lower compliance burden on manufacturers. Class IIa and higher involve greater risk and manufacturers must meet more onerous requirements, including involving Notified Bodies in the product’s conformity assessment procedure.
The MDR establishes new classification rules specifically for medical device software (see Rule 11 of Annex VIII to the MDR). The Guidance explains that these are designed to align the MDR with broader international guidance on software, particularly with guidance from the International Medical Device Regulators Forum.
Many commentators had suggested that the new rules would result in the “up-classification” of software. Specifically, that a significant proportion of software that currently falls under Class I would move up to Class IIa or higher under the MDR. The Guidance confirms this interpretation. It suggests that the characteristics of software that make it a medical device in the first place are likely to mean it must fall under Class IIa or higher, the main exception being software that has no medical purpose.
Notably, the Guidance gives one example of software that might fall under Class I. The example is of a patient-facing conception-support app that calculates a user’s fertility status based on various inputs. In many ways, the example cited underlines that only a very narrow group of software devices could fall under Class I (e.g., devices that do not have a medical purpose and are not accessories but, like conception support apps, are considered to be devices under the MDR’s specific deeming rules).
The Guidance also provides some commentary on the classification of independent medical device software and software that drives or influences another device. In the latter case, software must fall within the same class of device that it drives or influences. The Guidance also re-emphasizes the rule that when two or more classification rules apply to the same software, the highest of the possible classifications applies.