How software may be classified under medical device regulation guidance

Marie Manley and Zina Chatzidimitriadou, of law firm Sidley Austin, discuss how software will be classified under the new European medical device regulatory framework.

The new regulatory landscape on software medical devices that will apply under the new Regulations (Regulation (EU) 2017/745 (Medical Device Regulation (MDR)) and Regulation (EU) 2017/756 (In Vitro Diagnostic Regulation (IVDR)) as of 26 May 2020 and 26 May 2022 respectively, has been somewhat clarified by new guidance published by the European Commission’s Medical Devices Coordination Group (MDCG). Given that the Guidance has been the result of considerable work/ deliberations by the MDCG, due to the particularities of and fast pace of innovation in software as a medical device, one would expect more topics to have been addressed and perhaps in more depth. Still, this Guidance provides the first valuable insight into how software will be classified under the new Regulations, while more specific examples will continue to be included in the Borderline manual guidance.

Key features of the Guidance

• No change in qualification. Generally, the Guidance sets out that the principles applicable under the current regime regarding the qualification of software as MDSW will remain the same. In particular, “risk of harm to patients” is only a relevant factor in the classification, rather than the qualification as MDSW, which is also in line with the jurisprudence of the Court of Justice of the European Union. The same decision tree as in MEDDEV 2.1/6 is provided to assist the qualification decision-making. The Manual on Borderline and Classification of Medical Devices in the Community (currently under revision for adaptation to the MDR) should be consulted for more specific products.
• Software managing images. The Guidance includes many specific illustrative examples on software managing images, for example, software altering the representation of data or changing an image display so that it serves as decision support. This is a broad category of software and the Guidance sets out that image optimising means can be medical software. Likewise, attention is drawn to image management systems (IMS), which are systems primarily intended to be networked with digital pathology systems designed to access, display, store, etc. digitised patient images. Where an IMS is used with additional modules (that enable the IMS to support post-processing of images for diagnostic purposes, etc.), the modules might qualify as MDSW. The Guidance has not changed from the content of MEDDEV 2.1/6, but it is more explicit. Under the current rules and guidance, it could be argued that if the technical image software can be separated from the medical software, then a modular approach may allow the technical imaging software to escape CE marking. Under the MDR, this distinction now becomes more difficult. An example provided in the Guidance is “a melanoma image analysis software intended to drive a near-infrared laser light scanner,” which would qualify as a medical device. Not only will the software qualify as a MDSW, but it will also acquire a higher classification under the MDR (as explained below).
• No clarification on “placing on the market.” The MDR’s concept of “placed on the market” is a complex determination for MDSW compared to tangible/hardware devices. Unfortunately, the Guidance has missed the opportunity to clarify when a MDSW is deemed as being “placed on the market.” The timing of “placing on the market” is highly relevant for medical devices, particularly because (i) under the current rules, devices “placed on the market” can benefit from the transitional period before May 26, 2020 and May 26, 2022; and (ii) if Brexit materialises, whether a device has been “placed on the market” in the UK before Brexit would determine the validity of certification of these devices in order to continue being marketed in the remaining EU countries (e.g., if there were to be a grace period). So MDSW manufacturers must continue to rely on and interpret the existing guidance on what constitutes “placing on the market.”
• Important changes in classification of diagnostic/monitoring software. Under the current rules, all standalone software has ordinarily been classified as Class I devices. However, the MDR introduces new classification rules for various types of software. The Guidance confirms that as all MDSW are software intended to assist decisions for diagnostic or therapeutic purposes, the default classification for all MDSW is Class IIa, unless there are reasons for a higher classification. Likewise, software monitoring physiological processes is now classified as Class IIa or higher. Generally, the examples in the Guidance clarify that MDSW intended to perform diagnoses by means of image analyses for treatment decisions, or software with a diagnostic function enabling a treatment option, would bear the highest classification. A lot of software products classified as Class I under the current rules will be upgraded to Class IIa and above once the MDR becomes applicable. In the event of several rules applying to the same device, the strictest rule resulting in higher classification will apply.
• Software driving or influencing a device. Under previous guidance, software driving or influencing a medical device or the use of a device will automatically fall into the same class as the device it drives. The Guidance recognises that whilst software may drive or influence the use of another device, it might be achieving its own intended purpose. Such software will be classified in its own right and will have at least the same risk class as the hardware medical device, but possibly a higher one. The Guidance provides an example of a melanoma image analysis software intended to be used with a near-infrared laser light scanner. Whilst the scanner is considered a Class IIa device under Rule 10 of the MDR, the software driving it would also be subject to Rule 11 as a tool involved in cancer diagnosis, and as such would be classified as Class III. This could have a significant impact for many software manufacturers.
• Modular approach. A modular approach to the qualification of software is possible under the current rules, provided that there can be a true separation in functionality. As a result, only parts of the device would fall within the scope of the MDR/IVDR. Manufacturers may want to consider whether a modular approach would be practicable or even feasible at all. For instance, this could be particularly relevant in software modifying images (which, in itself, would not ordinarily be subject to the MDR/IVDR).
• Transition periods. Manufacturers must consider the feasibility and potential benefits of launching MDSW prior to May 26, 2020 (MDR), and May 26, 2022 (IVDR), if possible, to take advantage of the grace periods, during which they will still need to comply with all the necessary requirements under the MDR and IVDR such as quality management system (QMS) and vigilance.

Conclusion

The Guidance has confirmed the position that hardly any MDSW will remain as Class I under Rule 11. This will inevitably lead to an increased workload for manufacturers and Notified Bodies alike. Although the Guidance is aimed at aligning the EU position with IMDRF guidance, which in turn was created partly in order to soften the impact of Rule 11 by introducing the table of classification, there is no guarantee that it will be interpreted uniformly, particularly given that it does not have a legally binding effect. The main issue under the new Regulations remains that classification appears to be based on the severity of the risk, i.e. if a potential outcome could be death or irreversible deterioration, this would be enough to up-classify the software to Class III regardless of  whether the actual risk of failure of the device is minimal or almost non-existent.

Perhaps Rule 11 and the Guidance reflect the level of complexity and sophistication of new technologies, which has resulted in software being increasingly relied upon by patients and healthcare professionals alike in the management of patients’ conditions and therefore prompted the authorities to impose a high level of scrutiny to ensure the protection of public health. Some commentators have raised concerns on whether this would have a deterrent effect on the development of new software technologies.

Whilst this Guidance is a step in the right direction in clarifying the MDR, all eyes are turned to the MDCG, which expects to publish 47 guidance documents on clinical evaluation, clinical investigations and notified bodies under the new Regulations. Manufacturers are advised to have a robust system of pre- and post-market data collection to support new functionalities and a good risk management and quality management plan in order to facilitate the dealings with Notified Bodies and new software functionalities. The European Commission has acknowledged the difficulties that manufacturers of software devices currently falling under Class I are facing in order to upgrade the classification of existing devices within the required period of time. We expect, in the circumstances, that the Commission will grant a grace period for compliance for Class I software which will need to go through a Notified Body certification for the first time to ensure uninterrupted access of patients to potentially life-saving technologies.