European Commission Provides Important Guidance on Qualification and Classification of Software Under New Medical Devices Regulations

The European Commission’s Medical Devices Coordination Group (MDCG) has published a much-anticipated guidance on the qualification and classification of software devices as medical devices (MDSW)¹  under the new Medical Devices Regulation (MDR) and In Vitro Diagnostic Regulations (IVDR) (the Guidance, available here). The Guidance seeks to provide clarification to medical software manufacturers with respect to (i) when software is considered a device (qualification) and (ii) what risk category the device falls into (classification).

Under the currently applicable rules, supported by guidance set out in MEDDEV 2.1/6² , most software devices are classified as low risk. However, the new classification rules set out in the MDR, in particular Rule 11, significantly change the classification of MDSW, with many software devices to be generally considered medium- or even high-risk devices.

Below we examine which areas have been clarified by the Guidance and which topics remain open to interpretation.

Key Points to Highlight

• 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 optimizing 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. digitized 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 materializes, 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 analyzes 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 recognizes 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

Overall, the Guidance is better aligned with new technologies and has been bolstered with new examples of novel software, such as software receiving and analyzing measurements to detect a condition or calculate a risk of a condition (including smartwatch apps). References are also made to next generation sequencing (NGS) data analysis, in line with the tendency for personalized medicine and reflecting the recent collaborations concluded in this space. The Guidance also caters for telemedicine and widely available mobile apps by clarifying that such products may be MDSW regardless of the location (to encompass cloud-based and remotely operated software) or identity of the user (such a user could be a healthcare professional, a patient or a layperson).

The importance of gathering robust clinical evidence is essential to support existing claims, as well as the collection of post-market data to support the safety and efficacy of the software, especially for more novel technologies where efficacy is best confirmed over longer periods of time. This is particularly necessary in instances where software will receive higher classification than presently. Considering the frequent updates to software and its functionality, the proper collection of post-market data would enable the creation of a robust technical file and could support new functionalities.

¹ See MDR, Annex VIII, Chapter III, section 6.3 setting out Classification Rule 11.

² See Guidelines on the qualification and classification of standalone software used in healthcare within the regulatory framework of medical devices, MEDDEV 2.1/6, July 2016, available here.

³ See, inter alia, Case C-219/11 Brain Products [ECLI:EU:C:2012:742] and C-329/16 Snitems and Philips France [ECLI:EU:C:2017:947].

⁴ See Manual on borderline and classification in the community regulatory framework for medical devices, current version is 1.22 of May 2019, available here (current version is 1.22 of May 2019).

⁵ For instance, please refer to the European Commission’s Q&A related to the UK’s withdrawal from the EU with regard to industrial products, https://ec.europa.eu/info/sites/info/files/qa_brexit_industrial_products_en.pdf, the UK government’s guidance on “Definition of ‘placing on the market’ before and after the UK leaves the EU if there is no Brexit deal,” https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/792539/placing-on-market-definition.pdf, the Blue Guide Guidance on “placing on the market,” etc.