EU MDR and Software as a Medical Device, in Plain Language

When a piece of software is meant to diagnose a condition, guide a treatment choice, or calculate a drug dose, European law treats it as a medical device, not as an app. That single idea, intended purpose, is what separates a regulated diagnostic tool from a calorie tracker. A step counter that guesses wrong costs you nothing clinically. A tool that shapes a clinical decision can cause harm if it is wrong, so it carries obligations the step counter never will.

This article walks you through the landscape in plain terms: the two European regulations (MDR and IVDR), the concept of Software as a Medical Device, and why any of this exists. It is meant to help you understand the terrain before you talk to a notified body or a regulatory specialist.

Key points#

• What decides regulation is the software's intended purpose, not how it is packaged or marketed.
• MDR (Regulation 2017/745) governs devices that act on the patient; IVDR (2017/746) governs tests run on samples taken from the body, and the software that interprets them.
• Software as a Medical Device (SaMD) is software that performs a medical function on its own, without being part of a physical instrument.
• Under MDR Rule 11, software that informs diagnosis or treatment rarely sits in the lowest risk class, so it usually needs independent review.
• The evidence a regulator asks for (defined purpose, risk management, clinical proof, ongoing monitoring) is the same discipline that makes the product clinically sound.

The dividing line: intended purpose#

The first question a regulator asks is not "what does the code do?" but "what is it for?" Two apps can run the same calculation and land on opposite sides of the line. A fitness app that estimates calories burned is a lifestyle product. Software that estimates an insulin requirement from the same inputs is making a clinical claim, and that claim can hurt someone.

Because intended purpose drives everything, wording matters. Describing a product as a tool that "supports diagnosis" or "recommends a dose" places it squarely inside the regulations. Trying to dodge that by softening the marketing copy while the software still performs a clinical function does not change the legal reality; regulators look at function, not slogans.

MDR, IVDR, and SaMD in one pass#

MDR is the European Medical Device Regulation (Regulation 2017/745). It replaced the older directives and raised the bar for clinical evidence, post-market surveillance, and traceability across the European market. Broadly, MDR covers products that act on the patient more directly.

IVDR is its counterpart, the In Vitro Diagnostic Regulation (2017/746). It governs tests performed on samples taken from the body: blood glucose meters, laboratory assays, and the software that interprets their results. As a rough rule, if a product analyzes a specimen or the data from one, it usually falls under IVDR; if it acts on the patient, it usually falls under MDR.

Software as a Medical Device, or SaMD, is the term for software that performs a medical function on its own, without being embedded in a physical instrument. The phrase comes from the International Medical Device Regulators Forum, and it is useful precisely because older rules struggled to name this category. An algorithm that flags a suspicious image, or that proposes a dose adjustment, is a device in its own right even though it ships purely as code.

How software climbs the risk ladder#

Both MDR and IVDR sort products into risk classes, and software tends to rise quickly. Under MDR, Rule 11 states that software intended to provide information used for diagnostic or treatment decisions is rarely placed in the lowest class. The higher the class, the more clinical evidence is required, and the more likely it is that an independent notified body has to review the work before the product can reach the market.

A helpful way to picture the classes is by asking two questions the regulations themselves ask: how serious is the health situation the software addresses, and how much weight does its output carry in the decision? Software that offers background information for a low-stakes situation sits low on the ladder. Software whose output drives an immediate, high-stakes action sits near the top. Most clinically interesting products fall somewhere in the middle and above, which is why so many teams end up needing a notified body.

Why software gets regulated at all#

It helps to remember what regulation is for. A medical device can fail in ways that are invisible from the outside. A model trained on one population can underperform on another without any warning sign. An interface can nudge a tired clinician toward the wrong reading. A silent update can change the software's behavior overnight. Regulation exists to make each of those failure modes someone's explicit responsibility.

That is why the rules ask for things that feel heavy at first: a clear statement of intended purpose, a documented risk-management process, clinical evidence proportionate to the claim, and post-market surveillance so that real-world problems feed back into the product. For AI and machine-learning systems the same logic applies with sharper edges, because a model's performance is itself a claim that has to be measured, documented, and monitored rather than assumed.

Think of it as the structure behind being believed. When a hospital adopts a decision-support tool, the clinicians using it are extending trust to people they will never meet. A regulatory file is the organized way of earning that trust in advance: here is what the software is for, here is the evidence that it works, and here is how anyone will know if it stops working.

Compliance and clinical quality are the same project#

It is tempting to treat compliance as a tax on innovation, a stack of paperwork between a good idea and the market. The more accurate framing is that the discipline the regulations demand is the same discipline that makes a clinical product good in the first place. Defining intended purpose forces clarity about what is being claimed. Risk management forces a team to imagine how the tool fails in a real clinic. Clinical evidence forces a claim to be tested rather than asserted.

This mirrors how careful evidence appraisal works anywhere in medicine. A study is only as trustworthy as its methods, its population, and its willingness to report where it falls short. Software is no different. The most useful early question for a health-software team is not "how do we avoid being a medical device?" It is "what exactly are we claiming, and what would it take to prove it?" Answer that honestly and most of the regulatory path becomes legible.