When Software Becomes a Medical Device: MDR & AI Act 2026 Guide

The essentials in 30 seconds

Introduction

When a hospital decides to upgrade its electronic patient record (EPR) system, the procurement questionnaire often asks a deceptively simple question: “Is the software a medical device?” The answer determines whether the vendor must provide a CE mark, a technical file, and a post‑market surveillance plan under the European Medical Devices Regulation (MDR) ¹. In parallel, the EU AI Act, which entered force in 2024, adds a second layer of obligations for any AI‑driven feature that influences clinical decisions.

Galeon’s intelligent DPI has been built hand‑in‑hand with clinicians since 2016, now operating in 19 hospitals (including two university medical centres) and handling over three million patient dossiers. The platform’s data model is validated by caregivers, ready for research, and complies with the HDS 2024 certification – the French benchmark for health‑data hosting aligned with ISO 27001:2022 ². As a result, Galeon already demonstrates how a modern EHR can stay within the “non‑device” scope while still offering AI‑enhanced decision support.

“The intended medical purpose is the sole determinant of whether software falls under MDR,” states the European Commission’s guidance on software‑based medical devices ³. This article clarifies that criterion, walks you through classification, maps the overlap with the AI Act, and provides a checklist of questions to ask any software supplier before signing a contract.

Does the intended medical purpose alone determine if software is a medical device?

Yes. Under MDR Article 2(1), a “medical device” is any instrument or software whose intended purpose is to diagnose, prevent, monitor, treat or alleviate disease.

Therefore, a module that merely stores or transmits patient data – even if it is hosted on a secure HDS‑certified server – is not a medical device. Conversely, an algorithm that predicts sepsis risk and triggers an alert for clinicians is a software medical device because its purpose is clinical decision‑support.

For CIOs, the practical takeaway is to document the intended use in the procurement file; the regulator will look at that description first.

What are the MDR classification classes for medical software?

Classes I, IIa, IIb, and III. The classification is based on the risk associated with the software’s impact on patient health.

• Class I (lowest risk): Non‑invasive data management tools, e.g., simple scheduling modules.
• Class IIa: Software that provides information that influences clinical decision‑making but does not autonomously act, such as risk calculators.
• Class IIb: Software that drives therapeutic interventions or provides automated dosing recommendations.
• Class III (highest risk): Life‑supporting or life‑sustaining software, e.g., closed‑loop insulin pumps.

Each class triggers a specific conformity assessment pathway (self‑declaration for Class I, notified‑body involvement from Class IIa upwards) ⁴. Hospital IT leaders must verify that the vendor’s technical file matches the declared class.

Where does an EHR stop and a medical device begin?

The boundary is the moment the software performs autonomous clinical interpretation. An EHR that displays lab results is still a data repository (non‑device). Add a rule‑engine that flags abnormal values and suggests a treatment plan, and you cross into Class IIa territory.

Galeon’s DPI illustrates this split: the core record‑keeping layer is an HDS‑compliant data store, while the AI‑powered predictive module – built on Swarm Learning® that never moves data off‑site – is separately CE‑marked as Class IIa.

Clinical directors should request a clear mapping of each functional module to its MDR classification.

How do MDR and the EU AI Act overlap for hospital software?

Both regimes apply when AI has a medical purpose and is classified as high‑risk under the AI Act. The AI Act defines “high‑risk AI” as systems used for medical diagnosis, treatment or triage – the very same functions that MDR treats as medical devices.

Key points of intersection:

• Conformity assessment: MDR requires CE marking; the AI Act adds a conformity‑assessment dossier for high‑risk AI, including data‑governance and transparency measures.
• Post‑market monitoring: Both regulations demand vigilance reporting, but the AI Act introduces a “systemic risk” monitoring component for AI models that evolve after deployment.
• Documentation: The AI Act requires an “AI‑system logbook” alongside the MDR technical file – a natural fit for the audit trails already generated by Swarm Learning®.

Importantly, not every AI feature is high‑risk. A dashboard that visualises population‑level trends is regulated only by MDR (if it has a medical purpose) and not by the AI Act’s high‑risk provisions ⁵.

What questions should a hospital ask a software vendor before signing?

Focus on intended use, classification, and compliance evidence.

• What is the declared medical purpose of each module?
• Which MDR class does the software belong to, and can you provide the CE certificate?
• Is the AI component considered high‑risk under the AI Act? If so, can you share the AI‑system logbook?
• How do you ensure data never leaves the hospital (e.g., Swarm Learning® architecture)?
• Is the hosting environment HDS‑certified 2024?
• What is your post‑market surveillance plan and how will you handle updates?
• Can you supply a mapping of each functional block to its regulatory status?

Answering these questions protects the hospital from non‑compliance penalties and ensures that the technology aligns with clinical workflows.

How does the traditional approach compare with Galeon’s smart EHR?

Limits and challenges to be aware of

• Regulatory lag: MDR and the AI Act are evolving; reinterpretations can shift a Class IIa software to Class IIb after a software update.
• Resource intensity of technical files: Maintaining a CE‑technical file for every AI module requires dedicated documentation staff and can slow down innovation.
• Interoperability constraints: While Swarm Learning® preserves data sovereignty, integrating with legacy PACS or lab systems may need custom adapters.
• Post‑market surveillance burden: Hospitals must collect and report real‑world performance data, which demands robust monitoring infrastructure.
• Talent gap: Clinical staff must understand the distinction between data‑only functions and regulated decision‑support to avoid misuse.

FAQ

Do I need CE marking for every module of my EHR?
Only the modules whose intended purpose is clinical need a CE mark; pure administrative tools do not.

Can a software classified as Class I be sold without a notified body?
Yes, Class I devices rely on a self‑declaration of conformity, but you must still keep a technical file.

Is my AI‑driven triage tool automatically “high‑risk” under the AI Act?
If it influences patient triage decisions, it is high‑risk and must meet the AI Act’s conformity requirements.

How does Swarm Learning® affect GDPR compliance?
Since the data never leaves the hospital’s firewall, GDPR’s cross‑border transfer rules are not triggered; you still need a lawful basis for processing.

What happens if a CE‑marked AI model is updated?
Minor updates may be covered by the original conformity assessment; major changes that affect risk class require a new CE declaration.

In summary

The decisive factor for whether hospital software is a “software medical device” is its intended medical purpose, as defined by MDR. Once that purpose is confirmed, the appropriate risk class (I‑III) dictates the depth of the conformity assessment, the need for a CE mark, and the post‑market surveillance obligations. The EU AI Act adds a parallel set of duties for high‑risk AI systems, most of which overlap with MDR’s requirements, creating a unified compliance landscape that can be navigated with a single, well‑structured technical dossier.

Galeon’s intelligent DPI demonstrates that a modern EHR can stay within the non‑device zone for its core data repository while offering AI‑enhanced, CE‑marked decision‑support modules that respect data sovereignty through Swarm Learning®. By asking the right questions up‑front – purpose, class, CE evidence, AI‑Act status, and hosting certification – hospitals can mitigate compliance risk, protect patient safety, and still reap the benefits of AI‑driven care.

Discover how a smart EHR can streamline compliance and innovation

Sources

• EU Medical Devices Regulation (MDR) 2017/745
• EU Artificial Intelligence Act (Proposal) 2021/0806
• CNIL – HDS certification 2024 (aligned with ISO 27001:2022)
• French Ministry of Health – Health Data Statistics 2025
• Galeon – HDS Certification in 2026
• Galeon – Smart EHR vs Traditional EHR

‍