Software Classification Under the MDR and IVDR: What the European Commission’s Simplification Proposal Means in Practice

Why Software Classification Matters 

Software classification has become one of the most important regulatory questions for the companies that design, develop, or place digital health products on the EU market. Whether a product takes the form of a mobile application, algorithm, cloud platform or AI tool, it may qualify as a medical device (‘MD’) or an in vitro diagnostic medical device (‘IVD’) if it is intended for a specific medical purpose within the meaning of the Medical Device Regulation (‘MDR’) or the In Vitro Diagnostic Medical Device Regulation (‘IVDR’). Qualification, however, is only the starting point. Once a product has been qualified as an MD or IVD, it must be classified according to its intended purpose and the level of risk associated with its use. Qualification determines whether a product falls within the scope of the regulatory framework and classification determines the risk class to which the device belongs. The medical device classification determines whether the manufacturer may self-declare conformity or must involve a notified body before placing the product on the EU market. That classification outcome has both legal and commercial implications. It dictates the applicable conformity assessment procedure, the extent of technical documentation required, the level of clinical or performance evidence expected, and the scope of post-market surveillance obligations. As a result, it directly influences development timelines, compliance costs, and market access strategy. For software developers, healthcare companies, regulatory teams and investors, it is therefore one of the first strategic questions to answer, not a technical footnote. 

Under both the MDR and the IVDR, inconsistencies in qualification and classification decisions across EU Member States have contributed to legal uncertainty and created obstacles to market access. The regulations also introduced class-based requirements that have placed significant strain on manufacturers, particularly smaller ones. Compounding this challenge are the classification thresholds introduced under both regulations. This impact has been particularly pronounced in the field of medical device software. The classification rules established under the MDR and IVDR mean that the vast majority of software-based devices are now assigned to at least Class IIa, thereby requiring the involvement of a notified body in the conformity assessment process. While this requirement reflects a legitimate policy objective - ensuring the safety and performance of higher-risk devices - its practical burden falls disproportionately on smaller manufacturers who may lack the resources to navigate a protracted and costly conformity process. 

The importance of classification is further amplified where medical device software is AI-based. Under the EU AI Act, the application of high risk AI system regulatory requirements is closely linked to the device's classification under the MDR or IVDR, particularly for devices subject to notified body involvement. Consequently, classification may have implications that extend beyond MDR and IVDR, shaping a manufacturer's obligations under the EU's broader digital regulatory framework. 

The European Commission’s legislative proposal for a regulation to simplify rules on medical and in vitro diagnostic devices published on 16 December 2025 (‘the MDR/IVDR Simplification Proposal’) seeks to amend the existing rules, addressing some of these difficulties and promoting consistent, risk-based decisions across the internal market. Among its proposed reforms, the amendment to Rule 11 of Annex VIII MDR, the primary classification rule for medical device software (‘MDSW’), is arguably the most significant for digital health, software and AI developers. If adopted, the revised rule could substantially alter the classification landscape for medical device software, enabling a broader range of products to qualify as Class I devices and, consequently, eliminating the need for notified body involvement in the conformity assessment process. 

This article examines the current regulatory framework for medical device software classification under the MDR and IVDR, how the Medical Device Coordination Group (‘MDCG’) guidance approaches software qualification and classification, why Rule 11 has proved difficult in practice, what the Commission proposes to change, and what software developers, digital health companies and manufacturers should consider now. 

What Constitutes Medical Device Software? 

Medical device software is software (a set of instructions that processes input data and creates output data) that is intended to be used, alone or in combination, for a purpose as specified in the definition of a ‘medical device’ in the MDR or ‘in vitro diagnostic medical device’ in the IVDR. Whether software qualifies as MDSW depends primarily on its intended purpose. 

In practical terms, software may qualify as MDSW in its own right where it is specifically intended by the manufacturer to be used for one or more of the medical purposes set out in the definition of a medical device. By contrast, software developed for general purposes, even when deployed in a healthcare setting, and software intended for lifestyle or well-being purposes, will generally fall outside the MDR and IVDR. MDSW may be intended for use by either healthcare professionals (for example doctors) or lay users, such as patients or other non-professional individuals.

 Classification of Software under the MDR and IVDR 

Once software qualifies as a medical device or an in vitro diagnostic it must be assigned to the appropriate risk class. Classification is a critical regulatory step, as it determines the conformity assessment route and, in particular, whether a notified body must be involved before the product can be placed on the EU market. 

Under the MDR, medical devices are divided into four risk classes: Class I, IIa, IIb and III. Classification is based on the device’s intended purpose and inherent risks. As a general rule, the greater the potential impact on patient health and the associated risk, the higher the classification. The detailed classification rules are set out in Annex VIII MDR.

For software, two general principles apply. First, software that controls, drives or influences another medical device generally takes the same classification as that device. However, where software functions independently, it must be classified on its own merits (Rule 3.3). Second, where more than one classification rule could apply, the rule resulting in the highest risk class prevails (Rule 3.5). 

In addition to these general principles, Annex VIII contains a dedicated classification rule for medical device software: Rule 11. In essence, depending on the intended purpose of the MDSW, the existing Rule 11 categorises MDSW as follows: 

• Software intended to provide information which is used to take decisions with diagnostic or therapeutic purposes is classified as Class IIa; 
  - Where such decisions may cause serious deterioration of a person’s state of health or a surgical intervention, the software is classified as Class IIb; 
  - Where such decisions may cause death or irreversible deterioration of a person’s state of health, the software is classified as Class III; 
• Software intended to monitor physiological processes is classified as Class IIa; 
  - Where it is intended for monitoring of vital physiological parameters, where the nature of of variations of those parameters is such that it could result in immediate danger to the patient, the software is classified as Class IIb; 
• All other software is classified as Class I. 

One of the most persistent criticisms of Rule 11 is that it conflates severity with probability - assigning risk based on what could go wrong, rather than what is likely to go wrong. It also lacks the nuance to differentiate software with direct clinical significance from software that merely informs decisions at the margins. 

Software may also fall within the IVDR. This is particularly relevant where software is intended to be used in vitro for the examination of specimens derived from the human body, such as blood, tissue, cells or genetic material, and is intended to provide medical information. IVDs are classified under the IVDR as Class A, B, C or D, taking into account their intended purpose and inherent risks. As under the MDR, the greater the potential impact on patient health or public health, the higher the classification. Rule 11 does not apply to IVD software, which is classified under the separate rules in Annex VIII IVDR. 

How MDCG Guidance Applies the Rules 

The MDR and IVDR establish the legally binding framework for medical devices and in vitro diagnostic medical devices. In practice, however, manufacturers must also consider how these requirements are interpreted and applied through guidance issued by the MDCG. For software, the key guidance document is MDCG 2019-11 Rev.1, which addresses the qualification and classification of software under both the MDR and IVDR. This guidance should be read alongside MDCG 2021-24 Rev.1, which provides general principles for the classification of medical devices under the MDR. Although MDCG guidance is not legally binding, it serves as an important reference for manufacturers, notified bodies, and competent authorities when interpreting and applying the regulatory framework. 

MDCG 2019-11 Rev.1 provides a five-step decision chart to determine whether software qualifies as MDSW. In simplified form, the manufacturer should consider: 

1. If the product is software according to Section 2 of the MDCG guidance understood as a set of instructions that processes input data and creates output data; 
   • if YES proceed to question 2 
   • If NO it is not a MDSW 
2. If the product is an MDR Annex XVI device or accessory for a medical device or driving or influencing the use of a medical device; 
   • if YES, it is covered by MDR/IVDR
   • if NO proceed to question 3 
3. If the software performs an action on data beyond storage, archival, communication, simple search; 
   • if NO it is not covered by MDR/IVDR 
   • if YES proceed to question 4 
4. Is the action for the benefit of individual patients; 
   • if NO it is not covered by MDR/IVDR 
   • if YES proceed to question 5 
5. Is the software MDSW according to the definition in the MDCG Guidance meaning that if it is intended to be used, alone or in combination, for a purpose as specified in the definition of a “medical device” or ‘in vitro diagnostic medical device’ in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device. 
   • if NO it is not covered by MDR/IVDR 
   • if YES, the software qualifies as MDSW and falls within the scope of the MDR or IVDR 

This decision chart is useful because it prevents manufacturers from jumping too quickly to Rule 11. A product should first be assessed to determine whether it falls within the MDR or IVDR at all. Only then should the classification rules be applied. 

MDCG guidance also provides helpful examples of how Rule 11 may apply to different types of MDSW under the MDR. These examples are not exhaustive and do not replace a product-specific classification analysis, but they are useful reference points.

The practical message from the MDCG guidance is that software classification remains fact-specific. The same type of technology may be classified differently depending on the intended purpose, the data processed, the output generated, the intended user, the clinical context and the foreseeable consequences of incorrect or delayed output. 

The MDR/IVDR Simplification Proposal: A New Approach to MDSW Classification 

The MDR/IVDR Simplification Proposal addresses MDSW classification most directly through a targeted amendment to Rule 11 of Annex VIII MDR. Software falling under the IVDR would continue to be classified separately under Annex VIII IVDR; the proposal does not introduce an equivalent software-specific rule for IVDs. The IVDR is therefore addressed below in the context of the proposal’s broader mechanisms on expert panel opinions, reclassification and future adaptation of classification rules. 

A key objective of the proposed revision to Rule 11 is to better align MDSW classification with the actual risk associated with the software output and its clinical context. 

The proposal appears to move away from the broad current approach, under which many types of MDSW are automatically captured at Class IIa or higher, and toward a more differentiated risk-based structure. The proposed revised Rule 11 provides that software intended to generate an output that confers a clinical benefit and is used for diagnosis, treatment, prevention, monitoring, prediction, prognosis, compensation or alleviation of a disease or condition is classified as Class I, unless the output is intended for a disease or condition: 

• in a critical situation with a risk of causing death or an irreversible deterioration of a person’s state of health, in which case it is classified as Class III; 

• in a serious situation with a risk of causing a serious deterioration of a person’s state of health or a surgical intervention, or to drive clinical management in a critical situation, in which cases it is classified as Class IIb; 

• in a non-serious situation, or to drive clinical management in a serious situation or to inform clinical management in a critical or serious situation, in which cases it is classified as Class IIa. 

Unlike the current framework, where Class IIa serves as the default classification, the proposed rule designates Class I as the default category, meaning that a greater proportion of MDSW is likely to be classified as Class I. The proposed structure draws on the International Medical Device Regulators Forum (‘IMDRF’) risk-categorisation concepts reflected in MDCG 2019-11 Rev.1, though it does not adopt that matrix directly. 

However, the proposal should not be read as a general down-classification of MDSW. The starting point remains the intended purpose of the software. The manufacturer should be able to explain what the software does, what input data it uses, what output data it generates, who uses the output, how the output affects clinical decisions, and what harm could arise from incorrect or delayed output. Manufacturers should also be cautious because some aspects of the proposed wording remain unclear. 

In particular, the reference to software output intended for a disease or condition “in a non-serious situation” being Class IIa appears difficult to reconcile with the proposed Class I baseline. The terms “clinical management”, “critical situation”, “serious situation” and “non-serious situation” are undefined in the proposal and will need further clarification. Updated MDCG guidance is likely to be needed if the proposal is adopted. The proposal is also only at the start of the ordinary legislative procedure: it has not been adopted, the final text may differ, and no adoption is anticipated before late 2026 or 2027. 

The proposal also includes procedural mechanisms that may affect software qualification and classification practice more broadly, under both the MDR and the IVDR. Under the proposed new Article 4a MDR, a competent authority, notified body, manufacturer, developer or the Commission could request an expert panel opinion on whether a specific product, category or group of products falls within the definition of a medical device or an accessory. Where the requester considers that the product is a device, the request would also need to specify the proposed classification under Article 51 MDR and Annex VIII MDR. For IVDs, a corresponding mechanism is proposed under the new Article 3a IVDR. 

The proposal would also amend the reclassification mechanisms in Article 51 MDR and Article 47 IVDR. In broad terms, this would allow the reclassification of a device, IVD, accessory, category or group of products by way of derogation from Annex VIII, taking into account proportionality and classification at the international level, and where justified for reasons of public health on the basis of new scientific evidence or information arising from vigilance or market surveillance activities. 

Finally, the proposal would empower the Commission to adapt the classification rules in Annex VIII MDR and Annex VIII IVDR by delegated acts, in the light of technical or scientific progress and developments in classification at international level. For software and AI-enabled tools, this could make the framework more adaptable over time. It also means that manufacturers and developers will need to monitor not only the final text of the amending regulation, but also any future delegated acts and updated MDCG guidance. 

What Companies Should Do Now 

The proposal has not yet been adopted into law. Manufacturers should therefore not change their conformity assessment route, product classification or market access strategy on the assumption that the text of the MDR/IVDR Simplification Proposal will be adopted as proposed. The current MDR and IVDR rules continue to apply. 

That said, the MDR/IVDR Simplification Proposal is a clear signal of where the regulatory debate is heading. Software classification is likely to become more closely tied to the clinical context of the software output, the seriousness of the patient situation and the way the output is used in clinical management. This matters not only for manufacturers, but also for software developers, digital health companies, AI developers, healthcare providers integrating third-party tools, IVD and laboratory software businesses, regulatory teams and investors assessing EU market access risk.

The practical message is simple: the proposal may create opportunities for some lower-risk medical device software, but it is not a shortcut to Class I. Companies should use this period to prepare a defensible qualification and classification analysis, define the intended purpose precisely, map the software’s input and output, identify the clinical context and user, assess foreseeable harm, distinguish MDR from IVDR requirements, and keep technical documentation flexible enough to reflect the final adopted text. The classification question is not disappearing. It is becoming more risk-based, more product-specific and, for well-prepared companies, potentially more proportionate. 

Funding acknowledgement and disclaimer 

The authors are involved in EU-funded projects relevant to digital health, health data and AI-enabled healthcare technologies.

 • Nayana Murali participates in the PATH project. PATH is supported by the Innovative Health Initiative Joint Undertaking (IHI JU) under Grant Agreement No. 101253520. The IHI JU receives support from the European Union’s Horizon Europe research and innovation programme and COCIR, EFPIA, EuropaBio, MedTech Europe and Vaccines Europe. 

• Marta Wilinska participates in the AI4LUNGS project. AI4LUNGS is funded by the European Union under the Horizon Europe Programme, Grant Agreement No. 101080756. The Health and Digital Executive Agency (HaDEA) is the granting authority. 

• Vaisakh Shaji participates in VOLABIOS project. VOLABIOS is funded by the European Union under the Horizon Europe Programme, Grant Agreement No. 101156162. The Health and Digital Executive Agency (HaDEA) is the granting authority. 

Views and opinions expressed in this article are those of the authors only and do not necessarily reflect those of the European Union, the Innovative Health Initiative Joint Undertaking (IHI JU), the Health and Digital Executive Agency (HaDEA), or any other relevant granting authority. Neither the European Union, IHI JU, HaDEA nor any other relevant granting authority can be held responsible for them.