Is Your Health App a Medical Device? A Simple Guide to Software under EU MDR

A software application planned for healthcare domain in EU (European Union) countries comes under the same EU regulation sets out for medicinal physical products. However, not every software used in healthcare falls under MDR.

In this post, we will develop a basic understanding around fundamentals of EU MDR. In particular, we will cover the following topics.

What is EU MDR?
Which software applications fall under its scope?
How they are classified and what does it entail to classified under those categories?
Who will provide certification over compliance?

What is EU MDR?

EU MDR is a legally binding regulation on medical devices (EU 2017/745) which must be fulfilled by each medical device manufacturer. The primary aim of this regulation is to ensure a smooth functioning of the market, and sets standard for quality and patients’ safety.

In simple terms, this regulation sets out rules each business, manufacturing products for medical purposes, must comply to minimize risks associated with the usage of the product in order to ensure patients’ safety.

Let’s imagine a scenario with a monitoring device for heart health (e.g., echocardiograph). Here, the output of the machine used by a health professional in decision-making on the diagnosis of a patient. Here, an errouneous results from the machine may lead the professional to a wrong judgement (e.g., everything seems fine) which can delays in treatment resulting in deterioration of the patient’s health.

EU MDR aim is to make businesses to be thoroughly and systematically in assessing the risks associated with their product’s usage, and planning mitigation strategies along with preparing the clinical evidence on ‘product does what it aims to do’. In that way, risk assessment and mitigation becomes a part of product development lifecycle not a afterthought after a serious incident.

What qualifies a software application for EU MDR?

A software application qualified as a medical device, is suject to MDR regulation. What makes a software medical device depends on the “intended use” of that software.

This “intended use” is legally determined based on how the software is marketed, advertised, and put in labels and IFU (Instructions for Use).

EU MDR has a specific section (Rule 11) which focuses on Software as a Medical Device. Guidelines from Medical Device Coordination Group (MDCG) state that a software that is intended for human beings for medical purpose of

diagnosis, prevention, monitoring, prediction, prognosis, disease, treatment or alleviation of disease
diagnosis, monitoring, treatment, alleviation of, or compensation for, an injury or disability

There are four categories (I, IIa, IIb, III) from lower to higher risk. Each category has its own requirement to be fulfilled.

Category I: All softwares that do not fall in IIa, IIb and III.
Category IIa: Softwares intended with medical purpose of supporting a human beign in deciding for diagnosis or therapeutic. Software which are intended for monitoring vital physiological parameters such as heart rate falls under the scope of class IIa.
Category IIb: If the information from the software could lead to serious deterioration of a patinet’s heath or could impact surgical intervention then such software would go under class IIb. Moniotring software (vital physiological measurements) will fall under class IIb if variation in measurements could result in immediate danger to the patient
Category III: Softwares used for diagnosis or treatment in cases where incorrect information from the software could lead to critical incidents such as death.

How a software is qualified as MDSW and classified through risk-based assessment?

The first step is to determine whether the software application in question qualifies as MDSW (Medical Device Software). And, here the most crucial information is the software intended purpose. If the software is meant to be used for medical purposes then it is MDSW.

However, here are some exceptions to this rule. Softwares which are simply used for data storage, displaying, transferring or archival purposes are not qualified as medical devices.

Figure 1 shows a simplified version of MDSW classification process.

flowchart TD
    A{"Is the software meant to diagnose,<br/>treat, monitor or predict<br/>a health condition?"}
    A -->|No| N["Not a medical device"]
    A -->|Yes| B{"What does it do?"}

    B -->|"Helps make decisions<br/>about diagnosis or treatment"| C{"If it gets it wrong,<br/>what's the worst outcome?"}
    C -->|"Death or permanent harm"| III["Class III<br/>Highest risk"]
    C -->|"Serious harm or<br/>need for surgery"| IIb1["Class IIb<br/>Medium-high risk"]
    C -->|"Less serious harm"| IIa1["Class IIa<br/>Medium-low risk"]

    B -->|"Monitors body functions"| D{"Could a change put the<br/>patient in immediate danger?"}
    D -->|"Yes, e.g. heart rhythm<br/>in intensive care"| IIb2["Class IIb<br/>Medium-high risk"]
    D -->|No| IIa2["Class IIa<br/>Medium-low risk"]

    B -->|"Anything else"| I["Class I<br/>Lowest risk"]

    classDef none fill:#eeeeee,stroke:#999,color:#333
    classDef low fill:#d8f0dc,stroke:#4a9a5a,color:#1d4426
    classDef midlow fill:#fff3c4,stroke:#c9a227,color:#5a4500
    classDef midhigh fill:#ffd9b3,stroke:#d9822b,color:#5c3000
    classDef high fill:#f8c4c4,stroke:#c94a4a,color:#5c1414
    classDef question fill:#e8f0fb,stroke:#5b7fb8,color:#1c2f4f

    class N none
    class I low
    class IIa1,IIa2 midlow
    class IIb1,IIb2 midhigh
    class III high
    class A,B,C,D question

Figure 1: How software is classified as a medical device under the EU MDR (Rule 11)

References

Regulation (EU) 2017/745 on medical devices. (2017). Official Journal of the European Union, L 117, 1–175. http://data.europa.eu/eli/reg/2017/745/oj
SanoLabs Editorial. (2026, May 16). Wellness app vs medical device under EU MDR: The line that matters. SanoLabs. https://www.sanolabs.eu/en/blog/wellness-app-vs-medical-device-eu-mdr
Medical Device Coordination Group. (2025). Guidance on qualification and classification of software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR (MDCG 2019-11 Rev.1). European Commission. https://health.ec.europa.eu/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b_en?filename=mdcg_2019_11_en.pdf
Medical Device Coordination Group. (2025). Guidance on the safe making available of medical device software (MDSW) apps on online platforms (MDCG 2025-4). European Commission. https://health.ec.europa.eu/document/download/ec9b0f40-7f82-43a7-b833-ebd45b772eae_en?filename=mdcg_2025-4_en.pdf
Aura Health. (2026, September 2). Choosing a notified body for Software as a Medical Device. https://aurahealth.ch/notified-body-for-software-as-a-medical-device/
Aura Health. (2026b, July 27). How to structure a SaMD software architecture for FDA pre-submission. https://aurahealth.ch/how-to-structure-a-samd-software-architecture/