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

If a piece of software is meant to diagnose a condition, recommend a treatment, or calculate a drug dose, the law in Europe treats it as a medical device, not as an app. That is the short answer to a question I get often from founders and engineers: why does my health product suddenly need a regulatory file when a calorie tracker does not? The dividing line is intended purpose. A tool that informs a clinical decision can cause harm if it is wrong, so it carries obligations that a step counter never will.

This article explains the main rules in plain terms: EU MDR, IVDR, and the idea of Software as a Medical Device (SaMD). None of it is medical or legal advice. It is meant to help you understand the landscape before you talk to a notified body or a regulatory consultant.

What EU MDR, IVDR, and SaMD actually mean

EU 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. IVDR is its sibling, the In Vitro Diagnostic Regulation (2017/746), which governs tests run on samples taken from the body: blood glucose meters, lab assays, and the software that interprets their results. If your product analyzes a specimen or its data, you are usually in IVDR territory. If it acts on the patient more directly, you are usually under MDR.

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

The practical consequence is classification. Both MDR and IVDR sort products into risk classes, and software tends to climb the ladder fast. Under MDR, Rule 11 means that software intended to provide information used for diagnosis or treatment decisions is rarely the lowest class. The higher the class, the more evidence you need and the more likely it is that an independent notified body has to review your work before you can sell.

Why software gets regulated at all

It helps to remember what regulation is for. A medical device can hurt someone in ways that are not always visible from the outside. A model trained on one population can quietly underperform on another. A user interface can nudge a tired clinician toward the wrong reading. A silent update can change behavior between Tuesday and Wednesday. Regulation exists to make 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 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 the model's performance is a claim that has to be measured, documented, and monitored rather than assumed.

I think of this as the price of being believed. When a hospital integrates a decision-support tool, the clinicians using it are extending trust to people they will never meet. A regulatory file is the structured way of earning that trust in advance: here is what the software is for, here is the evidence it works, here is how we will know if it stops working.

Regulation and clinical trust 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 better framing is that the discipline regulation demands is the same discipline that makes a clinical product good. Defining intended purpose forces clarity about what you are claiming. Risk management forces you to imagine how your tool fails in a real clinic. Clinical evidence forces you to test the claim instead of asserting it.

I have lived on both sides of this. When we built EASY Diabetes, an AI decision-support system for type 2 diabetes, the work that mattered was not only the model. It was the registered randomized controlled trial, EASY-1 (NCT03258268), a multi-clinic study that evaluated the tool against standard of care. That kind of evidence is what turns a clever system into something a clinician can responsibly lean on. The product later received Sweden's Medtech4Health Innovation Award, but the award followed the evidence.

To work in this space seriously, I trained for it directly: a Medical Device Regulations training from KTH Royal Institute of Technology covering EU MDR, IVDR, FDA pathways, and Software as a Medical Device, alongside FDA Clinical Investigator Training. The training changed how I read a product roadmap. Once you understand the regulatory frame, you start designing for evidence and safety from the first sprint, rather than bolting them on when a notified body asks.

If you are building health software, the most useful early question is not "how do we avoid being a medical device." It is "what are we claiming, and what would it take to prove it." Answer that honestly and most of the regulatory path becomes legible.

This article is educational and general. It is not medical or legal advice, and it is not a substitute for a qualified regulatory assessment of your specific product.