p4mx health
← All impulses
Medical softwareJuly 27, 2026· 3 min read

When software becomes a medical device — and when it does not

Whether an application is regulated as a medical device is decided by its intended purpose, not by its technology. The same code can be a harmless evaluation tool or software requiring conformity assessment, depending on what the manufacturer says it should do. This article shows what the classification hangs on and how to make it early and deliberately.

Many teams ask the question too late: is the software we are building a medical device? The answer rarely lies in the technology. It lies in what the software, according to its manufacturer, is meant to do. Clarifying this early saves expensive reversals later — in both directions.

The intended purpose decides, not the technology

The starting point is the definition in Article 2(1) of the Medical Device Regulation (MDR). Under it, a product is a medical device if the manufacturer intends it for a medical purpose: prevention, diagnosis, monitoring, prediction, prognosis, treatment or alleviation of disease, as well as of injury or disability. This declared use is called the intended purpose.

What matters, therefore, is the claim, not the implementation. Two applications with identical source code can be classified differently if one merely displays values while the other supports a medical decision. The MDCG 2019-11 guidance issued by the European coordination group walks through this in traceable decision steps — it is the practical way into the question “medical device: yes or no?”.

An example

Take a dashboard that presents a patient’s laboratory values. As long as it only collects, stores and displays those values, it pursues no medical purpose of its own. Add to that same interface a note such as “value critical, review dose”, and the software is now providing information for a diagnostic or therapeutic decision. A display has become decision support — and with that, very probably a medical device. The difference lies not in the data set but in the intended purpose.

How the risk class comes about

If the software is a medical device, its risk class follows the rules in Annex VIII of the MDR. For software, Rule 11 is the decisive one. Simplified: software that provides information for diagnostic or therapeutic decisions is regularly placed in class IIa. The more serious the possible harm from a wrong decision, the higher the class — up to class III where a decision may lead to death or an irreversible deterioration in health. Software for monitoring physiological processes follows its own thresholds. Class I remains the exception for medical software.

The revised guidance (MDCG 2019-11 Rev.1, June 2025) sharpens these examples and addresses software containing artificial intelligence explicitly. If your product includes AI components, the AI Act (EU) 2024/1689 applies alongside the MDR; both frameworks operate in parallel.

How to proceed

In practice, this order has proven itself:

  1. Set down the intended purpose in writing — what the product is meant to do medically, and expressly what it is not.
  2. Qualify it against MDCG 2019-11: medical device, yes or no?
  3. Where the answer is yes, determine the class via Rule 11 and additionally mirror any AI component against the AI Act.
  4. Plan evidence and clinical evaluation early, not after development has finished.

Where this does not apply

Not every piece of software in healthcare is a medical device. Pure documentation, billing, appointment management or general wellness applications without a medical claim usually fall outside. Systems that only store, forward or display data unchanged, without interpreting it, are mostly not medical devices either.

The reverse matters just as much: you can slide into regulation without intending to. What counts for classification is the actual claim made about the product — not the wish to avoid effort. A marketing formulation promising a medical benefit can establish an intended purpose even though the team never sought a conformity assessment. Borderline cases are also not always clear-cut; in case of doubt, the competent authority decides.

Conclusion

The intended purpose is not a formality at the end but the switch point at the start: it determines class, evidence and cost. Both errors are expensive — classifying too high slows down a harmless tool, classifying too low puts a product requiring assessment into the field without evidence. Answer the question early and deliberately, and you lose no time later.

Sources: Regulation (EU) 2017/745 (Medical Device Regulation, MDR), Article 2(1) and Annex VIII Rule 11. Medical Device Coordination Group: MDCG 2019-11 Rev.1, Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR, June 2025. Regulation (EU) 2024/1689 (AI Act).

Does this match your situation?

We begin with a process analysis and show, with evidence, what is possible.

Arrange a conversation