Short answer
Software becomes a medical device under EU law when its manufacturer intends it to perform a specific medical purpose for an individual or group of patients. Relevant purposes include diagnosis, prevention, monitoring, prediction, prognosis or treatment of disease. It does not matter whether the software uses artificial intelligence, runs in the cloud or acts directly on the body. What matters is the intended purpose and what the software actually does with data.
A hospital setting or health-related subject is not enough. Software limited to administration, communication, storage, lossless compression or simple retrieval of information will not ordinarily qualify. Software that analyses patient-specific data and produces a diagnostic, prognostic or therapeutic recommendation ordinarily will. If the output depends principally on examining a specimen from the human body, the In Vitro Diagnostic Medical Devices Regulation (IVDR), rather than the Medical Devices Regulation (MDR), may govern it.
The manufacturer must then determine the class, validate the software, generate evidence, compile technical documentation and follow the correct conformity-assessment route. Most decision-support medical software is at least MDR class IIa and requires a notified body. The EU AI Act adds a layer but does not decide device status or class.
Start with the intended purpose, not the technology
Article 2(1) MDR expressly includes software in the definition of a medical device where the manufacturer intends it for one or more specified medical purposes:
“diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease”. —
Intended purpose comes from labels, instructions, promotional and sales statements, and clinical evaluation. A disclaimer cannot neutralise claims that present diagnosis or treatment functions. Define the population, user, indication, inputs, output and clinical role.
The Court of Justice reached the same basic distinction under the MDR's predecessor directive. In Brain Products, C-219/11, an object used to investigate a physiological process qualified only if the manufacturer intended a medical purpose. General use in healthcare was insufficient. In Snitem and Philips France, C-329/16, prescription software used patient-specific data to detect contraindications, drug interactions and excessive doses. The Court held:
It was a medical device “even if that software does not act directly in or on the human body”. —
Those judgments interpreted Directive 93/42/EEC, not the MDR, but their reasoning about specific medical purpose, patient-specific processing and lack of direct bodily action remains materially relevant to the MDR definition.
Non-binding MDCG 2019-11 rev.1 offers a useful framework. Storage, archival, communication, lossless compression and simple search are ordinarily outside device software. Patient-specific risk scores, lesion identification, treatment recommendations and significant alerts may qualify; scheduling and billing ordinarily do not.
A product can contain regulated and unregulated modules. Their boundaries and interfaces should be identified; a general platform does not escape regulation if one module performs the medical function.
Decide whether the MDR or IVDR applies
The MDR is the usual route for software using clinical observations, images or symptoms to diagnose, monitor, predict or treat. The IVDR applies where software examines human specimens to provide information about disease, predisposition, treatment response or therapeutic measures. Software interpreting genetic, biomarker or laboratory-assay results may therefore be an in vitro diagnostic medical device.
Independent software is classified in its own right. Software that drives or influences a device takes that device's class. A system may require separation where functions fall under the MDR, IVDR or neither.
MDR software classification is driven by possible harm
Apply MDR classification to the documented purpose and foreseeable consequences of a wrong, delayed or missing output. Rule 11 governs most decision and monitoring software:
“Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa”, subject to class IIb or III escalation where the decision's possible impact is more serious. —
The resulting structure is:
- class III where the decision may cause death or irreversible deterioration of health;
- class IIb where it may cause serious deterioration or require surgical intervention;
- class IIa for other diagnostic or therapeutic decision information;
- class IIb for monitoring vital physiological parameters where variations could create immediate danger;
- class IIa for other monitoring of physiological processes; and
- class I for other software, unless another rule applies.
Keeping a clinician “in the loop” does not itself determine class. Assess the output's significance, the clinical situation, whether an error can be detected in time, and resulting harm. Ordinary class I devices may generally be self-declared; classes IIa, IIb and III require notified-body involvement. Some special class I characteristics also require limited involvement.
IVDR software follows the IVDR's separate Rules 1–7 and classes A to D, based on the information supplied, intended purpose and consequences of an incorrect result for the individual and public health. It is not classified under MDR Rule 11. Class B, C and D devices require notified-body assessment; non-sterile class A devices are generally self-declared.
Evidence must connect technical performance to clinical use
For MDR software, conformity with the general safety and performance requirements must rest on clinical data providing sufficient clinical evidence. Article 61 requires the manufacturer to specify and justify the necessary evidence level in light of the device and intended purpose. The evidence package should normally establish:
- a valid clinical association between the software's output and the targeted condition or clinical state;
- technical performance, including accuracy, reliability, reproducibility, data integrity, cybersecurity, interoperability, usability and performance across intended environments and populations;
- clinical performance: whether use as intended achieves the claimed patient or patient-management benefit;
- risk controls for incorrect, biased, delayed, unavailable or misunderstood outputs, including human factors and foreseeable misuse; and
- a plan for post-market surveillance and post-market clinical follow-up that keeps the evaluation current.
Study design depends on novelty, risk, claims, literature, comparators and genuine equivalence. Bench testing or retrospective model accuracy alone may not establish clinical performance. A clinical investigation is required where existing evidence cannot demonstrate conformity. Changes to inputs, model, population, workflow or purpose must be assessed for their effect on evidence and certification.
For IVDR software, Article 56 requires a continuous, methodologically sound performance evaluation. It must demonstrate scientific validity, analytical performance and clinical performance:
“The data and conclusions drawn from the assessment of those elements shall constitute the clinical evidence for the device.” —
The performance evaluation report belongs in the technical documentation and must be updated through post-market performance follow-up and surveillance. Non-binding MDCG 2020-1 applies these concepts to software but cannot replace the Regulations or a device-specific assessment.
What conformity assessment requires
Before CE marking, the manufacturer needs qualification and classification records, risk management, a quality system, software-lifecycle verification, clinical or performance evaluation, technical documentation, labelling, surveillance and vigilance. Any notified body must have the relevant designation. Certification does not end incident reporting, corrective action or continuing evidence generation.
The AI Act is an additional layer, with later timing
Article 6(1) of Regulation 2024/1689 covers an AI system that is a safety component of, or is itself, a listed product requiring third-party assessment. The list includes MDR and IVDR devices. This commonly captures MDR IIa–III and IVDR B–D AI devices, but not every health-related or self-declared device.
Regulation 2026/1744, the Digital Omnibus on AI, changed that framework from 27 July 2026. A safety component now has an intended safety function or is one whose failure or malfunction endangers health, safety or property. Software used only for non-safety assistance, optimisation, efficiency, automation, convenience or quality control is excluded unless its failure would create that danger.
The AI Act's general application date remains 2 August 2026, two days after this review. The Omnibus postponed Chapter III Sections 1–3 for Article 6(1) product-route systems to 2 August 2028. Revised Article 43 keeps the applicable MDR or IVDR conformity route and integrates the AI requirements into that assessment when they apply; high-risk status alone does not force a different sectoral route. The Commission may later limit overlapping AI requirements where sectoral law provides equivalent or higher protection without reducing the overall level of protection.
The non-binding AIB 2025-1/MDCG 2025-6 FAQ predates the Omnibus, which controls amended definitions, procedures and dates. AI status does not replace the medical-purpose, device-regime and harm analysis.
Conclusion
The boundary is between software with a manufacturer-defined medical purpose and general information or administration. Manufacturers must define module boundaries, classify by possible harm, validate technical and clinical performance, document risk, involve a notified body where required and keep evidence current. The AI Act adds requirements on its own timetable; it does not dilute MDR or IVDR duties.
Sources
This article provides general legal information, not advice for a specific matter. Laws, facts and procedural deadlines may change the result. Follow the linked primary sources and obtain local advice before acting.