In October 2019, the European Commission’s Medical Devices Coordination Group (MDCG) published a new guidance on the qualification and classification of software as medical devices (MDSW) under the new Medical Devices Regulation (MDR) and In Vitro Diagnostic Regulations (IVDR) (the “Guidance”). The Guidance aims at providing clarification to medical software manufacturers with respect to (i) qualification issues (when software is considered a device); and (ii) classification issues, depending on the risk category of the device.
As to qualifying software as a medical device, there are no significant changes compared to the current regulatory framework. Conversely, with respect to the classification issues, the Guidance generally assigns to MDSW a higher class of risk compared to the current one, under Rule 11 of the MDR, as better explained below.
The Guidance also specifies that the criteria reported therein shall also apply to applications (apps), whether they are on a mobile phone, in a cloud or on other platforms.
1. Software as medical devices under the MDR
According to the new classification rules provided by the MDR (Rule 11):
- Software intended to provide information used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, except where 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 a surgical intervention, in which case it is classified as Class IIb.
- Software intended to monitor physiological processes is classified as Class IIa, but
- if it is intended to monitor vital physiological parameters, where the nature of variations of those parameters is such that could result in immediate danger to the patient, it is classified as Class IIb.
- All other software is classified as Class I.
Therefore, under the MDR, most of MDSW will probably fall into Class IIa or higher. This is a first very significant change compared to the previous regulatory framework. Indeed, under currently applicable rules, as also interpreted by the MEDDEV 2.1/6 guidance, most software are classified as low risk and fall into Class I.
In consideration of this major change in MDSW classification rules, the Guidance intends to provide some further clarifications on how to implement such new rules.
The main news in the Guidance
The Guidance does not provide any substantial change in the criteria for classifying software as medical devices (for instance, the Guidance includes the same decision tree as in MEDDEV 2.1/6).
In this respect, the Guidance points out that not all software used in healthcare is qualified as a medical device. For example, “Simple search”, which refers to the retrieval of records by matching record metadata against record search criteria or to the retrieval of information does not qualify as medical device software (e.g. library functions). However, software that is intended to process, analyze, and create or modify medical information may be qualified as medical device software if the creation or modification of that information is governed by a medical intended purpose. Indeed, the intended purpose described by the manufacturer of the software is relevant to qualify and classify any device.
Conversely, the Guidance gives some significant clarifications concerning the interpretation of Rule 3.3, Rule 3.5 and especially Rule 11, by giving examples on each of the three sub-rules listed above.
Specifically, with respect to Rule 3.3 which lays down that software which drives or influences the use of a device shall fall within the same class as the device, the Guidance clarifies that this rule should be considered as an orientation for finding the correct (minimum) classification of software that is placed on the market in combination with a (hardware) medical device. Therefore, if a MDSW both achieves its own intended purpose and drives or influences the use of a (hardware) device for a medical purpose, it shall be classified on its own, based on the intended purpose achieved. In such case, however, the risk class shall not be lower than the risk class of the hardware medical device.
This is consistent with Rule 3.5, which lays down the important principle by which, if several rules (or if, within the same rule, several sub-rules) apply to the same device based on the device’s intended purpose, the strictest rule and sub-rule resulting in a higher classification will apply.
2. Clarifications on placing the MDSW on the market
Moreover, the Guidance contains some considerations on placing the MDSW on the market and its conformity assessment. Specifically, it establishes that:
- MDSW may be placed on the market or put into service in its own right (e.g., MDSW apps): in such case, the MDSW shall undergo un appropriate regulatory process that shall take into consideration the qualification, classification and intended purpose of the MDSW; or
- MDSW may be placed on the market or put into service as an integral component/part of a device (e.g., MDSW that is part of a handheld hardware device intended for near-patient testing (POCT: point of care testing) to determine blood glucose concentration: in this case, MDSW may not have to undergo its own regulatory process, but shall be assessed through the regulatory process applied to the device as a whole, as it is placed on the market.
However, the Guidance does not provide any clarification on what “placing on the market” means with specific regard to MDSW, which may be marketed using different channels compared to physical devices (e.g., the Internet).
3. Possible modular approach
The Guidance points out that some MDSW may be segregated into a number of applications where each of these applications is correlated with a module. Some of these modules have a medical purpose, some not. Such modules may be intended to cover many needs, such as to collect and maintain administrative patient data, to keep patients’ medical history on file or for invoicing and other accounting functions. This raises the issue as to whether the whole product can be CE marked when not all applications have a medical purpose.
In this case, the Guidance clarifies that it is the obligation of the manufacturer to identify the boundaries and the interfaces of the different modules. The modules which are subject to the MDR must comply with the requirements of the medical device regulations and must carry the CE marking. The non-medical device modules are not subject to the requirements for medical devices.
4. A changing classification
Finally, the Guidance reminds manufacturers that they shall evaluate the potential impact of any changes to the function, intended use, essential design, and manufacturing characteristics on the software’s qualification as MDSW and its classification (including the classification of the combination of the MDSW with another medical device).
Indeed, a change to or the addition of functionality to a software may lead to it being qualified as MDSW, or a revision of the classification of the MDSW. Similarly, a module that is added to software might be qualified as MDSW on its own.
5. Rapid evolution of software for medical purposes
Considering how fast the technology applied to MDSW is evolving, the list of examples provided by the Guidance is not comprehensive, since they have been drafted in consideration of today’s state of the art.
For the purpose of providing further updated examples to support MDSW’s manufacturers, the Manual on borderline and classification in the Community regulatory framework for medical devices is currently under revision to adapt it to MDRs. In light of the technological progress, further examples will be regularly published in both the Manual and in this guidance.
