---
title: When Does Software Qualify as a Medical Device Under MDR? Decision Flowchart
description: MDR Article 2(1) and MDCG 2019-11 Rev.1 together answer when software qualifies as a medical device. Here is the decision flowchart in plain text.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: when does software qualify medical device MDR
canonical_url: https://zechmeister-solutions.com/en/blog/when-does-software-qualify-medical-device
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# When Does Software Qualify as a Medical Device Under MDR? Decision Flowchart

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

> **Software qualifies as a medical device under the MDR when four conditions are met in sequence: it is software in the MDCG 2019-11 Rev.1 sense, it performs an action on data that goes beyond storage, archival, lossless compression, communication, or simple search, the action is performed for the benefit of individual patients, and the manufacturer's stated intended purpose falls within one of the specific medical purposes listed in Article 2(1) of Regulation (EU) 2017/745. All four conditions must hold. If any one of them fails, the software is not a medical device under the MDR. The decision tree in MDCG 2019-11 Rev.1 (June 2025) is the walk-through that Notified Bodies and Competent Authorities use to answer this question consistently.**

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

---

## TL;DR

- The MDR qualification test for software has four sequential gates: is it software, does it act on data beyond storage and search, is the action for individual patients, and does the intended purpose meet Article 2(1).
- The stated intended purpose drives the answer. Technology stack, deployment model, and business model are irrelevant to qualification.
- MDCG 2019-11 Rev.1 (June 2025) provides the decision tree that operationalises Article 2(1) for software. It is the definitive walk-through.
- A failure at any gate means the software is not a medical device under the MDR. A pass at all four means it is, and Annex VIII Rule 11 then classifies it.
- Claims on websites, app store listings, IFUs, and marketing materials all count toward the intended purpose under Article 2(12). Investor-deck claims do not bind the Regulation but bind reality once the product ships.
- The qualification answer must be in writing before the engineering team picks a framework. Every downstream decision flows from it.

---

## Why the qualification question is the decision that sets everything else

In medical software, the qualification question is the single most expensive decision a founder makes, and it is also the one most often deferred. We have met teams eighteen months into building a product who still could not state cleanly whether what they were building was a medical device. The answer changes the entire regulatory file, the QMS obligations, the clinical evaluation scope, the post-market surveillance plan, and the time-to-market. Deferring it does not make it go away; it only makes the cost of getting it wrong compound.

The qualification question is also the one where founders most often guess. The guess usually runs in one of two directions. Direction one: "We are just a tool, we are not a medical device." The team ships, marketing adds a clinical claim to improve conversion, and eighteen months later a Competent Authority reads the claim and the product is retroactively a non-conforming medical device on the EU market. Direction two: "We will assume we are a medical device, just to be safe." The team builds a full QMS and spends a year on documentation for a product that a small rewording of the intended purpose would have kept outside the MDR entirely. Both directions are expensive. Both are avoidable by running the qualification test in writing on day one, using the decision tree in MDCG 2019-11 Rev.1.

This post walks through that decision tree, gate by gate, in the order MDCG 2019-11 Rev.1 applies it.

## The qualification question — what the MDR text actually asks

The MDR does not provide a standalone qualification test for software. It provides the general medical device definition in Article 2(1), which names software explicitly as one of the things that can be a medical device, and it provides the intended-purpose definition in Article 2(12). MDCG 2019-11 Rev.1 is the document that operationalises those two articles for software specifically.

The foundation is Article 2(1):

> *"'medical device' means any instrument, apparatus, appliance, software, implant, reagent, material or other article intended by the manufacturer to be used, alone or in combination, for human beings for one or more of the following specific medical purposes: 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; providing information by means of in vitro examination of specimens derived from the human body..."* — Regulation (EU) 2017/745, Article 2, point 1.

Two elements in that sentence are load-bearing for software. "Software" is named explicitly — there is no carve-out for code, apps, cloud services, or algorithms. And "intended by the manufacturer" — the test is driven by the manufacturer's stated intended purpose, not by how users end up using the product.

Article 2(12) defines intended purpose:

> *"'intended purpose' means the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation"* — Regulation (EU) 2017/745, Article 2, point 12.

This is the definition that makes the qualification test sensitive to every public claim the manufacturer makes. Labelling, IFU, website copy, app store listing, sales materials — all of them count.

## The MDCG 2019-11 Rev.1 decision steps

MDCG 2019-11 Rev.1 — Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 — MDR and Regulation (EU) 2017/746 — IVDR — was first published in October 2019 and revised in June 2025. The June 2025 revision is the current version. If you find an older copy online, you are reading a superseded document.

The guidance provides a qualification decision tree that walks any piece of software through four sequential gates. The gates are applied in order. The first gate that fails stops the process — the software is not a medical device, and no further analysis is needed. Only software that passes all four gates is a medical device and moves on to the classification question under Annex VIII Rule 11.

The four gates are: (1) is it software; (2) does it perform an action on data beyond storage, archival, lossless compression, communication, or simple search; (3) is the action performed for the benefit of individual patients; (4) does the intended purpose meet Article 2(1). The remainder of this post walks through each gate with the reasoning Notified Bodies and Competent Authorities apply.

## Gate 1 — Is it software?

This sounds trivial. It is not. MDCG 2019-11 Rev.1 defines software broadly: any set of instructions that processes input data and creates output data. That definition includes mobile applications, cloud services, web platforms, algorithms embedded in larger systems, modules within medical devices, and scripts that execute on general-purpose computing hardware. It also includes machine-learning models, regardless of how they were trained.

What the gate is screening out is not "is this code" — almost everything that is code passes this gate. What it is screening out is confusion about whether an analogue process or a hardware function is being called "software" by habit. A mechanical interlock is not software. A paper worksheet is not software. A lookup table printed in a manual is not software. If the thing executes instructions on a processor and produces data output from data input, it is software for the purpose of the MDCG 2019-11 Rev.1 test, and this gate passes.

## Gate 2 — Does the software perform an action on data beyond storage, archival, lossless compression, communication, or simple search?

This is the "more than a database" gate, and it is where many wellness and health-adjacent products fall out of the MDR correctly. MDCG 2019-11 Rev.1 lists five actions that by themselves do not qualify as medical device actions: storage, archival, lossless compression, communication, and simple search.

Pure storage is not medical device action. A cloud backup of patient records is not a medical device on the storage alone. Pure archival is not action. Pure communication — transmitting a signal from a device to a clinician's workstation — is not action. Lossless compression that reduces file size without changing meaning is not action. And simple search — looking up a record by a specified field — is not action.

What crosses the gate is any action that changes the meaning of the data or produces new information from it. Calculation. Interpretation. Pattern recognition. Risk scoring. Thresholding and alerting. Segmentation. Classification. Prediction. Normalisation that corrects for clinically relevant variables. Decision support based on rules or models. Each of these actions transforms the data in a way that the output is not simply a representation of the input but a new clinical artefact.

The line is sharper than it sounds. A DICOM viewer that displays an image as it was captured is storage and communication. A DICOM viewer that measures, annotates, segments, or enhances the image crosses the action threshold. A lab information system that stores and retrieves results is storage and search. A lab information system that applies reference ranges and flags values as abnormal crosses the action threshold. The difference between "below the gate" and "above the gate" is often a single feature.

## Gate 3 — Is the action performed for the benefit of individual patients?

The third gate screens out software whose action, even if it crosses the data-action threshold, is not directed at decisions about specific individuals. General public-health dashboards that aggregate anonymised population data. Epidemiological research analytics. Hospital operations dashboards that show bed occupancy and staffing. Billing and administration software that processes claims. These products may act on medical data, but the action is not for the benefit of individual patients in the sense the MDR uses.

What passes this gate is any software whose output is used to inform decisions, monitoring, diagnosis, or treatment of specific individuals. The test is the unit of action. If the output is a number, score, alert, or recommendation attached to one patient, the gate passes. If the output is a statistic attached to a population, it does not.

Borderline cases appear in two forms. First, research-use software that starts on population data and later gets used per-patient. The qualification follows the stated intended purpose; if the purpose is written as per-patient, the gate passes, regardless of the data volume. Second, quality-improvement dashboards that flag individual cases for review. These often pass the gate even when founders assume they do not, because the output attaches to individual patients, not to the population.

## Gate 4 — Does the intended purpose meet Article 2(1)?

This is the decisive gate, and it is also the one that founders can influence through the wording of the intended purpose. Article 2(1) lists specific medical purposes: diagnosis, prevention, monitoring, prediction, prognosis, treatment, alleviation of disease; diagnosis, monitoring, treatment, alleviation of, or compensation for an injury or disability; investigation, replacement, or modification of the anatomy or a physiological or pathological process or state.

If the manufacturer's stated intended purpose falls into one of these categories, the software is a medical device. If it does not, it is not.

What does not qualify, if the intended purpose is written correctly and held consistently across all public claims: lifestyle and wellness applications without medical claims; general fitness trackers; simple appointment-booking software; hospital administration and billing; educational or reference tools that do not provide patient-specific recommendations; and software that stores or transmits medical data without acting on it in a clinical sense.

The gate is sensitive to phrasing. A sentence on a website that promises "early detection of atrial fibrillation" brings the software inside. The same product with a sentence that promises "heart-rate tracking for general wellness" may stay outside. The choice is legitimate either way, as long as it is made deliberately and held consistently. What breaks founders is not the choice — it is the inconsistency between the regulatory claim and the marketing claim.

## Intended purpose first — the discipline that makes the test repeatable

The qualification test is only as reliable as the intended-purpose statement it runs against. If the intended purpose is not written down, the test cannot be run. If the intended purpose on the website contradicts the intended purpose in the technical file, the test runs twice and produces two answers.

The discipline is to write the intended purpose first — one paragraph, in the form Article 2(12) expects — and run the qualification test against that paragraph. Then make every public claim match. The website, the app store listing, the pitch deck, the sales collateral, the IFU, the clinical evaluation — all of them say the same thing about what the software is for. If they do not, the qualification answer is unstable, and the product carries a regulatory risk that cannot be closed without rewriting the claims.

This is where MDCG 2019-11 Rev.1 becomes a practical tool rather than a theoretical reference. The decision tree in the guidance is designed to be run once against a clear intended-purpose statement. Run it against something vague and you get a vague answer. Run it against a one-paragraph statement that covers labelling, IFU, and promotional materials, and you get a defensible answer that a Notified Body will recognise.

## The action criterion — where most borderline cases live

In practice, most software that is borderline under the MDR is borderline at Gate 2, not at Gate 4. The intended purpose is often clearly medical; the question is whether the software's action crosses the threshold above storage, communication, and simple search.

Two clarifications from MDCG 2019-11 Rev.1 are worth holding in mind. First, "simple search" is narrower than it sounds. A query that returns records matching exact field values is simple search. A query that ranks, filters by clinical relevance, applies inclusion/exclusion logic based on clinical criteria, or combines results from multiple sources with weighting is not simple search — it is an action. Second, "communication" covers the transport of data, not the transformation of it. A system that relays a signal from a sensor to a display is communication. A system that converts the signal into an alert, a trend, or a diagnosis is not.

The cleanest way to test Gate 2 on a specific product is to ask: would the clinical output still exist if we removed the software and performed the underlying steps by hand using the input data? If the answer is yes and the software is just automating a retrieval or a display, the gate does not cross. If the answer is no — if the output exists because the software computed, interpreted, or transformed the data — the gate crosses.

## The human-in-the-loop nuance

Founders often ask whether having a clinician in the loop pulls the software out of the medical device category. It does not. MDCG 2019-11 Rev.1 is explicit that decision-support software used by clinicians is still a medical device if its output informs diagnostic or therapeutic decisions about individual patients. The presence of a clinician in the loop is a factor in risk — because the clinician can catch a wrong output before it becomes a wrong decision — but it is not a factor in qualification.

The consequence is that "it is just decision support, a doctor always decides" is not a qualification argument. It may be part of a classification argument at the edges of Rule 11, and it is part of the risk-management story. But it does not answer the qualification question. The question at qualification is whether the software provides information used for medical purposes. If it does, and the other gates pass, it is a medical device.

## Examples — passing and failing the test

- **Passes all four gates (medical device):** A mobile application that interprets ECG traces recorded by the phone and returns a classification of normal sinus rhythm or atrial fibrillation. Software (Gate 1); acts on data beyond storage by classifying (Gate 2); per-patient (Gate 3); diagnostic purpose (Gate 4).
- **Passes all four gates:** A cloud-based imaging tool that segments tumours on CT scans and returns volume measurements used by oncologists for treatment planning. Software; acts by segmentation and measurement; per-patient; diagnostic and monitoring.
- **Passes all four gates:** A clinical decision-support platform that reads lab values and flags patients at risk of sepsis for clinician review. Software; acts by risk scoring; per-patient; monitoring and prediction.
- **Fails Gate 2:** A pure DICOM archive that stores and retrieves images without analysis. Software; action is storage and search only.
- **Fails Gate 3:** A population-health dashboard that aggregates anonymised data for public-health reporting. Software; may act on data; but the action is not directed at individual patients.
- **Fails Gate 4:** A fitness tracker that records step counts and heart rate with wellness positioning and no medical claims on any public surface. Software; may act on data; per-user; but the stated intended purpose is general wellness, not a medical purpose under Article 2(1).

The critical case to watch is the last one. The fitness tracker fails Gate 4 only as long as the public claims match the non-medical positioning. The moment the marketing adds "early detection of atrial fibrillation" or "screen for arrhythmia," the intended purpose under Article 2(12) changes, and the product passes Gate 4 retroactively. The regulatory status follows the claims, not the engineering.

## Common errors at each gate

**Gate 1 — "We are not software, we are an AI model."** Machine-learning models are software under MDCG 2019-11 Rev.1. The gate passes.

**Gate 2 — "We only show the data, we do not interpret it."** If the display includes highlighting, thresholding, colour-coding based on clinical ranges, or ranking, the software is doing more than showing. Re-read the feature list against the five exempt actions.

**Gate 2 — "Our search is simple."** A search that applies clinical filtering or ranking is not simple search. The threshold is narrower than the word suggests.

**Gate 3 — "We are research-use only."** The stated intended purpose controls. A product marketed for research but deployed per-patient in a hospital is in a contradiction that the Regulation resolves against the manufacturer.

**Gate 4 — "We have no medical claims because we said so internally."** The test runs on all public claims, including website copy, app store listings, and sales decks. Internal intentions do not override public statements under Article 2(12).

**Gate 4 — "The doctor is always in the loop, so we are not a medical device."** Human-in-the-loop is not a qualification exit. Decision-support software is still a medical device.

## The Subtract to Ship angle

The qualification test is one of the cheapest things to get right if it is done first and one of the most expensive things to get wrong if it is deferred. The Subtract to Ship discipline here is to run the four-gate test in writing before the engineering team picks a framework, before the website is written, before the first customer conversation.

What Subtract to Ship subtracts in this context is guesswork. The four gates are deterministic — given a clear intended-purpose statement, they produce one answer, and the answer is defensible against a Notified Body or a Competent Authority. Running the test takes an hour. Reversing a wrong answer eighteen months later takes months of rework and sometimes a full re-development. Post 065 covers the Subtract to Ship framework for MDR as a whole; this post is a specific application to one of the two highest-leverage decisions in medical software (the other being classification under Rule 11).

What Subtract to Ship does not subtract here is the test itself. Skipping the test is not lean — it is debt. The test is the foundation every downstream regulatory decision stands on. Run it once, in writing, with MDCG 2019-11 Rev.1 open, and keep the result current as the intended purpose evolves.

## Reality Check — Where do you stand on the qualification question?

1. Have you written down the intended purpose of your software in one paragraph, in the form Article 2(12) expects, covering labelling, IFU, and promotional materials?
2. Have you walked your software through the MDCG 2019-11 Rev.1 four-gate decision tree in writing, and recorded the answer at each gate?
3. At Gate 2, have you listed every action your software performs on data and confirmed which ones go beyond storage, archival, lossless compression, communication, or simple search?
4. At Gate 3, can you state whether the software's output attaches to individual patients or to populations?
5. At Gate 4, does your stated intended purpose use the specific language of Article 2(1) or map cleanly onto one of its listed medical purposes?
6. Do all your public claims — website, app store, sales materials, pitch deck, IFU — match the intended purpose you ran the test against?
7. If your qualification answer is "not a medical device," can you hold that position without modifying a single public claim?
8. If your qualification answer is "medical device," have you moved on to classification under Annex VIII Rule 11?

Any question you cannot answer with a clear yes is a gap that will widen as the product ships. Close it before the next sprint starts.

## Frequently Asked Questions

**Can software be a medical device without a manufacturer label?**
Under Article 2(12), intended purpose is defined by the data supplied by the manufacturer on the label, in the IFU, in promotional materials, and in the clinical evaluation. If there is no label, the remaining sources still supply the intended purpose. If a product is placed on the market with no claims at all, the qualification question is answered by the absence of medical claims — which typically means it is not a medical device under Article 2(1), but only if that absence is genuine and held across all public surfaces.

**Does MDCG 2019-11 Rev.1 have legal force?**
MDCG guidance documents are not legally binding in the way the MDR text is, but they represent the consensus interpretation of the European Commission and the Member States, and Notified Bodies apply them as the operational reference. In practice, a qualification argument that contradicts MDCG 2019-11 Rev.1 will not survive Notified Body review without a very strong written justification.

**What if my software has medical and non-medical modules?**
MDCG 2019-11 Rev.1 addresses mixed-module software explicitly. The medical module is a medical device; the non-medical module is not. The challenge is demonstrating separation — the modules must be clearly delimited, documented as separate, and the regulatory boundary must be held across labelling, IFU, and risk management. Post 374 covers this case in more detail.

**What if I change my intended purpose after launch?**
Changes to intended purpose are substantial changes under the MDR. A change that moves a product across the qualification boundary — from non-medical to medical, or the reverse — is a major regulatory event that requires formal assessment. A change within the medical device category — from one intended medical purpose to another — may also trigger re-assessment. The qualification answer is not a one-time decision; it is maintained over the product's lifecycle.

**If my software is used off-label for a medical purpose, am I a medical device?**
The qualification follows the manufacturer's stated intended purpose, not off-label use. But if the manufacturer becomes aware of a pattern of off-label use and does not act to correct it — or worse, implicitly endorses it in marketing — Competent Authorities can and do treat that as evidence of the real intended purpose. The safe position is to state the intended purpose clearly, enforce it in labelling, and act promptly on off-label use.

**Does the qualification answer change if I am only in Europe?**
No — MDCG 2019-11 Rev.1 and the MDR apply to any product placed on the EU market. Being a European-only product does not change the qualification test; it just means the MDR is the only regulation that applies. A product placed on both the EU and US markets runs separate qualification tests under MDR and FDA frameworks, which may produce different answers.

## Related reading

- [MDR Classification Rule 11 for Software — The Short Version](/blog/mdr-classification-rule-11-software) — the classification rule that applies once qualification is answered yes.
- [Rule 11 Borderline Cases](/blog/rule-11-borderline-cases) — the edge cases where classification under Rule 11 is contested.
- [What Is Software as a Medical Device (SaMD)?](/blog/what-is-software-as-medical-device-samd-mdr) — the pillar post for the SaMD category, covering the full lifecycle after qualification.
- [SaMD vs. Software in a Medical Device (SiMD)](/blog/samd-vs-simd-distinction) — the split that follows qualification when the software is embedded in or drives a hardware device.
- [MDCG 2019-11 Rev.1 — What the Software Guidance Actually Says](/blog/mdcg-2019-11-software-guidance) — the full reading of the decision tree referenced in this post.
- [Intended Purpose for Medical Software](/blog/intended-purpose-medical-software) — the discipline of writing the intended-purpose paragraph that the qualification test runs against.
- [The MDR Software Lifecycle and EN 62304:2006+A1:2015](/blog/mdr-software-lifecycle-iec-62304) — the lifecycle obligations that attach once qualification passes.
- [Wellness vs. Medical Device Software](/blog/wellness-vs-medical-device-software) — the Gate 4 distinction in practice.
- [Clinical Decision Support Under MDR](/blog/clinical-decision-support-mdr) — how the human-in-the-loop nuance plays out for CDS tools.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology pillar for the blog, with direct application to software qualification.

## Sources

1. 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.
2. 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.
3. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015).

---

*This post is part of the Software as a Medical Device Under MDR category in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — MDCG 2019-11 Rev.1 operationalises Article 2(1) and Article 2(12) for software qualification, and the decision tree in the guidance is the walk-through that Notified Bodies and Competent Authorities use. For startup-specific regulatory support on software qualification and classification, 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).*