Software as a Medical Device under the MDR and IVDR: Qualification, Rule 11 and What Applies

Monitoring software sits in class IIa or IIb under the same rule, and all other device software in class I.

The rules concern every manufacturer whose software diagnoses, monitors, predicts or treats, whether the software runs on its own, drives a hardware device or reaches users as an app. The MDR (Regulation (EU) 2017/745) has applied since 26 May 2021 and the IVDR (Regulation (EU) 2017/746) since 26 May 2022, and every software rule on this page has its basis in one of the two.

This page sets out how MDCG 2019-11 rev.1 tests whether software is MDSW, how the three sub-rules of Rule 11 and the other MDR rules assign a class, and how the seven IVDR rules treat IVD software. It then covers the evidence, identification and life-cycle duties, legacy software up-classified by Rule 11, the pending rewrite of Rule 11 and the current versions of the software guidance.

What Medical Device Software (MDSW) Means

Medical device software (MDSW) is software intended to be used, alone or in combination, for a purpose specified in the definition of a medical device in the MDR or of an in vitro diagnostic medical device in the IVDR (MDCG 2019-11 rev.1, Section 2). Both legal definitions name software expressly. MDR Article 2(1) lists software among the instruments, apparatus, appliances and other articles that the manufacturer intends for specific medical purposes, and IVDR Article 2(2) includes software in the definition of an in vitro diagnostic medical device. The medical purposes of MDR Article 2(1) include diagnosis, prevention, monitoring, prediction, prognosis and treatment of disease. Software can therefore be considered a medical device in its own right, and the purpose its manufacturer assigns to it is what makes it one.

The software rules of the EU MDR and IVDR sit in two separate acts with one shared logic. Both regulations entered into force on 25 May 2017 (MDR Article 123(1), IVDR Article 113(1)), and both are directly applicable in every member state, so qualification and classification of software follow the same EU text everywhere, without national transposition. The two acts are explained together under EU MDR and IVDR.

Software as a Medical Device, MDSW and Software That Drives Hardware

MDCG 2019-11 rev.1 uses the term MDSW and no longer uses "standalone software"; "software as a medical device" and SaMD are the common terms for the same idea. This page uses MDSW, the term of the EU guidance, for software that meets one of the two definitions, whatever name the market gives it.

MDSW appears in two forms. It can be independent of any other device, or it can drive or influence the use of a hardware device. The difference matters for classification: MDR Annex VIII implementing rule 3.3 classifies independent software in its own right and gives software that drives or influences a device the class of that device, as the classification section below explains.

Software Deemed an Active Device

MDR Article 2(4) deems software an active device, so the rules for active devices in Annex VIII (Rules 9 to 13) can apply alongside Rule 11. The 22 classification rules of MDR Annex VIII Chapter III fall into four groups: non-invasive Rules 1 to 4, invasive Rules 5 to 8, active Rules 9 to 13 and special Rules 14 to 22. Rule 11 itself is one of the active-device rules of the EU MDR. The term active device and the definitions of medical device, accessory and manufacturer sit in Article 2 of the EU MDR (Regulation (EU) 2017/745).

Duties That Apply to MDSW at a Glance

MDSW is a device like any other under both regulations: it meets the general safety and performance requirements of Annex I, goes through the conformity assessment route of its class, carries technical documentation, clinical or performance evidence, a UDI and post-market surveillance. Each duty applies under the regulation that covers the software: the MDR for software that is a medical device, the IVDR for IVD software. The class decides the conformity assessment route, which is why qualification and classification come first on this page. The table lists eight duties with their basis in each regulation; the last row leads to the dedicated page on device cybersecurity.

When Software Qualifies as MDSW: The Steps of MDCG 2019-11 rev.1

Whether software is MDSW depends on its intended purpose as stated by the manufacturer, and MDCG 2019-11 rev.1 (June 2025, original October 2019) explains how to test it step by step; the guidance is not legally binding, and notified bodies take it into consideration. The Medical Device Coordination Group (MDCG) set up under MDR Articles 103 and 105 and IVDR Articles 98 and 99 issues it under the Commission's guidance topic "New technologies", and Annex VII Section 1.6.2 of both regulations requires notified bodies to take such guidance into consideration. As of 6 November 2026, the Commission's guidance list shows no later revision.

Revision 1 rewrote the scope and added text on intended purpose and modular MDSW, on software covered by Annex XVI, on modules and on electronic health records and the EHDS. It also clarified Rule 11a with regard to the prevention of illness and added new examples, among them MDSW intended to treat and a new class I example. Every qualification starts with the general question of what is a medical device under MDR Article 2(1) or IVDR Article 2(2), and that general test is set out under what is a medical device.

Functions That Do Not Make Software MDSW

Software whose action on data is limited to storage, archival, communication, simple search or lossless compression is not MDSW (MDCG 2019-11 rev.1, Section 3.3). The exclusion is decision step 3 of the guidance, which the Commission publishes as MDCG 2019-11 rev.1. Software that performs more than these five actions on data still needs a medical purpose of MDR Article 2(1) or IVDR Article 2(2) to be MDSW.

Section 3.1 of the same guidance gives examples of software that is not MDSW. The examples are software for invoicing and staff planning, e-mailing and messaging, data parsing, word processing and back-up, and wellness or fitness apps.

Device Software or IVD Software: The Data-Source Test

MDSW is IVD software when its intended purpose is substantially driven by data from in vitro diagnostic devices, a qualitative weighting that MDCG 2019-11 rev.1 sets out in Section 3.4. The test matters for software that combines data from in vitro diagnostic devices with data from other sources, because it decides which of the two regulations applies. Where the IVD data drive the purpose, IVD software then falls under the IVDR (Regulation (EU) 2017/746).

The consequence is a different set of classification rules. IVD software is classified under IVDR Annex VIII, and MDR Rule 11 does not apply to it (MDCG 2019-11 rev.1, Section 4.2 note and Section 5.1).

Software Sold with Hardware or through App Platforms

MDCG 2023-4 (October 2023) describes three ways to place MDSW together with hardware: the hardware as an accessory, the hardware as a device (system, combination or integral part), or the hardware as a consumer product, in which case the MDSW manufacturer is responsible for the combination. The three options are set out in Section 4 of MDCG 2023-4 on MDSW and hardware combinations, issued by the MDCG under the topic "New technologies".

App distribution has its own document. MDCG 2025-4 (June 2025), also under "New technologies", covers the safe making available of MDSW apps on online platforms.

Rule 11: How the MDR Classifies Software

MDR Annex VIII Section 6.3 sets out Rule 11, which classifies software intended to provide information for diagnostic or therapeutic decisions in class IIa, IIb or III, monitoring software in class IIa or IIb, and all other software in class I; it has applied since 26 May 2021. Rule 11 is one of the 22 rules of MDR Annex VIII Chapter III, which assign the classes I, IIa, IIb and III of MDR Article 51, in the text of the consolidated MDR on EUR-Lex. The table shows the three sub-rules with their classes.

MDCG 2021-24 rev.1 (April 2026), the MDCG guidance on classification of medical devices, explains how the rules of Annex VIII are applied, while MDCG 2019-11 rev.1 explains Rule 11 in detail. The other rules are set out under MDR classification and the 22 rules of Annex VIII.

Software That Informs Diagnostic or Therapeutic Decisions

Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is in class IIa, unless the decisions may cause death or an irreversible deterioration of health (class III) or a serious deterioration of health or a surgical intervention (class IIb). The first paragraph of Rule 11 therefore sets one default class and two severity triggers. The trigger is the impact of the decisions that the information supports: the worse the possible outcome of those decisions, the higher the class.

MDCG 2019-11 rev.1 calls this first paragraph Rule 11a, and revision 1 clarified Rule 11a with regard to the prevention of illness. Class IIa is the lowest class Rule 11a gives, so decision-support software is never class I under the current text. "Class I by default" describes only the pending rewrite set out further down this page. The intended purpose stated by the manufacturer decides whether software informs decisions at all, which places it under Rule 11a, or monitors physiological processes or does something else, which places it under Rule 11b or Rule 11c.

Monitoring Software and All Other Software

Software intended to monitor physiological processes is in class IIa, and in class IIb where it monitors vital physiological parameters whose variations could result in immediate danger to the patient (Rule 11b). MDCG 2019-11 rev.1, Section 4.2.1, names six vital physiological parameters as examples: respiration, heart rate, cerebral functions, blood gases, blood pressure and body temperature.

All other software is in class I under the third paragraph of Rule 11, which MDCG 2019-11 rev.1 calls Rule 11c. Class I under Rule 11c is a residual class: within Rule 11, software reaches it only when it neither provides information for diagnostic or therapeutic decisions nor monitors physiological processes. The class of a single product can be narrowed down with a class finder, and an indicative class with the Annex VIII rule behind it comes from the medical device class finder.

The IMDRF Table and the MDCG Examples

MDCG 2019-11 rev.1 Annex III maps Rule 11a onto the IMDRF grid of situation and significance: critical situations with treat or diagnose give class III, critical with drive and serious with treat or diagnose give class IIb, and every other cell gives class IIa. The grid is illustrative, covers Rule 11a only and does not apply to IVD software. The examples of Annex IV of the guidance are listed below with the sub-rule and the class the guidance gives.

Classes as given in MDCG 2019-11 rev.1 (June 2025), Annex IV.

These examples of software as a medical device cover every class of Rule 11. The guidance classifies software that analyses acute stroke images for treatment decisions in class III, a heartbeat app that informs a physician to guide diagnosis and depression-scoring software in class IIb, and continuous vital-sign surveillance in anaesthesia, intensive or emergency care in class IIb under Rule 11b. It classifies software that ranks chemotherapy options for BRCA-positive patients in class IIa, and a fertility status app and a communication-aid app in class I under Rule 11c.

Implementing Rule 3.3, Rule 15 and Rule 22

Under MDR Annex VIII implementing rule 3.3, software that drives or influences the use of a device falls within the same class as the device, and software independent of any other device is classified in its own right. MDSW that has its own medical purpose and also drives a hardware device is classified on its own purpose, and its class is not lower than the class of the hardware (MDCG 2019-11 rev.1, Section 4.1).

Two special rules catch software directly as well. MDCG 2019-11 rev.1 places software for contraception in class IIb under Rule 15 (Section 4.2.4) and closed-loop systems in class III under Rule 22 (Section 4.2.5). Rule 11 is therefore not the only rule for software: implementing rule 3.3, Rules 15 and 22 and the active-device rules apply next to it.

Software under the IVDR Rules

IVD software is classified under the seven rules of IVDR Annex VIII into classes A, B, C and D, never under MDR Rule 11, and IVDR Annex VIII implementing rule 1.4 repeats the MDR principle: software driving an IVD instrument takes the class of the instrument, independent software is classified in its own right. The four classes come from IVDR Article 47, in the consolidated IVDR on EUR-Lex, and the IMDRF grid of MDCG 2019-11 rev.1 Annex III does not apply to IVD software. The class therefore follows from the IVDR rule that matches the intended purpose of the software. The table lists IVD software examples with the rule and class the MDCG guidance gives.

The score example comes from a second document. MDCG 2020-16 rev.5 (September 2026), the MDCG guidance on classification rules for in vitro diagnostic medical devices, places eGFR/ACR, ELF and MELD score software under Rule 3(g), class C. MDCG 2019-11 rev.1, Section 5.2, gives the other three examples, from class D under Rule 1 to class C under Rules 3(k) and 3(l). All seven rules of IVDR classification are explained under IVDR classification and classes A, B, C and D.

Evidence, Identification and Life-Cycle Duties for MDSW

Three duties take a software-specific form: the clinical or performance evidence, the unique device identification of each release, and the software life-cycle requirement of Annex I. MDR Annex I Section 17.2 and IVDR Annex I Section 16.2 require software to be developed and manufactured in accordance with the state of the art, taking into account the principles of the development life cycle, risk management including information security, and verification and validation.

Clinical and Performance Evidence for MDSW

MDCG 2020-1 (March 2020) explains clinical evaluation under the MDR and performance evaluation under the IVDR for MDSW on three pillars: valid clinical association or scientific validity, technical or analytical performance, and clinical performance. The evidence on the three pillars feeds the clinical evaluation of MDR Article 61 for software that is a medical device and the performance evaluation of IVDR Article 56 for IVD software. As of 6 November 2026, the Commission's guidance list shows no revision of MDCG 2020-1.

Software releases bring a point of their own. MDCG 2020-1, Section 4.4, explains that validation of clinical performance should be considered at each change to a new release. Where the manufacturer does not repeat the validation for a release, the reason is justified in the technical documentation.

When a Software Release Needs a New Device Identifier

Under MDR Annex VI Part C Section 6.5.2, a new UDI-DI is needed whenever a change modifies the original performance, safety, intended use or interpretation of data, such as new or modified algorithms, database structures, operating platform, architecture, user interfaces or interoperability channels. The identifiers themselves, UDI-DI and UDI-PI, are explained under UDI under the MDR and IVDR.

Minor software revisions need a new UDI-PI only, not a new UDI-DI: MDR Annex VI Part C Section 6.5.3 names bug fixes, usability enhancements that are not for safety purposes, security patches and operating efficiency. Section 6.5.4 places the UDI on the "about" file or the start-up screen in plain text, makes it available through an application programming interface for software without a user interface, and does not require the machine-readable form on the screen. MDCG 2018-5 (October 2018), issued under the Commission's UDI topic, explains UDI assignment to MDSW.

The Software Life-Cycle Standard and Its Status

IEC 62304 is the international standard on software life-cycle processes, and as of 6 November 2026 it is not cited in the Official Journal under the MDR (Implementing Decision (EU) 2021/1182, amended 10 times, latest by 2026/1231) or the IVDR (Implementing Decision (EU) 2021/1195, amended eight times, latest by 2026/1313). The two decisions and their amendments are listed on the Commission's harmonised standards page.

A standard gives a presumption of conformity under MDR and IVDR Article 8 only when its reference is published in the Official Journal, so IEC 62304 gives no presumption of conformity under either regulation. Scope and status of the standard are covered on IEC 62304 under the EU MDR and IVDR.

Legacy Software Up-Classified by Rule 11

Software that was self-declared under Directive 93/42/EEC, with an EU declaration of conformity drawn up before 26 May 2021, and now needs a notified body because of Rule 11 may be placed on the market or put into service until 31 December 2028 under MDR Article 120(3b), as amended by Regulation (EU) 2023/607, but only if the Article 120(3c) conditions are met. Regulation (EU) 2023/607 (OJ L 80, 20.3.2023, p. 24) entered into force on 20 March 2023.

The Article 120(3c) conditions include two deadlines. The manufacturer had to put in place a quality management system and lodge a formal application with a notified body by 26 May 2024, and to sign a written agreement with the notified body by 26 September 2024 (MDR Article 120(3c)(d) and (e)). Both dates have passed, so software that missed either of them cannot use the Article 120(3b) period.

Legacy IVD software follows IVDR Article 110 as amended by Regulation (EU) 2024/1860, with end dates by class: 31 December 2027 for devices with an IVDD certificate and for self-declared devices now in class D, 31 December 2028 for self-declared devices now in class C, and 31 December 2029 for self-declared devices now in class B and sterile class A (IVDR Article 110(3a) and (3b)). The quality management system deadline of 26 May 2025 applies to all legacy IVDs (IVDR Article 110(3c)(d)), and the other conditions are set out under IVDR transition periods for legacy IVDs.

The Pending Rule 11 Rewrite

As of 6 November 2026, Rule 11 is unchanged law: the Commission's proposal COM(2025) 1023 of 16 December 2025 (procedure 2025/0404(COD)) would replace MDR Annex VIII Section 6.3, but it is pending, at the stage "Awaiting committee decision" in the European Parliament's SANT committee, and is not law. The past procedural events recorded in the Legislative Observatory file 2025/0404(COD) include the SANT draft report of 30 June 2026.

The proposal would make class I the default for software whose output confers a clinical benefit. It would place software in class III for a critical situation with a risk of death or irreversible deterioration, and in class IIb for a serious situation or where the software drives clinical management in a critical situation. Class IIa would cover a non-serious situation, software that drives management in a serious situation and software that informs in a critical or serious situation. The full wording is in the proposal COM(2025) 1023 on EUR-Lex.

The proposal would also let a notified body and a manufacturer agree a predetermined change control plan, added to Annex VII Section 4.9 of both regulations, so that the planned changes could be made without prior information to the notified body. None of these amendments applies unless an amending regulation is adopted and published, and every amending act and the proposal are listed under MDR and IVDR amendments.

Software Guidance and Current Versions

The core MDCG documents on software, MDCG 2019-11 rev.1, MDCG 2020-1, MDCG 2023-4 and MDCG 2025-4, sit under the Commission's guidance topic "New technologies", and the table names each software-related document with its current version as of 6 November 2026. MDCG 2018-5 sits under the UDI topic of the Commission's MDCG guidance list, and the infographic "Is your software a Medical Device?" is a Commission page without an MDCG number.

What This Page Does Not Decide

This page explains how the MDR and the IVDR treat software; it does not decide whether a named product is MDSW or which class it has. AI-based medical device software is also subject to the EU rules on artificial intelligence; the MDCG has published an FAQ on how the two fit together (MDCG 2025-6, June 2025). The general EU cybersecurity rules for products with digital elements are a separate topic and are not covered on this page.

Who Decides Whether a Product Is MDSW

The manufacturer qualifies and classifies its software on the basis of its intended purpose, and the notified body checks the class where one is involved. MDCG 2019-11 rev.1 explains the method that both apply.

How the US Approach Differs

The United States regulates software under its own federal framework, which this page does not describe. Readers who compare the EU MDR with the US approach find the main differences in EU MDR vs FDA.