Having shed light on the relevance of the intended purpose of a medical device when determining whether software qualifies as medical devices software (“MDSW”) under the new EU Medical Device Regulation 2017/745 (“MDR”) in part 2 of our series of articles, in this part 3, we now turn to the issue of risk classification of such MDSW under the MDR.
INTRODUCTION
Under the current EU Medical Device Directive 93/42/EEC (as amended by Directive 2007/47/EC – “MDD”), most stand-alone MDSW (i.e., MDSW not implemented in a more complex medical device, such as control software) including, for instance, a mobile app that allows users to take pictures of moles on their skin and evaluates whether it is a melanoma, are classified as Class I medical devices and therefore subject to self-certification (see Manual on Borderline and Classification, Version 1.22, page 81). This is likely going to change under the MDR, coming into full effect on May 26, 2021. Due to new classification rules, significantly more stand-alone MDSW will likely be classified as Class IIa or higher. This means that obtaining CE markings for stand-alone MDSW will more often require involvement of a notified body with an increasing level of scrutiny depending on the determined class.
1. THE EU RISK CLASSIFICATION SYSTEM
Already under the current MDD regime, medical devices, such as stand-alone MDSW, are classified according to their intended purpose and their inherent risks, and are divided into the following four risk classes: Class I (lowest-risk class), Class IIa, Class IIb, and Class III (highest‑risk class).
These risk classes determine which conformity assessment procedures are required to obtain CE markings and range from self-certification (for Class I) to a full review of the technical design and manufacture of the specific device by a notified body (for Class III). Self-certification includes compliance with general safety and performance requirements, performance of clinical evaluation, preparation of technical documentation, and the issuance of an EU Declaration of Conformity. In addition to that, a Class IIa examination requires that a notified body examines the quality management system (“QMS”) and the technical data of one representative product sample per product category. In Class IIb, examination is conducted per generic product group, and in Class III, the QMS and technical data of every product must be examined.
2. AMENDED RISK CLASSIFICATION SYSTEM FOR MDSW UNDER THE MDR
The classification of MDSW under the MDR will take place in accordance with Annex VIII of the MDR. For classification purposes, MDSW, just like hardware devices, is considered an active device and can be classified in all four risk classes. Depending on whether the MDSW is a stand‑alone MDSW, an accessory to a hardware device, or drives or influences the use of a hardware device for a medical purpose, Rules 9, 10, 11, 12, 13, 15, and 22 of Annex VIII, Chapter 3 to the MDR (the “Rules”), can be relevant. Stand-alone MDSW, such as most health apps, will be classified independently from any hardware medical device (Annex VIII, Chapter 2, para. 3.3 of the MDR) and will thus mainly be governed by Rule 11 of Annex VIII to the MDR (“Rule 11”).
According to Rule 11:
(a) Software intended to provide information that 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 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.
(b) 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 danger to the patient, in which case it is classified as Class IIb.
(c) All other software is classified as Class I.
In light of the foregoing it seems that a significant portion of stand-alone MDSW will fall in the higher risk classes IIa to III, as most of the stand-alone MDSW with an intended medical purpose will likely also provide information that is used for decision-making with diagnosis or therapeutic purposes.
3. A MORE DIFFERENCIATED APPROACH TO CLASSIFICATION
However, classification of stand-alone MDSW under the MDR will not be black and white. Guidance and a more detailed approach on risk categorizations and classification under Rule 11 is provided by the European Commission’s Guidance on qualification and classification of software in Regulation (EU) 2017/745-MDR and Regulation (EU) 2017/746-IVDR (in the version of October 2019; “MDCG 2019-11”). Although the MDCG 2019-11 are not binding, as official documents, they should be taken into consideration when assessing software for classification under the MDR.
According to the MDCG 2019-11, Rule 11 mirrors the regulatory guidance developed at the international level — more specifically, in the context of the International Medical Device Regulators Forum (“IMDRF”). The IMDRF framework for risk categorization of software as a medical device (SaMD) (“IMDRF Risk Framework”) categorizes the risk of software based on the combination of two factors:
i. the significance of the information provided by the software to the healthcare decision,
and
ii. the healthcare situation or patient condition.
In this regard, the IMDRF has developed a table for assisting manufacturers in identifying the appropriate risk category for their MDSW. This table was further supplemented by the European Commission and included in Annex III to the MCDG (“Amended IMRF Framework”) to reflect the corresponding MDR risk classes according to Rule 11:
Source: Annex III of the MDCG 2019-11
The Amended IMRF Framework allows a more differentiated approach to risk categorization and classification of stand-alone MDSW under Rule 11. For example, a mobile app intended to analyze a user’s heartbeat, detect abnormalities, and inform a physician accordingly may be classified as Class IIb per Rule 11(a), if the information provided by the software is intended to guide the physician in the diagnosis, because the information drives clinical management and the health care situation can be critical.[1] Yet, if the MDSW were intended to automatically adapt treatment (e.g., medication plans) of, for example, cardiac arrhythmias, it may be classified as Class III per Rule 11(a), as not only would the health care situation be critical but the MDSW would also be used to take immediate action to treat a disease or a condition.
On the other hand, MDSW intended to rank therapeutic suggestions for a health care professional based on patient history, imaging test results, and patient characteristics (e.g., a MDSW that lists and ranks all available chemotherapy options for BRCA-positive individuals) may be classified as class IIa per Rule 11(a) since, albeit cancer being a critical disease, the MDSW only informs clinical management about the options.[2]
It must be noted that the table does not take into account MDSW, which is Class I, as Class I MDSW falls outside the IMDRF risk categories.
4. ROOM FOR CLASS I CLASSIFICATION OF MDSW
However, a classification in Class I still remains possible. This will be the case for stand-alone MDSW that — even though intended for medical purposes — stays under the threshold set out by Rules 11(a) and (b) and thus falls under Rule 11(c). Manufacturers of MDSW should therefore not assume by default that any MDSW must at least be Class IIa but will still find it worthwhile to carefully assess whether the features of the software do not rather warrant a Class I categorization.
For example, an app intended to support conception by calculating the user’s fertility status based on a validated statistical algorithm in which the user inputs her own health data (i.e., basal body temperature (BBT) and menstruation days) to track and predict ovulation and in which the fertility status of the current day is reflected by one of three indicator lights (i.e., red = fertile, green = infertile, or yellow = cycle fluctuation) may be regarded as Class I, as this MDSW is neither used to take decisions with diagnosis or therapeutic purposes, nor does it monitor physiological processes. Another example may be a mobile app that assists users with a medical condition to self-manage their condition or to pursue a healthier lifestyle based on data provided (e.g., sleeping hours, heart beat frequency) and preferences selected by the user, including increased body activity or recommendations concerning regular sleep.
It is important to note that, other than the MDCG 2019-11, which are not binding, there are no conclusive guidelines as of now, and naturally no examples of enforcement or relevant court decisions applicable to Rule 11 due to its significant deviances from the framework under the MDD. Therefore, practical appliances will only clarify the continued relevance of Class I classifications when the MDR will be applicable.
CONCLUDING REMARKS
Developers and operators of new stand-alone MDSW not yet placed on the EU market need to brace themselves for the new, more rigid classification system under the MDR, which will likely make more products subject to the direct involvement of the notified bodies. Therefore, obtaining CE markings will become more complex and time consuming. A careful assessment should be made, taking into account the intended purpose and the functions of the stand-alone MDSW and by applying the Amended IMRF Framework. Under certain requirements, stand-alone MDSW already on the EU market and classified as a Class I medical device under the MDD will only be required to comply with the new rules as of May 26, 2024. We will discuss these requirements in more detail in Part 6 of our series of articles on Software as a Medical Device in Europe, available on March 19, 2021.
[1] See Annex IV of the MDCG 2019-11on classification examples.
[2] See Annex IV of the MDCG 2019-11on classification examples.