Short answer: the Medical Device Regulation (MDR, 2017/745) covers devices that act on or gather data from the patient directly: monitors, imaging, apps that score symptoms. The In Vitro Diagnostic Regulation (IVDR, 2017/746) covers devices that examine specimens derived from the human body (blood, urine, tissue, swabs) to provide information about a physiological or pathological state, including the software that drives an analyser or interprets its results. If your software's medical purpose is derived from laboratory or genetic data, you are probably under the IVDR, whose classification (A to D) involves notified bodies for almost every class. If it uses signals, images or reported symptoms, you are under the MDR. Software that does both is classified under each and follows the stricter path.
The dividing line
The line between the MDR and the IVDR for software is the origin of the data: software whose intended purpose includes providing information derived from in vitro examination of specimens from the human body (blood, urine, tissue, genetic material) is an IVD medical device under the IVDR; software using imaging, sensors, ECGs, questionnaires or clinical observations falls under the MDR.
MDCG 2019-11 gives the test. Software is an IVD medical device when its intended purpose includes providing information derived from in vitro examination of specimens: interpreting a genetic test, calculating a risk score from lab values, flagging a result as diagnostic of a condition, controlling an analyser. Software is a medical device under the MDR when the information comes from other sources: imaging, ECG, sensors, questionnaires, clinical observations. The specimen origin of the data, not where the software runs, decides.
Examples that fall under the IVDR: software that computes an eGFR-based kidney disease stage and labels it as such for diagnosis; a tumour-board tool that interprets sequencing variants; middleware that validates and auto-releases analyser results. Under the MDR: an app that scores a depression questionnaire; a radiology AI; a blood-pressure trend alert. Not a device under either: a record that stores and displays lab results with the laboratory's own flags and reference ranges, because it creates no new medical information.
Side by side
Side by side, the MDR (2017/745) and the IVDR (2017/746) differ in scope (devices using data from the body versus devices examining specimens), classes (I to III versus A to D), notified-body involvement (about a third of devices versus 80–90% of IVDs), evidence (clinical evaluation versus performance evaluation) and transition deadlines, while sharing ISO 13485, IEC 62304, UDI and EUDAMED.
| MDR 2017/745 | IVDR 2017/746 | |
|---|---|---|
| Scope | Devices acting on the body or using data from it | Devices examining specimens from the body, incl. software |
| Classes | I, IIa, IIb, III | A, B, C, D |
| Software rule | Annex VIII Rule 11 | Annex VIII rules by intended use; software driving or influencing a device takes its class; standalone IVD software classified by its own purpose (rules 1–7) |
| Notified body | Not for class I (except Im/Is/Ir) | Not for class A non-sterile only; B, C, D always |
| Share needing a notified body | Roughly a third of devices | Roughly 80–90% of IVDs |
| Clinical evidence | Clinical evaluation (Annex XIV) | Performance evaluation: scientific validity, analytical and clinical performance (Annex XIII) |
| Date of application | 26 May 2021 | 26 May 2022 |
| Transition for legacy devices | Extended by Reg. 2023/607 to 2027–2028 by class | Extended by Reg. 2024/1860 to Dec 2027 (D), Dec 2028 (C), Dec 2029 (B, A sterile) |
| Common ground | QMS (ISO 13485), IEC 62304, ISO 14971, UDI, EUDAMED, post-market surveillance, vigilance, PRRC | Same |
IVDR classes for software
The IVDR classifies in vitro diagnostic software by the consequence of a wrong result for the individual and for public health: class D for transfusion screening and life-threatening transmissible diseases, class C for most diagnostic, prognostic, genetic and companion tests, class B as the default, and class A for general laboratory use. Software interpreting a test inherits that test's class.
The IVDR classifies by the consequence of a wrong result for the individual and for public health. Class D: detection of transmissible agents in blood for transfusion, life-threatening diseases with high risk of propagation (HIV, hepatitis). Class C: most diagnostic and prognostic tests where an erroneous result could cause death or severe disability, including companion diagnostics, genetic testing, cancer markers, screening. Class B: the default for everything not covered elsewhere, and self-testing for non-critical parameters. Class A: reagents and instruments for general laboratory use, specimen receptacles, and software whose purpose is only general laboratory use. Software that interprets a class C test's result inherits class C.
Why the IVDR is felt as heavier
The IVDR is felt as heavier than the MDR because most in vitro diagnostics were self-certified under the previous directive, whereas under the IVDR the large majority need a notified body, fewer notified bodies are designated for IVDs, and performance evaluation demands documented scientific validity, analytical performance and clinical performance that software teams rarely produced before.
Under the previous directive, most IVDs were self-certified. Under the IVDR, the overwhelming majority need a notified body, and there are fewer notified bodies designated for IVDs than for MDR devices. Performance evaluation asks three things that software teams rarely documented before: scientific validity (does this marker relate to this condition?), analytical performance (does the software compute it correctly across inputs?) and clinical performance (does the output help in the intended population?). This is why the transition deadlines were extended twice.
Software that does both
Software that interprets both specimen data (lab values) and non-specimen data (ECGs) has two intended purposes and is classified under both the IVDR and the MDR, with conformity assessed for each, often by the same notified body under one quality system. Keeping the IVD module separable, with its own intended purpose and risk file, avoids reopening both assessments.
Modular design helps: keep the IVD module separable, with its own intended purpose, risk file and IEC 62304 class, so that a change to the MDR module does not reopen the IVD assessment.
What this means for a health record
For a health record, storing a lab report, showing values with the laboratory's units, flags and reference ranges, converting units, plotting trends and sharing the report with a clinician create no diagnostic information, so neither the IVDR nor the MDR applies. Stating what a value means for the person's health makes the software an IVD, usually class B or C.
Storing a lab report, showing the values with the laboratory's units, flags and reference ranges, converting units with a published factor, plotting a trend and sharing the report with a clinician create no new diagnostic information: no IVDR, no MDR. The moment the software states or implies what the value means for the person's health (a stage, a probability, a recommendation), it becomes IVD software and, for most analytes, class B or C. Anpheros stays on the first side of that line by design, and its lab features show what the laboratory reported, converted and ordered in time, with the laboratory's own interpretation flags; see How to read your lab results and Software as a medical device.
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
- Software as a medical device: MDR and IEC 62304 classes
- Is a health app a medical device? EU MDR Rule 11
- How to read your lab results
- FHIR DiagnosticReport explained
- Health data regulation map
Sources
- Regulation (EU) 2017/746 (IVDR), EUR-Lex
- Regulation (EU) 2017/745 (MDR), EUR-Lex
- Regulation (EU) 2024/1860 (IVDR transition extension), EUR-Lex
- Regulation (EU) 2023/607 (MDR transition extension), EUR-Lex
- MDCG 2019-11: Qualification and classification of software (MDR and IVDR)
- European Commission: in vitro diagnostic medical devices
Frequently asked questions
Is a lab unit converter an IVD?
No. Converting mg/dL to mmol/L with a published factor does not create diagnostic information; it restates the laboratory's result. Adding an interpretation of the converted value would.
My software only displays analyser results to the lab. Which regulation?
If it only displays and transmits, neither. If it validates, auto-releases or flags results against rules it applies itself, it drives the diagnostic process and falls under the IVDR, typically in the class of the tests it handles.
Which has the longer transition?
The IVDR, after Regulation 2024/1860: class D legacy devices until the end of 2027, class C until the end of 2028, class B and A sterile until the end of 2029, provided the manufacturer has applied to a notified body in time.
Does the FDA make the same distinction?
The FDA regulates IVDs as a category of medical devices under the same statute, with the Center for Devices and Radiological Health handling both. The classification logic differs in detail, but the question of whether the data comes from a specimen is relevant there too.
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
