Qualification and Classification of Software under MDR and IVDR: Essential Foundations for Medical Device Software (MDSW)

Software developed for specific medical purposes is subject to complex qualification and classification processes under the Medical Device Regulation (EU) 2017/745 (MDR) or the In Vitro Diagnostic Medical Device Regulation (EU) 2017/746 (IVDR). This text explores the requirements imposed on Medical Device Software (MDSW) regardless of whether this software is a standalone medical device (Software as Medical Device (SaMD)) or embedded in the hardware of medical devices. We also review relevant MDCG guidances to provide clarity on compliance. Learn how precise classification and early coordination with Notified Bodies can contribute to safe and compliant implementation.

What Constitutes Medical Device Software (MDSW)?

Medical Device Software (MDSW) under MDR and IVDR is defined as software intended for human use which, alone or in combination, fulfills one or more specific medical purposes as listed in the medical device definition (Article 2 (1) MDR). MDSW can function as standalone software or be embedded within the hardware of a medical device.

For adequate oversight of MDSW quality and safety by Notified Bodies, MDR and IVDR also define qualification and classification requirements based on intended purpose, risks, and potential impacts on patient health.

According to the definition of MDSW, software must meet one or more specific medical purposes, making the manufacturer's intended purpose crucial for MDSW qualification. Notably, runtime environments (e.g., cloud, medical device hardware) or whether the software is standalone or embedded do not influence qualification.

Software without its own medical purpose, which controls or influences a medical device or its accessories, cannot qualify as MDSW; rather, it is subject to MDR and IVDR as part of or as an accessory to a medical device. In this case, the software does not independently generate information with a medical purpose.

Software can also feature characteristics that fall outside MDR or IVDR. For instance, information systems designed solely to transmit, store, convert, format, and archive data are not considered medical devices. When the software architecture allows modular construction, qualification and classification at the module level are permissible, provided the functionality of each module is independent.

This results in the following categories for software or software modules used in healthcare:

• MDSW
• Standalone application
• Embedded within medical device hardware
• Software controlling or influencing a medical device or its accessories
• Accessory: standalone application
• Part/component: embedded within medical device hardware
• Software not considered a medical device
• Standalone application
• Embedded within medical device hardware

Important to note: As should become clear from this categorization, MDSW under the MDR and IVDR does not cover the same scope as Software as Medical Device (SaMD) according to the IMDRF definition.

What Actions Are Required?

Qualification

The MDCG 2019-11 guidance, "Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR," facilitates a two-step approach to determining which regulation applies to a given software. The qualification criteria are specified

• with detailed explanations and definitions,
• and in the form of decision trees.

Additionally, the MDCG has created an infographic outlining the qualification decision steps for MDSW support.

Classification

Once software falls under a medical device regulation, it must be classified according to the MDR or IVDR classification rules. This classification determines the applicable conformity assessment procedure and the need for Notified Body involvement.

Classification is risk-based and focuses on potential impacts of the software on patient health. Although the risks associated with MDSW fundamentally align with those of other medical devices, certain software-specific risks, such as cybersecurity threats, must also be addressed.
Further support and explanations of MDR and IVDR classification rules are available in MDCG 2021-24, "Guidance on classification of medical devices," and MDCG 2020-16 Rev. 3, "Guidance on Classification Rules for in vitro Diagnostic Medical Devices under Regulation (EU) 2017/746."

In Europe, the intention is generally to assign software to higher risk classes, meaning that few MDSW will qualify for Class I or Class A:

• The MDR includes specific classification rule for software—Rule 11, which classifies “software intended to provide information used to make decisions for diagnostic or therapeutic purposes” as at least Class IIa. Here, consideration of the impact on patient health may result in classification as Class IIb or III.
• Under the IVDR, MDSW is classified independently, while software that controls or influences a medical device or its accessories assumes the same class as the medical device or accessory it influences.

Recommendations for Manufacturers

Despite the explanatory guidance made available by the MDCG, interpreting the legal requirements remains challenging due to potential ambiguities. Manufacturers of MDSW should therefore discuss classification early on with the Notified Body to avoid unnecessary time spent on preparing a conformity assessment that the Notified Body may not consider suitable.

Our experts are available to advise you on MDSW qualification and classification, but also on applicable standards for risk management, usability, lifecycle requirements, or safety. For questions, please reach out directly to the author or use our contact form.