The European Commission’s Medical Devices Coordination Group (MDCG) recently published guidance on the qualification and classification of medical device software under the new EU Medical Devices Regulation (MDR) and the EU In Vitro Diagnostic Medical Devices Regulation (IVDR).
The guidance provides helpful clarification for manufacturers and, although not legally binding, is likely to be followed by notified bodies and competent authorities. In particular, it provides some welcome clarity on the classification of software medical devices.
Background to the MDR and IVDR
The MDR ((EU) 2017/745) and the IVDR ((EU) 2017/746) (the Regulations) came into force on 25 May 2017. The regulations were introduced following a number of instances where medical devices were found to be defective (including those involving silicon breast implants and surgical meshes) and are intended to apply more rigorous regulatory requirements to medical devices before they can be placed on the market.
Following an initial transition period, the MDR and IVDR will become fully in force in all EU Member States from 26 May 2020 and 2022, respectively. During the transition period, devices can be placed on the market under current EU Directives or the new Regulations.
The UK has confirmed its continuing commitment to implementing the MDR and IVDR. The UK will transpose the key elements of MDR and IVDR and will bring the Regulations into effect in line with the EU timetable (ie. 26 May 2020 for MDR and 2022 for IVDR).
The Regulations require medical devices to be correctly classified against new risk criteria. With regard to the classification of software medical devices, many manufacturers were of the view that the wide drafting of the Regulations would mean a large proportion of medical devices would fall within class IIa or III. Under the currently applicable rules on medical devices (as supported by the European Commission’s previously published guidance set out in MEDDEV 2.1/6) most software devices are classified as low risk and currently fall within class I.
MDCG’s guidance and what it means for commerce and industry
This eagerly awaited guidance seeks to clarify when software will constitute a medical device (qualification) and, if so, the risk class assigned to it (classification).
The guidance confirms that medical device software is “software that is intended to be used, alone, or in combination, for a purpose as specified in the definition of “medical device” in the MDR or IVDR, regardless of whether the software is independent or driving or influencing use of the device.”
The guidance clarifies that not all software used within healthcare is classified as a medical device. For example, the guidance provides “Simple search” – referring to the retrieval of records – as not constituting a medical device. Equally, staff planning or invoicing software would not be medical device software.
Generally, software which processes, analyses, creates or modifies medical information will qualify as medical device software if it is intended to have a medical purpose. The same decision tree as in the previous guidance MEDDEV 2.1/6 is included in the new guidance to assist manufacturers in determining whether their software will constitute a medical device. The guidance also confirms that software must first fall within the definition of a medical device under the MDR before it can fall within the IVDR.
The guidance provides that medical device software may constitute a medical device in its own right, or qualify as medical device software where the software drives or influences a (hardware) medical device and also has a medical purpose. It includes some examples of where software “drives or influences” medical devices, including melanoma image analysis software intended to drive a near-infrared laser light scanner.
The guidance also notes that the type of interconnection between the medical device software and the hardware device (eg Wi-Fi, Bluetooth) does not affect qualification under the MDR and IVDR. It is also irrelevant whether the end-user is a healthcare professional or member of the public.
The guidance confirms that risk of harm to patients is not a criterion on whether software qualifies as a medical device. However, it is relevant in relation to classification.
Classification of software
The classification rules in the MDR provide at Rule 11 of Annex VIII:
“Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause:
- death or an irreversible deterioration of a person’s state of health, in which case it is in class III; or
- a serious deterioration of a person’s state of health or surgical intervention, in which case it is classified as class IIb.
Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate damage to the patient, in which case it is classified as class IIb.
All other software is classified as class I.”
The guidance breaks Rule 11 down into three sub-rules. It confirms that:
- For all medical device software intended to assist decisions for diagnostic or therapeutic purposes the default classification shall be class IIa (unless there are reasons for a higher classification)
- Medical device software intended to monitor physiological processes shall similarly be class IIa (unless variations to those physiological parameters could cause the patient immediate danger, in which case the classification would be higher.) (the penultimate paragraph of Rule 11)
- All other software is class I (the last paragraph of rule 11).
Consequently, a number of software products, particularly those involved in diagnosis or monitoring and currently classified as class I, will fall within Class IIa or above once the MDR takes effect. With regard to software that drives or influences a device, the guidance recognises that such software may, in addition to driving or influencing another device, also be achieving its own intended purpose. In such a case, the risk class will not be lower than the risk class of the hardware medical device.
Using the example of the melanoma image analysis software intended to be used with a near-infrared laser light scanner (mentioned above), the guidance notes that the scanner would be considered Class IIa under Rule 10 of the MDR. In addition, the software driving the scanner would be subject to Rule 11, and, as a device used in cancer diagnosis, would be classified as class III.
The Regulations permit a modular approach in relation to the qualification of software, provided there is separation of functionality. Where software can be broken down into a number of applications where each correlates to a module, some modules may have a medical purpose and others will not.
This raises the question of whether the whole product can be CE marked. The guidance suggests that modules that are software medical devices will be subject to the Regulations. It is the responsibility of the manufacturer to identify the boundaries of the different modules and those subject to the Regulations must be clearly identified as such.
The guidance provides helpful clarification for medical software manufacturers and includes a number of useful illustrative examples. It confirms that a large proportion of medical device software currently classified as Class I under the current rules will be upgraded to Class IIa or higher under the MDR.
Companies currently producing software to be used in connection with medical devices, or as a standalone medical device, should be aware of these changes and implement any measures necessary to ensure that their software is compliant with the new regime.