Short answer: when software has a medical intended purpose (diagnosis, prevention, monitoring, prediction, prognosis, treatment), it is a medical device under the EU Medical Device Regulation (MDR, 2017/745) and gets a risk class: I, IIa, IIb or III, mostly by Rule 11 of Annex VIII. The class decides whether you can self-certify (class I only) or need a notified body, how deep the clinical evaluation must be and how post-market surveillance runs. Separately, the engineering standard IEC 62304 gives the software a safety class: A (no injury possible), B (non-serious injury possible) or C (death or serious injury possible), which decides how much documentation, design and testing the lifecycle requires. The two classifications are related but independent, and both are set by the harm the software could cause, not by its complexity.
Step 1: is it a device at all?
Software is a medical device under the EU MDR when its intended purpose is medical: diagnosis, prevention, monitoring, prediction, prognosis or treatment (Article 2(1)). Software that only stores, archives, communicates, displays or searches data is not a device; software that creates or modifies medical information to support a diagnostic or treatment decision is, according to MDCG 2019-11.
The MDR definition (Article 2(1)) turns on intended purpose. Software that stores, archives, communicates, displays or performs simple searches on data is not a device (MDCG 2019-11 calls these out). Software that creates or modifies medical information to support a diagnosis or a treatment decision is. A record that shows a lab value with the laboratory's reference range is not; software that tells a user the value indicates a condition, or recommends a dose, is. See Is a health app a medical device? for the qualification step in detail.
Step 2: the MDR risk class, Rule 11
MDR Rule 11 classifies medical device software by the harm a wrong decision could cause. Software providing information for diagnostic or therapeutic decisions is class IIa by default, class IIb if such decisions may cause serious deterioration or surgery, and class III if they may cause death or irreversible deterioration. Monitoring software is IIa, or IIb for vital parameters.
| Software intended to… | MDR class |
|---|---|
| provide information used to take decisions with diagnosis or therapeutic purposes (the default) | IIa |
| …where such decisions may cause death or an irreversible deterioration of health | III |
| …where such decisions may cause a serious deterioration of health or a surgical intervention | IIb |
| monitor physiological processes (the default) | IIa |
| …monitor vital physiological parameters where variations could result in immediate danger to the patient | IIb |
| anything else (software that is a device but none of the above) | I |
Rule 11 pushed most previously class I software into IIa or higher, which is the main reason the MDR was felt as a step change for digital health. MDCG 2019-11 and the IMDRF risk framework (significance of the information × state of the healthcare situation) help place borderline cases. Software that drives or influences a hardware device takes that device's class (Rule 3.3 of the implementing rules).
Consequences by class: class I is self-declared with a technical file and registration, no notified body (except Im, Is, Ir); IIa needs a notified body assessment of the quality system and a technical documentation sample; IIb the same with more documentation scrutiny; III a full technical documentation review and, where relevant, expert panel consultation. All classes need a quality management system, clinical evaluation proportionate to the class, a person responsible for regulatory compliance, UDI, registration in EUDAMED, post-market surveillance and vigilance.
Step 3: the IEC 62304 software safety class
The IEC 62304 software safety class rates medical device software by the worst harm it could contribute to, after external risk controls: class A when no injury is possible, class B when non-serious injury is possible, class C when death or serious injury is possible. The class sets how much design, verification and documentation the software lifecycle requires.
IEC 62304 (2006, amended 2015) is the harmonised standard for medical device software lifecycle processes. Its safety class comes from the worst hazardous situation the software can contribute to, after considering risk control measures external to the software:
| Class | Hazardous situation could lead to… | What the lifecycle requires |
|---|---|---|
| A | no injury or damage to health | Software development plan, requirements, release; problem resolution; configuration management |
| B | non-serious injury | A: plus architectural design, verification of integration and system tests, documented unit verification |
| C | death or serious injury | B: plus detailed design for each unit, additional architectural segregation, more rigorous verification |
Classes are assigned per software system and can be assigned per software item after decomposition, so that only the risky parts carry class C rigour; the standard explains the segregation argument this requires. ISO 14971 (risk management) feeds the classification; IEC 82304-1 adds product-level requirements for health software that runs on general-purpose platforms (phones, cloud).
How the two interact
The MDR risk class and the IEC 62304 safety class are independent: the MDR class (I to III) decides the regulatory route and notified-body involvement, while the IEC 62304 class (A to C) decides the rigour of the engineering process. A class IIa app may be 62304 class B or C depending on the harm a wrong output could cause.
MDR class is about regulatory route; IEC 62304 class is about engineering process. A class IIa app under Rule 11 might be IEC 62304 class B (wrong information could lead to a non-serious delay in care) or class C (if a wrong dose suggestion could kill). A class I device is usually 62304 class A but not necessarily. Notified bodies expect the technical file to show the 62304 class with its justification, the lifecycle documents at that level, and the link to the risk management file. Cybersecurity (MDCG 2019-16, IEC 81001-5-1) is assessed alongside.
Worked example
A worked SaMD example: a symptom-tracking app that logs, displays and shares symptoms is not a medical device. Adding a feature that scores symptoms against a validated scale and tells the user when to seek care makes it a device, MDR Rule 11 class IIa by default, with IEC 62304 class B, or class C for a cardiac use case.
A symptom-tracking app that lets users log symptoms, view trends and share them with their doctor: not a device (storage, display, communication). The same app adds a feature that scores the logged symptoms against a validated scale and tells the user when the score suggests they should seek care: now a device, Rule 11 default class IIa (information for a diagnostic decision; a wrong "no need to seek care" could delay treatment, serious but not typically irreversible, so not IIb or III unless the condition targeted makes it so). IEC 62304: a false reassurance could lead to delayed care, non-serious to serious depending on the condition, so class B, possibly C for a cardiac use case. Route: ISO 13485 QMS, notified body, clinical evaluation of the scale, usability engineering (IEC 62366-1), post-market surveillance.
The United States, briefly
In the United States the FDA regulates software as a medical device by intended use, with classes I, II and III and the 510(k), De Novo and PMA pathways. The 21st Century Cures Act excludes administrative software, general wellness products, electronic health records and certain clinical decision support from device status. The FDA recognises IEC 62304 as a consensus standard.
The FDA regulates software as a medical device under the same intended-use logic, with classes I, II and III and pathways 510(k), De Novo and PMA. The 21st Century Cures Act (section 3060) removed several categories from device status: administrative software, general wellness, electronic health records, and clinical decision support that lets the clinician independently review the basis of the recommendation (the FDA's 2022 CDS guidance interprets this narrowly). The FDA recognises IEC 62304 as a consensus standard and, since 2023, requires cybersecurity documentation for "cyber devices". ISO 13485 became the basis of the US quality system regulation (QMSR) in 2026.
In Anpheros
Anpheros Daily stores, displays and shares; it does not score, interpret or recommend, and its intended purpose says so. It is therefore not a medical device under Rule 11 or the Cures Act exclusions, and the team applies ISO 27001-style security and documented software practice without the device route. If a feature with a medical purpose were ever added, it would be classified under Rule 11 and developed under IEC 62304 before release. See Health transparency.
This page explains regulation for product and engineering teams. It is not legal advice; the texts linked under Sources are the authority, and your data protection officer, notified body or counsel decides for your case. Last reviewed: October 2026.
Related pages
- Is a health app a medical device? EU MDR Rule 11
- MDR vs IVDR
- CDS Hooks explained
- Health data regulation map
- The EU AI Act and health AI
Sources
- Regulation (EU) 2017/745 (MDR), Annex VIII, EUR-Lex
- MDCG 2019-11: Qualification and classification of software
- IEC 62304:2006+AMD1:2015, Medical device software lifecycle processes
- IEC 82304-1:2016, Health software product safety
- FDA: Clinical Decision Support Software guidance (2022)
- FDA: Software as a Medical Device
Frequently asked questions
Can software be class I under the MDR?
Yes, but rarely: only software with a medical purpose that neither informs diagnostic or therapeutic decisions nor monitors physiological processes. Most apps that qualify as devices land in IIa.
Does a class IIa device need clinical trials?
It needs a clinical evaluation, which can rely on literature, equivalence and performance data; a clinical investigation is required when existing evidence is insufficient. Software that claims a diagnostic performance usually needs its own performance study.
Is IEC 62304 mandatory?
It is a harmonised standard, so following it is the presumption of conformity with the MDR's software requirements (Annex I, 17). You may use another approach, but you then have to prove equivalence, which nobody does in practice.
What about AI features?
The same rules apply, plus the EU AI Act: a device with a notified body assessment is a high-risk AI system under Annex I, with requirements on data, logging, transparency and human oversight assessed together with the MDR.
Try it free in the sandbox
Your first FHIR call in 5 minutes. An HL7 FHIR R4 API with the patient's consent built in: try it in the sandbox, then connect your own app or clinic system.
Free · 30 synthetic patients · no card
Anpheros builds a medical record that the patient controls and can share with any clinic, on an HL7 FHIR R4 platform, based in the EU. These guides help you understand and organise your health; they do not replace your doctor.
About Anpheros →
AnpherosThe more you log, the clearer your record
Your health history in one place, under your control.
Free · Works in your browser · No card
