"When does software become a medical device in the EU?"

If you are building a health app, a diagnostic tool, or anything that sits near clinical data, you have probably asked yourself some version of this: does my software count as a medical device? Do I need to worry about MDR? Is this going to require a notified body?

The answer is not as complicated as the regulatory documentation makes it sound. It comes down to one question.

The one question that decides everything

Under the EU Medical Device Regulation (MDR 2017/745), what determines whether your software is a medical device is its intended purpose -- what you say it is for, not what it technically could do.

The EU defines a medical device as any product intended to be used for a medical purpose: diagnosing, preventing, monitoring, predicting, prognosing, treating, or alleviating disease or injury. If your software is intended to do any of those things, it is probably a medical device.

The word "intended" is doing a lot of work there. It means your claims -- your marketing copy, your product documentation, the way you describe what the software does -- are what regulators look at. A piece of software that could theoretically help with diagnosis but is explicitly marketed as a general wellness tool sits in a very different position than one whose documentation says "supports clinical decision-making for Type 2 diabetes management."

Practical questions to ask yourself

Read through your product description, your website, and any documentation you give to users or customers. Then ask:

Does your software claim to diagnose, detect, or predict a condition? An app that says "identifies early signs of atrial fibrillation" is making a diagnostic claim. One that says "tracks your heart rate" probably is not.

Does it influence clinical decisions? Software that surfaces information to a clinician in a way that is intended to drive a clinical decision -- prescribing, diagnosis, treatment selection -- is in SaMD territory. Software that just stores or displays data without making any clinical claim is on safer ground.

Is the user a patient or a clinician in a clinical context? Consumer wellness apps marketed to healthy people ("track your sleep") sit differently to software marketed to healthcare professionals for use with patients.

If you answered yes to any of these, you are probably looking at a medical device. If you answered no to all of them, you are likely outside the scope of MDR -- but it is worth reviewing your claims carefully, because the intended purpose can shift based on how you talk about your product.

What "general purpose software" means

The EU explicitly carves out general purpose software from medical device classification. A spreadsheet used to record patient data is not a medical device. An HR system used in a hospital is not a medical device. Neither is email, a calendar app, or a data backup tool.

What matters is not the environment (healthcare) but the function. If your software makes no claims about medical purpose and does not influence clinical outcomes, the fact that it is used in a hospital does not make it a regulated device.

If you are a medical device -- what happens next

Once you have determined that your software is a medical device, a few things follow:

Classification. EU MDR uses a risk-based classification system -- Class I, IIa, IIb, and III. Most software falls under Rule 11 of the MDR classification rules. The higher the potential impact on a patient if the software fails, the higher the class. Class I is self-certified by the manufacturer. Class IIa and above requires a notified body.

IEC 62304. This is the standard for software lifecycle processes for medical device software. It covers how you develop, maintain, and release your software in a way that satisfies regulators. If you are a medical device, this is what governs your development process.

ISO 13485. This is the QMS standard for medical device manufacturers. It describes the organisational processes -- documentation, change control, risk management, complaints handling -- that need to be in place. Our plain-English guide to what a QMS is covers the building blocks in detail.

A QMS. You need one. Not because the paperwork is valuable in itself, but because the evidence it generates is what you will need to demonstrate compliance to a notified body, a customer, or a regulator.

The honest take for early-stage teams

Most founders discover they are building a medical device the same way -- a potential enterprise customer asks for your ISO 13485 documentation and you realise you don't have any.

The good news is that getting your foundations in order does not require a consultant and six months of process mapping. The standards are not as scary as they look, and if you are already building software properly -- with requirements, test cases, version control, and a documented release process -- you are closer than you think.

The main thing early-stage teams need to do is start treating compliance as part of their development process, not a separate project for later. The teams who do that from the beginning have a significantly easier time when notified body reviews or enterprise procurement audits come around.

Where QualiHQ fits

If you have established that your software is a medical device and you need to get your QMS in place, QualiHQ handles the documentation layer. QualiHQ AI will help define your requirements, link them to your verifications and test evidence, run your risk analysis, and push releases through a structured approval process.

The audit trail builds as you work. If a notified body or enterprise customer asks to see your traceability matrix, your release records, or your risk assessment, you have it -- without having to reconstruct it from memory and Github PRs.

Get started free and see how far you can get before anyone charges you anything.

Not sure whether MDR applies to your specific product? The European Commission's MDCG 2019-11 guidance document on software classification is the authoritative reference. For anything with real regulatory stakes, a qualified regulatory affairs consultant is worth the investment.