Does Your Software Qualify as a Medical Device?

The question that changes everything

Before classification, before technical documentation, before a Notified Body even enters the picture — you need to answer one question: is this software a medical device at all? Get this wrong and everything that follows is built on the wrong foundation. Teams that skip this step properly tend to discover the problem during a Notified Body audit, which is a very expensive place to find it.

EU MDR defines a medical device in Article 2(1). The definition is deliberately broad, but for software the practical test comes down to one thing: intended purpose. Not what the software can do. Not what users sometimes do with it. What you — the manufacturer — have declared the software is intended for. That declaration appears in your labelling, your IFU, your marketing materials, and your technical documentation. All of those have to be consistent.

What MDCG 2019-11 actually tells you

MDCG 2019-11 is the guidance document that walks through software qualification under MDR. It's worth reading in full, but the core logic is a decision tree: does the software perform an action on data? Is that action beyond simple storage, archiving, communication, or lossless compression? Does the action benefit an individual patient (rather than a population)? If you answer yes to all three, you're almost certainly in SaMD territory.

One thing that catches a lot of teams off guard: the "benefit an individual patient" question is where many clinical decision support tools land. If your software analyses patient data and produces a recommendation or flag that a clinician uses to make a decision about that specific patient, the MDCG position is clear — that's medical device software. The fact that a human makes the final call doesn't take it out of scope.

What typically doesn't qualify

MDCG 2019-11 gives useful examples of software that falls outside MDR scope:

• Software that stores or routes clinical data without modifying it (e.g. a basic PACS viewer that doesn't perform analysis)
• Administrative software: scheduling, billing, coding tools
• Software intended for general wellness purposes — monitoring sleep or fitness without a specific medical claim
• Software that processes population-level data for research, with no direct patient-level output used for individual decisions

The line between "out of scope" and "qualified as SaMD" often sits exactly where you'd expect trouble: software that started as a research tool but gets used clinically, or a wellness app where the manufacturer adds claims about detecting or managing a condition. The intended purpose stated by the manufacturer is the anchor — not how users actually deploy it.

The intended purpose test in practice

When you sit down to do this assessment, work through it in this order:

1. Write out your intended purpose statement — exactly as it would appear in your IFU. If it's not written yet, drafting it forces the clarity this exercise needs.
2. Ask: does the software take action on data to produce a specific output? Retrieval and display alone don't count. Calculation, analysis, detection, diagnosis, prediction — these do.
3. Ask: is that output used in, or does it support, a clinical decision about a specific patient? If yes, you are very likely in SaMD scope.
4. Check the MDCG 2019-11 decision tree against your answers. The document has explicit worked examples — use them.

If you're on the borderline, document your rationale thoroughly. Regulators and Notified Bodies want to see that you engaged with the question, not that you assumed your way to an answer.

What qualification unlocks

Once you've confirmed your software qualifies as a medical device, you move to classification. Rule 11 in Annex VIII is the rule that applies to software, and it connects directly back to intended purpose — specifically, to the severity of harm that could result if the software fails or provides incorrect output. That's the next step in the chain.

If you've determined your software does not qualify, document that assessment anyway. Regulators can and do ask why a manufacturer concluded a product is out of scope. A reasoned, documented non-qualification is much more defensible than silence.