---
title: MDCG 2019-11: Guidance on Qualification and Classification of Software — Key Takeaways
description: MDCG 2019-11 Rev.1 is the definitive EU guidance on when software is a medical device and how to classify it. Here are the key takeaways for startups.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: MDCG 2019-11 software guidance
canonical_url: https://zechmeister-solutions.com/en/blog/mdcg-2019-11-software-guidance
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# MDCG 2019-11: Guidance on Qualification and Classification of Software — Key Takeaways

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **MDCG 2019-11. Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745. MDR and Regulation (EU) 2017/746. IVDR. Is the European Commission's Medical Device Coordination Group document that tells manufacturers, Notified Bodies, and Competent Authorities how to decide two questions about a piece of software: is it a medical device under MDR Article 2(1), and if yes, what class does it fall into under Annex VIII Rule 11. Revision 1, published in June 2025, is the current version. For medical software startups in the EU, this document. Read alongside the MDR text itself. Is the single most important regulatory reference you will use.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- MDCG 2019-11 Rev.1 (June 2025) is the current version. Anything older is superseded. Check the date before you rely on a copy you downloaded last year.
- The document's job is to operationalise two MDR provisions for software: Article 2(1) (the definition of a medical device) and Annex VIII Rule 11 (the software classification rule).
- The qualification decision tree walks software through four tests: is it software, does it act on data beyond storage and transmission, is the action for the benefit of individual patients, and does its intended purpose fall within Article 2(1).
- The classification walkthrough applies Rule 11 and shows how most medical software lands at Class IIa or higher. Class I is the exception.
- MDCG 2019-11 Rev.1 contains worked classification examples across imaging, cardiology, dermatology, oncology, diabetes, and other domains. These examples are how you calibrate borderline cases.
- The guidance addresses modules and changes. How to handle mixed-purpose software and how to handle software that evolves after it has been placed on the market.
- Startups should use the document as a working tool: read it in full, apply its flowchart to your product in writing, and cross-check against the examples before you commit engineering resources.

---

## Why this guidance exists

The MDR tells you that software can be a medical device and gives you Rule 11 to classify it. What the MDR does not give you is a repeatable procedure for walking a specific product through those provisions. That gap is what MDCG 2019-11 fills. The Medical Device Coordination Group. The expert body that advises the European Commission and coordinates Competent Authorities across Member States. Publishes guidance documents that represent a common reading of the regulation. MDCG guidance is not legally binding in the way the MDR text is, but in practice it is how Notified Bodies and Competent Authorities reason, and a file that contradicts MDCG guidance without a strong argument will not pass conformity assessment.

The first version of MDCG 2019-11 was published in October 2019. Revision 1 was published in June 2025 and reflects six years of accumulated experience from Notified Bodies, Competent Authorities, and the Commission itself. If the copy you are reading predates June 2025, stop reading it and download the current one. Software guidance is a moving target, and startups that build on outdated guidance end up rewriting technical files.

## What MDCG 2019-11 Rev.1 is. And what it is not

MDCG 2019-11 Rev.1 is a qualification and classification guidance. It answers two questions: is this software a medical device, and if yes, what is its class. It is not a software lifecycle guidance. That work lives in MDR Annex I Section 17 and, for presumption of conformity, in EN 62304:2006+A1:2015. It is not a clinical evaluation guidance for software. That work lives in MDCG 2020-1 and related documents. It is not a cybersecurity guidance. That work lives in MDCG 2019-16. It is not an AI/ML guidance. That work is still developing, and the MDR's treatment of AI software flows through the regular Rule 11 classification rather than through a software-specific AI path.

Understanding the scope of the document matters because founders sometimes reach for MDCG 2019-11 to answer questions it was never written to answer. It tells you what you are and what class you are in. It does not tell you how to build the software, how to evaluate it clinically, or how to secure it. Those are different documents, and the sequence matters. Qualification and classification come first, and everything else follows from them.

## The qualification decision tree. Is it software, and is it a device?

The heart of the document is the qualification flowchart. It walks a product through a series of yes/no questions, and the outcome is either "this is MDSW under the MDR" or "this is not MDSW under the MDR." The structure of the tree, in the order MDCG 2019-11 Rev.1 applies it, is this.

**Is it software at all?** The answer is almost always yes, but the definition is broad. Software includes mobile applications, cloud services, modules within larger systems, algorithms embedded in hardware, scripts, and any set of instructions that processes data. If your product executes code, it is software for the purpose of this question.

**Does it perform an action on data that goes beyond storage, archival, lossless compression, communication, or simple search?** This is the filter that separates MDSW from pure IT infrastructure. A database that stores clinical records is not MDSW. A messaging system that transmits images is not MDSW. A search engine that retrieves records is not MDSW. The moment the software does something to the data. Calculates a score, flags an abnormality, interprets a pattern, recommends a next step. The filter is crossed and you move to the next question.

**Is the action performed for the benefit of individual patients?** Population-level analytics, research aggregates, and public-health dashboards typically do not benefit individual patients in the sense the guidance intends. Software whose output is used for decisions about specific named individuals does.

**Is the intended purpose a medical purpose under Article 2(1)?** The medical purposes listed in MDR Article 2(1) are specific: 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. If the manufacturer's stated intended purpose. Across labelling, IFU, promotional materials, and the clinical evaluation, as required by MDR Article 2(12). Falls into one of these categories, the software qualifies.

Run the four questions in order, in writing, and you have a defensible qualification position. Skip a step or run them from memory, and you have an opinion. Notified Bodies audit positions, not opinions.

## The MDSW concept. What the document actually calls medical software

MDCG 2019-11 Rev.1 uses the term Medical Device Software, or MDSW, as the formal name for software that qualifies as a medical device under the MDR. "SaMD". Software as a Medical Device. Is the IMDRF term. The two overlap almost completely in practice, and the guidance acknowledges the IMDRF context, but when you write your technical file for an EU Notified Body, use MDSW. It is the language the document uses and the language the auditor expects.

MDSW under MDCG 2019-11 Rev.1 covers both stand-alone software products and software modules within larger systems. The guidance is explicit that a medical module inside a non-medical system can itself be MDSW, and that the module's boundary, intended purpose, and interfaces have to be defined clearly enough that the regulatory scope is unambiguous. This is the point most founders miss when they build a platform with one medical feature inside a broader non-medical product. The platform as a whole may not be a medical device, but the module is, and the technical file has to scope the module precisely.

For the distinction between MDSW (software that is a medical device in its own right) and software that drives or influences the use of a hardware medical device, see post 372.

## Classification via Rule 11. The walkthrough

Once software qualifies as MDSW, Annex VIII Rule 11 classifies it. MDCG 2019-11 Rev.1 walks through Rule 11's structure and resolves the interpretive questions that come up most often.

The structure of Rule 11 is a hierarchy. Software that provides information used for diagnostic or therapeutic decisions is Class IIa by default. It escalates to Class IIb if those decisions could cause serious deterioration of health or a surgical intervention, and to Class III if those decisions could cause death or irreversible deterioration. Software that monitors physiological processes is Class IIa, unless it monitors vital physiological parameters where variations could result in immediate danger, in which case it is Class IIb. All other software is Class I.

The phrase that does the work in Rule 11 is "information used to take decisions with diagnostic or therapeutic purposes." MDCG 2019-11 Rev.1 reads this phrase broadly. "Information" includes scores, gradings, classifications, recommended actions, priority flags, alerts, annotations, and anything else the software outputs that feeds into clinical reasoning. "Decisions" includes decisions made by clinicians using the software as one input among several. Not only fully autonomous decisions made by the software itself. The presence of a clinician in the loop does not drop the classification; Rule 11 is written to cover clinical decision support, and MDCG 2019-11 Rev.1 confirms this reading.

The practical consequence is that most medical software is Class IIa at minimum. The Class I floor. "all other software". Is narrower than founders hope. It captures things like simple communication tools, scheduling software, and purely educational references. It does not capture any software whose output contributes to a diagnostic or therapeutic decision about an individual patient. If your software does that. And most medical software startups are building something that does. You are looking at Class IIa, IIb, or III.

For the introductory walkthrough of Rule 11, see post 081. For the deep-dive treatment of edge cases, see post 085.

## Modules and changes. The parts founders skip

MDCG 2019-11 Rev.1 dedicates substantial space to two topics that founders typically ignore until they become urgent: modules and changes.

**Modules.** Modern medical software is rarely monolithic. A platform can contain a medical module and a non-medical module, or multiple medical modules with different classifications, or a medical module that depends on non-medical infrastructure. The guidance sets out how to draw the boundary between medical and non-medical parts, how to handle the interfaces between them, and how to scope the technical file around the medical modules without dragging the whole platform into the MDR. Draw the boundaries badly, and you either over-scope the regulatory work (expensive) or under-scope it (non-compliant). Draw them clearly, and you can keep a lean regulatory footprint inside a larger product.

**Changes.** Software evolves after release. MDCG 2019-11 Rev.1 addresses how to handle changes to MDSW that is already placed on the market. When a change is a new version under the same certification, when it is a significant change requiring notification, when it is a change of intended purpose that triggers a new conformity assessment, and when it is a change severe enough that the product is effectively a new device. This is the part of the document that matters most in the years after initial CE marking, and it is the part that most founders do not read until they hit their first significant change. Read it now and you know the rules before you need them.

## The classification examples in the guidance

MDCG 2019-11 Rev.1 contains worked examples that show Rule 11 applied to real-world software categories. The examples cover imaging software (including PACS and image-processing tools), cardiology software (including ECG interpretation and arrhythmia detection), diabetes management software (including insulin-dose calculators), dermatology software (including lesion classification), oncology software (including treatment-planning support), and several other domains. Each example states the intended purpose, walks through the qualification test, and then applies Rule 11 to land on a class.

These examples are more useful than any summary of Rule 11 because they show the reasoning, not just the result. If your software resembles one of the worked examples, you can anchor your own classification argument to the guidance's treatment of the example, and the result is much harder for a Notified Body to push back on. If your software does not resemble any example cleanly, the examples still show you the shape of the reasoning that a defensible classification argument needs.

Reading the examples is not optional work. It is the step that turns Rule 11 from a paragraph of legal text into a practical decision procedure.

## Common misapplications

Founders and even some early-stage regulatory consultants misread MDCG 2019-11 Rev.1 in predictable ways. The most common mistakes are these.

**Treating the flowchart as a checklist instead of a logical sequence.** The four qualification questions have to be run in order, and the answer to each depends on the ones before. Answering them out of order produces false negatives and false positives.

**Assuming the Class I bucket is the default.** Rule 11's "all other software" clause sits at the bottom of the rule for a reason. Most medical software moves up the hierarchy before it lands there. The Class I default is an anti-pattern in this category.

**Confusing the MDSW concept with the delivery channel.** Whether the software is a mobile app, a web platform, a desktop tool, or a cloud service does not change the qualification. The intended purpose does. App-store availability is not a regulatory filter.

**Treating the worked examples as exhaustive.** The examples in MDCG 2019-11 Rev.1 illustrate the reasoning; they do not list every possible software product. Borderline cases still require judgement, and the judgement has to be defended in writing.

**Ignoring the modules and changes sections.** These are the sections that matter most once the product is past first certification. Skipping them early means relearning them under pressure later.

**Using an older revision.** MDCG 2019-11 Rev.1 (June 2025) supersedes the October 2019 original. Regulatory positions built on the 2019 version need to be checked against the Rev.1 text before they are relied on.

## How startups should use the guidance in practice

The document is a working tool, not a reference to cite. Use it like this.

Start by reading MDCG 2019-11 Rev.1 in full, once, with a notebook open. The document is not long. Reading it end to end is a half-day exercise. Do not skim it.

Write down your software's intended purpose in one paragraph, in the form MDR Article 2(12) requires. If you cannot state it in one paragraph, the intended purpose is not yet clear, and you cannot run the qualification test reliably.

Walk your software through the qualification flowchart in writing. Record your answer to each of the four questions, with the reasoning. This document becomes the qualification section of your technical file. It is also the document you send to Tibor or any other regulatory consultant when you want a second opinion. The conversation goes faster when the consultant can read your reasoning instead of reconstructing it from a demo.

If the software qualifies, apply Rule 11 in the same way. Write the classification argument. Cross-check it against the worked examples in MDCG 2019-11 Rev.1. If your product resembles one of the examples, anchor your reasoning to that example explicitly.

If the software contains multiple modules, draw the module boundaries explicitly. State which modules are MDSW and which are not. State the interfaces between them. This is the scoping step that protects your regulatory footprint from growing beyond the medical parts of the product.

If you are past first certification and you are about to ship a change, walk the change through the guidance's changes section before you ship, not after.

All of this should happen before the engineering team commits to an architecture and before the QMS work begins. The qualification and classification answers drive everything downstream.

## The Subtract to Ship angle

MDCG 2019-11 Rev.1 is, in the Subtract to Ship sense, a simplification tool. It turns two dense MDR provisions into a repeatable procedure. A startup that uses the procedure subtracts a whole class of downstream work. Re-classifications, re-scoping, re-certifications. By getting the upstream decisions right the first time.

The other way the guidance supports the Subtract to Ship approach is by clarifying the module boundary. Most medical software startups can draw their regulatory perimeter narrowly by scoping the medical function to a clearly defined module rather than letting the whole platform be classified as MDSW. This is the kind of upstream subtraction that saves months of QMS and technical-file work later. The module boundary does not reduce the safety of the software. It reduces the paperwork by aligning the paperwork with the part of the product that is actually a medical device. For the broader framework, see post 065.

## Reality Check. Are you using MDCG 2019-11 Rev.1 the way it should be used?

1. Do you have the June 2025 revision of MDCG 2019-11. Not an older copy?
2. Have you read the guidance in full, at least once, end to end?
3. Have you written down your software's intended purpose in one paragraph, in the form MDR Article 2(12) expects?
4. Have you walked your software through the four-step qualification flowchart in writing?
5. If your software qualifies, have you applied Rule 11 explicitly and reached a defensible class?
6. Have you cross-checked your classification against the worked examples in MDCG 2019-11 Rev.1?
7. If your product contains multiple modules, have you drawn the medical/non-medical boundaries explicitly in writing?
8. If you are past first certification, do you know where the changes section of MDCG 2019-11 Rev.1 is, and have you used it before shipping significant changes?
9. Have you confirmed that your qualification and classification reasoning is consistent with your public claims on your website, app store listings, and marketing materials?
10. Has your qualification and classification position been reviewed by someone other than the founder who wrote it?

Any question you cannot answer with a clear yes is a gap in your regulatory foundation. Close it before the engineering and QMS work goes further.

## Frequently Asked Questions

**Is MDCG 2019-11 legally binding?**
No. MDCG guidance documents are not legally binding in the way the MDR text is. In practice, Notified Bodies and Competent Authorities reason in line with MDCG guidance, and a technical file that contradicts MDCG 2019-11 Rev.1 without a strong, documented argument will not pass conformity assessment. Treat it as authoritative for practical purposes and cite the MDR articles for the binding positions.

**How do I know I have the current version?**
The current version at the time of writing is Revision 1, dated June 2025. The European Commission publishes MDCG documents on its health and medical devices pages, and each document is dated. If the document you have is dated earlier than June 2025, you have an outdated version. Download the current one before relying on any specific passage.

**Does MDCG 2019-11 cover in vitro diagnostic software?**
Yes. The document covers both MDR (Regulation (EU) 2017/745) and IVDR (Regulation (EU) 2017/746) software. The qualification logic is similar, but the classification rules differ. IVDR software uses IVDR Annex VIII classification, not MDR Rule 11. If you are building IVD software, read the IVDR sections of MDCG 2019-11 Rev.1 alongside the MDR sections, and do not mix up the classification rules.

**Is MDCG 2019-11 the only guidance I need for software?**
No. It covers qualification and classification. For the software lifecycle, you need MDR Annex I Section 17 and EN 62304:2006+A1:2015. For clinical evaluation of software, you need MDCG 2020-1 and related documents. For cybersecurity, you need MDCG 2019-16. MDCG 2019-11 Rev.1 is the starting point, not the complete set.

**Can I use MDCG 2019-11 Rev.1 for AI medical software?**
For qualification and classification, yes. The document's logic applies to AI software the same way it applies to any other software. The intended purpose drives qualification; Rule 11 drives classification. What AI changes is the lifecycle, clinical evaluation, and post-market surveillance work, not the qualification and classification question itself. The forthcoming AI Act adds a separate regulatory layer on top of the MDR for AI systems.

**Our product contains one medical module inside a larger non-medical platform. Does the whole platform become MDSW?**
Not necessarily. MDCG 2019-11 Rev.1 addresses modules explicitly. If the medical module is defined clearly, has a documented intended purpose, and has well-specified interfaces with the rest of the platform, the technical file can be scoped to the module and the broader platform can remain outside the MDR. This is one of the most useful scoping moves the guidance supports.

## Related reading

- [What Is Software as a Medical Device (SaMD)? The MDR Definition for Startups](/blog/what-is-software-as-medical-device-samd-mdr) – the category pillar on MDSW qualification and classification.
- [SaMD vs SiMD. Software as a Medical Device vs Software in a Medical Device](/blog/samd-vs-simd-distinction) – the distinction the guidance relies on.
- [When Does Software Qualify as a Medical Device?](/blog/when-does-software-qualify-medical-device) – the qualification decision tree walkthrough.
- [MDR Classification Rule 11 for Software. The Short Version](/blog/mdr-classification-rule-11-software) – the entry-level spoke on Rule 11.
- [MDR Classification Rule 11 for Software. The Deep Dive](/blog/mdr-classification-software-rule-11-deep-dive) – advanced treatment including borderline cases.
- [Rule 11 Borderline Cases. Where Classification Gets Hard](/blog/rule-11-borderline-cases) – the edge-case companion.
- [Decision Support Software Under the MDR](/blog/decision-support-software-mdr) – the CDS-specific treatment.
- [Clinical Decision Support and Rule 11](/blog/clinical-decision-support-rule-11) – the CDS classification walkthrough.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) – the methodology pillar for scoping regulatory work down to what matters.

## Sources

1. MDCG 2019-11. Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745. MDR and Regulation (EU) 2017/746. IVDR. First published October 2019; Revision 1, June 2025. Published by the Medical Device Coordination Group, European Commission.
2. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 2, points 1 and 12; Annex VIII, Rule 11. Official Journal L 117, 5.5.2017.
3. EN 62304:2006+A1:2015. Medical device software. Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015).

---

*This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on the definitive European guidance for software qualification and classification. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post. MDCG 2019-11 Rev.1 is the Commission's operational reading of MDR Article 2(1) and Annex VIII Rule 11, and EN 62304:2006+A1:2015 is the lifecycle tool referenced separately for presumption of conformity with MDR Annex I Section 17. For startup-specific regulatory support on MDSW qualification, classification, and technical file scoping, Zechmeister Strategic Solutions is where this work is done in practice.*

---

*This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*