Written and maintained by CASRAI Editorial Board
Last updated
MDCG 2019-11 (Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR, updated in June 2025 as MDCG 2019-11 Rev. 1) is the definitive European Union regulatory guidance governing when standalone or embedded clinical software qualifies as Medical Device Software (MDSW) and how it is classified under EU MDR Annex VIII Rule 11. Issued by the European Commission’s Medical Device Coordination Group (MDCG), MDCG 2019-11 works alongside MDCG 2020-1 (clinical evaluation of MDSW) and MDCG 2023-4 (software-hardware combinations), while sharing a direct IMDRF risk-categorization architecture with the UK MHRA and Australian TGA Software as a Medical Device (SaMD) frameworks.
What Does MDCG 2019-11 (and Rev. 1) Require for Medical Device Software (MDSW) Qualification and Classification?
MDCG 2019-11 establishes a 5-step decision tree that determines whether software qualifies as Medical Device Software (MDSW) by verifying that it performs an action on data beyond simple storage, archival, lossless compression, communication, or simple search for the medical benefit of individual patients under MDR Article 2(1) or IVDR Article 2(2).
Before applying classification rules, a digital health developer or academic clinical software team must determine whether a software module—or a specific module inside an Electronic Health Record (EHR) or Hospital Information System (HIS)—crosses the legal threshold into MDSW:
- Step 1 — Software Definition: Confirm the product is a set of instructions that processes input data and creates output data.
- Step 2 — Hardware / Annex XVI Check: Determine whether the software is an MDR Annex XVI product, an integral component/accessory driving a hardware medical device, or independent software.
- Step 3 — Action on Data Beyond Basic IT Functions: Software that solely stores, archives, performs lossless compression, communicates, or executes “simple search” (retrieving records by matching metadata without interpreting clinical significance) is not MDSW. Conversely, software that alters, scores, prioritizes, or computes diagnostic/therapeutic likelihoods performs a qualifying medical action.
- Step 4 — Individual Patient Benefit: Confirm the output is intended for the medical care of individual patients rather than solely population-level epidemiological aggregation, financial reimbursement, or hospital staff scheduling.
- Step 5 — Medical Purpose & MDR vs. IVDR Boundary: Confirm the Manufacturer’s Intended Purpose aligns with MDR Article 2(1) (diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease) or IVDR (EU) 2017/746 Article 2(2) (if the software processes data obtained substantially from in vitro diagnostic examinations to provide information within the IVDR scope).
What Changed in MDCG 2019-11 Rev. 1 (June 2025): Revision 1 expands the guidance to explicitly cover Medical Device Artificial Intelligence (MDAI), clarifies qualification boundaries for disease-prediction and risk-stratification algorithms, refines rules for modular EHR clinical decision support modules to align with the European Health Data Space (EHDS) Regulation (EU) 2025/327, and adds worked examples distinguishing general wellness/lifestyle trackers from regulated MDSW.
How Does EU MDR Annex VIII Rule 11 Classify Medical Device Software into Class I, IIa, IIb, and III?
Under EU MDR Annex VIII Rule 11, standalone software that provides information used to take decisions with diagnostic or therapeutic purposes, or that monitors physiological processes, is classified at a minimum as Class IIa (requiring Notified Body conformity assessment), escalating to Class IIb or Class III based on the severity of potential patient harm.
Under the legacy Medical Devices Directive (MDD 93/42/EEC), most standalone clinical software defaulted to self-certified Class I. Within the 22 EU MDR Annex VIII classification rules, Rule 11 eliminated that loophole by mapping software directly to the International Medical Device Regulators Forum (IMDRF/SaMD WG/N12FINAL:2014) risk matrix:
| EU MDR Rule 11 Sub-Rule & IMDRF Category | Intended Clinical Function & Impact of Decision | EU MDR Class | Conformity Assessment Impact |
|---|---|---|---|
| Rule 11a (First Indent) IMDRF Category IV (Critical × Treat/Diagnose) |
Software providing information used to take diagnostic or therapeutic decisions where an erroneous decision may cause death or an irreversible deterioration of a person’s state of health (e.g., automated malignant lesion diagnosis or acute stroke triage). | Class III | Notified Body QMS audit + rigorous Technical Documentation & Clinical Evaluation consultation |
| Rule 11a (Second Indent) & Rule 11b IMDRF Category III |
Diagnostic/therapeutic decision software whose impact may cause a serious deterioration of health or a surgical intervention; OR software monitoring vital physiological parameters where variations could result in immediate danger to the patient. | Class IIb | Notified Body QMS audit + Technical Documentation sampling/assessment per Annex IX |
| Rule 11a (Baseline) & Rule 11b (Baseline) IMDRF Category II & Category I (Inform) |
All other software intended to provide information used to take decisions with diagnosis or therapeutic purposes, or intended to monitor non-vital physiological processes. | Class IIa | Notified Body QMS audit + Technical Documentation assessment of representative devices |
| Rule 11c (Residual Clause) | All other Medical Device Software that neither provides diagnostic/therapeutic decision information nor monitors physiological processes (e.g., basic fertility conception support apps not diagnosing pathology). | Class I | Manufacturer self-declaration of conformity (unless sterile/measuring) |
Note that under Implementing Rule 3.3 of Annex VIII, software that drives a hardware device or influences the use of a device automatically falls into the same risk class as the driven hardware device; if the software also has an independent medical purpose, the higher of the two classes applies (Implementing Rule 3.5).
How Do MDCG 2020-1, MDCG 2023-4, and the UK MHRA and Australian TGA Frameworks Regulate Clinical Software?
While MDCG 2019-11 handles qualification and classification, MDCG 2020-1 governs clinical evidence generation for the Clinical Evaluation Report (CER), MDCG 2023-4 regulates MDSW paired with consumer wearables/smartphones, and the UK MHRA and Australian TGA enforce parallel IMDRF-aligned SaMD rules.
1. MDCG 2020-1: Clinical and Performance Evaluation of MDSW
When preparing a Clinical Evaluation Report (CER) under EU MDR (Article 61 and Annex XIV) or a Performance Evaluation Report under IVDR (Article 56), software developers follow MDCG 2020-1. Adopting the IMDRF N41 framework, MDCG 2020-1 requires three distinct pillars of evidence:
- Valid Clinical Association (Scientific Validity): Demonstrates through peer-reviewed literature, clinical guidelines, or clinical studies that the software’s algorithm output corresponds accurately to the target physiological state or clinical condition.
- Technical Performance (Analytical Validation): Demonstrates via verification testing (IEC 62304 / IEC 82304-1) that the software accurately, reliably, and reproducibly generates the expected output from input data (sensitivity, specificity, AUROC, latency, repeatability).
- Clinical Performance: Demonstrates that the software achieves its intended clinical benefit when used by target users (clinicians or patients) in the real-world clinical workflow.
2. MDCG 2023-4: Medical Device Software (MDSW) and Hardware Combinations
Published in October 2023, MDCG 2023-4 addresses apps that rely on optical sensors, accelerometers, cameras, or microphones built into smartphones or consumer smartwatches. It defines three regulatory pathways:
- Option 1: The hardware sensor/wearable is placed on the market separately as a CE-marked medical device or medical device accessory.
- Option 2: The MDSW manufacturer places both the software and the hardware on the market together as a single medical device system or Article 22 procedure pack.
- Option 3 (Consumer Hardware Platform): The MDSW runs on a consumer smartphone or smartwatch that has no medical purpose of its own. Here, the MDSW manufacturer assumes full regulatory responsibility under MDR Annex I General Safety and Performance Requirements (GSPRs) for verifying, validating, and continuously monitoring the reproducibility, calibration, and cybersecurity of every supported consumer hardware model and OS version.
3. International Cross-Walk: UK MHRA and Australian TGA SaMD Regulations
- UK MHRA (Software and AI as a Medical Device Change Programme): The Medicines and Healthcare products Regulatory Agency (MHRA) regulates SaMD and AI as a Medical Device (AIaMD) under the UK Medical Devices Regulations, aligning its classification transition with the four IMDRF risk categories and recognizing Predetermined Change Control Plans (PCCPs) (developed jointly with the US FDA and Health Canada) so adaptive ML models can update within pre-approved validation boundaries.
- Australian TGA (Software-Based Medical Devices): Under Schedule 2, Part 4, Clauses 4.5–4.8 of the Therapeutic Goods (Medical Devices) Regulations 2002 (reformed in February 2021), the Therapeutic Goods Administration (TGA) classifies SaMD using a structure nearly identical to EU MDR Rule 11—categorizing diagnostic, screening, therapeutic specification, and physiological monitoring software into Class I, IIa, IIb, or III, while carving out explicit exemptions for certain low-risk clinical decision support (CDS) tools where a health professional can independently review the basis of the recommendation.
