Go to Client Portal
NAMSA

Qualification and Classification of Software Under the EU Regulations MDR and IVDR

What is Medical Device Software (MDSW)?

Over the past several years, software has become an essential tool in healthcare technology, revolutionizing patient care. Various types of software are being used in healthcare settings, from a software-based system storing patient information to innovative artificial intelligence that can accurately diagnose . For example, a software-based system that stores patient information is considered software for general purposes, as it primarily manages data without directly impacting patient health. On the other hand, software that uses artificial intelligence to diagnose conditions or suggest treatments qualifies as a medical device (MD) or in vitro diagnostic medical device (IVD) because it directly influences medical decisions and patient outcomes. This type of software is generally referred to Medical Device Software (MDSW) and is regulated by the EU Regulations 2017/745 (MDR) and 2017/746 (IVDR).

 

MDSW Definitions

In Europe, MDSW is defined as:

MDSW definition, MDCG 2019-11:

“Medical device software is software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” in the medical devices regulation or in vitro diagnostic medical devices regulation.”

This definition would include both Software as Medical Device (SaMD), as defined by the International Medical Device Regulators Forum (IMDRF), and Software in Medical Device (SiMD), which has no official definition but is understood as software that is a part of another medical device and cannot function separately.

SaMD definition, IMDRF:

Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical .”

Thus, software serving a medical purpose is considered a medical device and, as such, shall comply with the EU Regulation 2017/745 (MDR) or EU Regulation 2017/746 (IVDR). In comparison with the previous directives, the regulations have additional requirements for MDSW. To obtain the CE-marking for an MDSW, manufacturers should consider three critical steps:

  1. Qualification–Confirm that the software is an MD or IVD
  2. Classification–Identify the Class of the MDSW: I-III for MDs and A-D for IVDs
  3. Additional Requirements–Comply with specific MDSW requirements in the regulations

 

Qualification of MDSW as MD or IVD

The MDR Article 2 specifies that stand-alone software is a medical device if it is intended to be used by the manufacturer for one of the following purposes:

  • “Diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease,
  • Diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability,
  • Investigation, replacement or modification of the anatomy or of a physiological or pathological process or state,
  • Providing information by means of in vitro examination of specimens derived from the human body, including organ, blood and tissue donations,”

Similarly, the IVDR Article 2 defines that software is an IVD if it is used to provide information on one or more of the following:

  • Concerning a physiological or pathological process or state;
  • Concerning congenital physical or mental impairments;
  • Concerning the predisposition to a medical condition or a disease;
  • To determine the safety and compatibility with potential recipients;
  • To predict treatment response or reactions;
  • To define or monitoring therapeutic measures.”

In Europe, software can qualify as a medical device or IVD regardless of the user (healthcare or lay person, healthy or sick individual), the technology used (complex or simple algorithms), or its risk. The qualification of software as a medical device or IVD solely depends on the device’s intended purpose and whether this meets the definition of medical device or IVD in the regulations. Examples of MDSW include:

  • The software embedded in pacemakers to monitor and regulate heart rhythm (SiMD)
  • The software that is part of infusion pumps to calculate and control the delivery of controlled doses of medications (SiMD)
  • An app to track insulin levels (SaMD)
  • A software that processes and analyzes MRI images to assist the diagnosis of certain conditions (SaMD)

Software can also be considered MDSW if it is an accessory of an MD or IVD, or if it is listed in MDR Annex XVI (devices without medical purpose).

Another important aspect to consider is whether the software performs any action on the data that is different from storage, archival, communication, or simple . For example, an electronic health record system that only stores and retrieves patient records or a patient appointment scheduling system would not be considered MDSW.

In addition to definitions in the regulations concerning software, MDCG 2019-11 “Guidance on Qualification and Classification of Software” provides a figure with decision steps to facilitate software qualification as MDSW, adapted below.

 

What About Fitness or Wellness Applications?

Whereas health and wellness apps provide information on lifestyle, fitness, or well-being, MDSW provides information for the treatment or diagnosis of a disease or clinical condition–it has a medical purpose. The MDR mentions explicitly that fitness or wellness applications are not MDSW:

“Software for general purposes, even when used in a healthcare setting, or software intended for life-style and well-being purposes is not a medical “.

Non-MDSW Examples:

  • A health app that tracks nutrition intake to help manage weight
  • An app that informs users of their heart rate during the day

These apps do not perform actions that qualify them as medical devices under the MDR because they do not provide medical information or make medical decisions.

 

MDSW Examples:

  • A nutrition tracker app that calculates the dose of insulin needed for a patient with diabetes
  • An app that informs users of their heart rate and, for heart failure patients, takes into account other user information to provide the probability of a heart attack

These apps qualify as MDSW because they perform actions that influence medical decisions or provide medical information, thus falling under the MDR.

 

Classification Rules Under the MDR and IVDR

Under the Medical Device Directive (MDD) and the In Vitro Diagnostic Medical Device Directive (IVDD), medical device software (MDSW) was generally considered to be low risk and, therefore, often deemed a lower risk device. Specifically, MDD considered MDSW to be an active medical device, following rules 9 to 12 (Annex IX, Section III), with an outcome that could range from Class I to Class IIb. Though in reality, software was typically classified as a Class I MD. Software used with IVDD tests, were considered to be a “General/Other” IVD except if it was intended for evaluating the risk of trisomy 21, in which case it was in List B (Annex II).

With the implementation of the MDR and IVDR, the MDSW classification system has changed, and it now receives more attention.

Both the MDR and IVDR specify in their Implementing Rules Annex VIII that:

“Software, which drives a device or influences the use of a device, shall fall within the same class as the device.

If the software is independent of any other device, it shall be classified in its own right.”

The MDR contains a specific classification rule for stand-alone software: Rule 11 (Annex VIII). This rule states that:

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 a 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 danger to the patient, in which case it is classified as Class IIb.

All other software is classified as Class I.”

The IVDR does not contain a specific classification rule for stand-alone software, and IVD MDSW is classified using the seven classification rules in Annex VIII according to its intended purpose.

 

Additional MDCG Guidance Document for MDSW Classification

According to MDR Rule 11, the classification for stand-alone software can range from Class I to Class III, depending on the potential impact of the clinical decision an individual has to make based on the results or output by the software.

Since this rule does not provide a literal interpretation, to avoid the related legal uncertainty, the IMDRF risk framework is suggested to assist in the classification. This framework has been adopted for the MDR into MDCG 2019-11 which provides a table (adapted below) that facilitates device classification based on: (1) the significance of the information provided by the MDSW to a healthcare situation related to diagnosis/therapy; and (2) the state of healthcare situation or patient condition. Interestingly, Class I does not appear in the table, suggesting that MDSW under the MDR Class I will be rare, and software will tend to have a higher risk classification.

MDCG 2019-11 states that the implementing rules (MDR Annex VIII, Implementing Rule 3.3, or IVDR Annex VII, Implementing Rule 1.4) should also be considered for orientation to find the correct classification of software that drives or influences the use of a device. Therefore, a MDSW that both achieves its intended purpose and drives or influences the use of another MD for a medical purpose is classified on its own, based on the intended purpose achieved. In such a case, however, the risk class shall not be lower than the risk class of the MD.

In MDCG 2019-11, Implementing Rules 3.5 and 1.9 (MDR Annex VIII or IVDR Annex VII, respectively) are also considered to be relevant for all devices, which state:

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 higher classification will apply.

 

Difference Between MDR/IVDR Classification vs IEC 62304 Software Classification

Besides the MDR and IVDR, there are additional standards to consider when classifying MDSW’s risk class. The IEC 62304 is an international that specifies life cycle requirements for the development of MDSW. IEC 62304 classification system focuses on safety and is independent of the classification systems in the MDR and IVDR.

In general, the MDR defines Classes I, IIa, IIb, and III depending on the risk the device poses. Accordingly, the IVDR defines Classes A to D, where class A includes the non-critical devices and Class D the most critical devices. Software Safety according to IEC 62304 is divided into three classes:

  • Class A: If the software cannot cause any harm
  • Class B: If the software can cause minor harm such as injuries
  • Class C: If the software can cause major harm such as severe injuries or even death

The software safety class determines the amount and specificity of required software documentation as follows:

Summary

In summary, the role of Medical Device Software (MDSW) in healthcare systems is becoming increasingly significant, both as stand-alone applications and as integral parts of traditional medical devices. Under the EU Regulations MDR and IVDR, software qualifies as MDSW if it directly influences medical decisions or patient outcomes. The classification of MDSW depends on its intended purpose, with the MDR providing specific rules for stand-alone software and the IVDR using a broader set of classification criteria. Additional guidance, such as MDCG 2019-11, further supports the classification process, ensuring that MDSW is appropriately regulated to maintain patient safety. As healthcare technology continues to evolve, understanding and adhering to these regulations is essential for manufacturers to ensure compliance and deliver safe, effective medical software.

 

NAMSA Can Help You Bring Your MDSW to the market

At NAMSA, we specialize in Medical Device Software (MDSW) and are dedicated to helping you navigate the critical steps required to bring your MDSW to market. Our team of experts ensures patient safety and device performance while developing a comprehensive go-to-market strategy tailored to your software. We assist in defining the intended purpose, classifying your device, and identifying the optimal pathway to gather necessary clinical evidence. Ultimately, we support your team in meeting all MDSW-specific requirements and dealing with Notified Body and Competent Authority feedback. Contact us for more information.

Ariadna Navarro

Dr. Ariadna Navarro has a strong scientific background with a PhD in Cardiovascular Sciences and close to ten years of experience in preclinical and clinical research. During her academic career, she collaborated with In Vitro Diagnostic (IVD) manufacturers in the design of strategies and the set up of in vitro techniques to diagnose several cardiovascular and neurological disorders. Dr. Navarro’s medical device industry experience includes working as Clinical Research Scientist and Clinical Study Manager, gaining thorough knowledge in the design, set-up and conduct of clinical investigations according to ICH/GCP guidelines, ISO 14155 and ISO 20916. Ariadna has also developed a strong experience in Regulatory Affairs and Quality Assurance, and she has expert competence on the European regulatory landscape (MDR 2017/745, IVDR 2017/746 and the MEDDEV/MDCG guidance documents). She is a certified ISO 13485 Lead Auditor with experience in setting up medical device quality management system standards aiming to support manufacturers placing and maintain their devices in the market.