In Brief
Software is not automatically a medical device simply because it processes health data, uses artificial intelligence, or is used by a physician.
In Europe, its qualification depends in particular on its intended purpose, its functions, and the manner in which the information it produces is intended to be used.
The first question is therefore not:
"Does this software contain AI?"
but:
"What exactly is its intended purpose?"
This distinction is essential, because when software is qualified as a medical device, the European Medical Devices Regulation (MDR) — or, depending on its purpose, the IVDR — may entail substantial requirements in terms of classification, risk management, assessment, documentation, cybersecurity, surveillance, and compliance.
Key Points
Software used in healthcare ≠ automatically a medical device.
AI ≠ automatically a medical device.
Health data ≠ automatically a medical device.
The intended purpose is a central element of qualification.
A distinction must be made between qualification and classification.
Software providing information used for diagnostic or therapeutic decisions may fall under Rule 11 of the MDR.
Validation of the result by a physician does not, on its own, exclude qualification as a medical device.
MDR/IVDR analysis and AI Act analysis are distinct, even when they overlap.
1. Medical Software Is Not Simply Software Used by a Physician
Software may be used daily in a practice, clinic, or hospital without being a medical device.
Regulation (EU) 2017/745 on medical devices — the MDR — draws a fundamental distinction.
Recital 19 states in substance that software specifically intended by its manufacturer for one or more medical purposes falling within the definition of a medical device may itself constitute a medical device.
Conversely, general-purpose software does not become a medical device simply because it is used in a healthcare environment.
The same applies to software intended for lifestyle or wellness purposes.
This distinction is critical.
A hospital uses:
accounting software;
messaging systems;
scheduling tools;
human resources management tools;
document management software;
video conferencing solutions;
archiving tools;
billing systems.
The medical context in which this software is used does not in itself confer a medical purpose on it.
The place of use does not, on its own, determine the regulatory qualification of the software.
2. The Fundamental Question: What Is the Intended Purpose?
Qualification begins with an analysis of the intended purpose.
It is necessary to determine what the manufacturer actually intends the software to accomplish.
The question must be formulated precisely:
What function is this software intended to perform for a patient, a professional, or a medical decision?
The following must be examined in particular:
the features of the product;
the information it receives;
the processing it performs;
the results it produces;
how those results are intended to be used;
the users for whom it is intended;
the manufacturer's claims;
its documentation;
its instructions for use;
its functional environment.
A marketing description is therefore not sufficient to resolve the qualification question.
It is necessary to understand what the system actually does and what purpose it is intended to serve.
3. Qualification and Classification: Two Different Questions
This is probably one of the most important distinctions in the entire regulation of medical software.
First question
Is the software a medical device?
This is qualification.
Second question
If it is a medical device, which class does it belong to?
This is classification.
It is dangerous to begin directly by asking:
"Is this a Class I or IIa device?"
without having first established that the software actually falls within the scope of the MDR.
The correct logic is therefore:
Software
↓
Intended purpose
↓
Medical purpose?
↓
Possible qualification as a medical device
↓
Classification
↓
Applicable regulatory requirements
4. SaMD and MDSW: What Are We Talking About?
Two expressions are frequently encountered.
SaMD — Software as a Medical Device
The term Software as a Medical Device (SaMD) was notably structured at the international level by the International Medical Device Regulators Forum — IMDRF.
It refers to software intended to be used for one or more medical purposes, performing those purposes without being part of a hardware medical device.
This terminology is particularly useful when working in an international environment.
MDSW — Medical Device Software
In the European regulatory environment, the Medical Device Coordination Group documentation commonly uses the concept of:
Medical Device Software — MDSW.
The guidance document MDCG 2019-11 rev.1, updated in June 2025, is today an essential document for analysing the qualification and classification of software under the MDR and IVDR.
However, these terms should not distract from the fundamental question:
Does the software genuinely have a purpose that brings it within the scope of a medical device?
5. The Decision Tree
SOFTWARE
↓
What is its intended purpose?
↓
Relevant medical purpose?
NO → Not a medical device on that basis alone
YES → MDR or IVDR analysis required
↓
What does the software actually do?
Administrative function → Not a medical device
Information for clinical decision → Qualification required
Monitoring / other medical function → Qualification required
↓
Classification
↓
Applicable requirements
This tree is an orientation tool. It does not replace a complete regulatory analysis of a specific product.
6. Practical Cases: Scheduling, Billing, and Transcription
Case 1 — Intelligent Medical Scheduling
An artificial intelligence optimises a clinic's appointment slots based on:
availability;
cancellations;
average consultation durations;
available resources.
It produces no diagnostic or therapeutic information.
Conclusion
Not automatically a medical device.
The fact that the scheduling tool is used by physicians or contains certain appointment-related information does not in itself create a medical purpose within the meaning of the MDR.
Case 2 — Medical Billing Software
The software generates invoices, tracks payments, and organises administrative items.
Conclusion
Not a medical device on that basis alone.
The function is administrative.
Case 3 — Automatic Consultation Transcription
The system automatically converts a physician-patient conversation into text.
Conclusion
Not automatically a medical device.
Its exact functions must be examined.
A system performing only transcription must not automatically be equated with a system that interprets data to produce a medical recommendation.
However, if additional features are added, the analysis may change.
7. The Much More Subtle Case of the Automatic Medical Summary
Consider now a system that:
1. listens to or receives a consultation transcript;
2. identifies certain pieces of information;
3. organises them;
4. proposes a structured summary to the physician.
It would be imprudent to answer:
"This is a medical device."
But it would be equally imprudent to answer:
"This is never a medical device."
It is necessary to determine in particular:
What exactly does the system produce?
and above all:
What is the produced information intended for?
The difference between:
"The patient reports knee pain for the past three weeks."
and:
"Presentation compatible with a condition requiring such-and-such examination."
is regulatorily considerable.
The first result may fall under a documentation function.
The second may contribute to a clinical decision.
The boundary therefore does not simply lie between "AI" and "not AI".
It lies in the function and purpose of the system.
8. Digital Consent
A system presents to the patient:
an information document;
records their reading of it;
allows them to ask questions;
collects a decision;
performs authentication;
collects a signature;
timestamps events;
ensures the integrity of the document.
The fact that this process relates to a medical act does not automatically mean that the software itself is a medical device.
A distinction must be drawn between:
the management of a medico-administrative and evidentiary process
and:
the production of information that itself has a diagnostic or therapeutic purpose.
This distinction is particularly important in digital patient pathway platforms.
9. Patient Chatbot: The Word "Chatbot" Allows No Conclusion
Two interfaces may look almost identical while having radically different regulatory statuses.
Chatbot A
It responds:
"Your appointment is scheduled for Tuesday at 2 p.m."
Chatbot B
It analyses the patient's symptoms and produces information intended to guide a diagnostic or therapeutic decision.
The interfaces may be almost identical.
But their intended purposes are different.
Saying:
"It's just a chatbot."
therefore has practically no value for regulatory qualification.
10. Medical Imaging Analysis
Consider an algorithm intended to analyse a radiological image to identify an anomaly that may be used by the radiologist in their diagnosis.
We are in a situation that much more clearly requires analysis as a medical device.
The system no longer merely:
archives the image;
transmits it;
or displays it.
It produces information intended to contribute to a medical purpose.
It is then necessary to determine the appropriate qualification and classification.
11. Therapeutic Recommendation
Consider now software that analyses:
clinical data;
certain biological results;
current treatments;
various medical parameters;
and produces information intended to guide the therapeutic choice.
We enter directly into one of the areas where Rule 11 of the MDR becomes particularly important.
12. Rule 11 of the MDR
Rule 11 is one of the fundamental texts for the classification of medical software under the MDR.
It provides in particular that software intended to provide information used to make decisions for therapeutic or diagnostic purposes falls in principle under:
Class IIa.
However, this classification may increase depending on the potential consequences of the decision.
Death or irreversible deterioration of health
→ Class III
Serious deterioration of health or surgical intervention
→ Class IIb
In other situations covered by this part of the rule:
→ Class IIa
The rule also covers software intended to monitor physiological processes.
Such software falls in principle under:
→ Class IIa
but when intended to monitor vital physiological parameters whose variations could present an immediate danger to the patient:
→ Class IIb
Finally, the rule provides that other software falling within the MDR is classified as:
→ Class I
Classification therefore depends not only on the function of the software, but also on the level of consequence associated with the information or process concerned.
13. A Clinical Score May Be Far More Regulated Than It Appears
Imagine software producing a score.
At first glance:
"It's just a score."
But this formulation says practically nothing.
The following questions must be asked:
A score of what?
Produced from what information?
For what purpose?
Intended to be used by whom?
To make what decision?
With what potential consequences?
A score intended solely to organise certain administrative priorities does not necessarily have the same status as a score intended to identify a clinical risk used in a diagnostic or therapeutic decision.
The format of the result does not determine its regulatory status. Its purpose does.
14. The Seven False Criteria
"It processes health data, therefore it is a medical device."
No.
A system may process health data for many purposes without necessarily being a medical device.
Data protection and medical device regulation are two separate analyses.
"It is used in a hospital, therefore it is a medical device."
No.
The MDR distinguishes between software with a medical purpose and general-purpose software simply used in a healthcare environment.
"It uses artificial intelligence, therefore it is a medical device."
No.
The use of AI is not sufficient.
Qualification under the MDR/IVDR and qualification under the AI Act must be analysed separately.
"It is used by a physician, therefore it is a medical device."
No.
The professional status of the user is not sufficient to qualify the software.
"It produces a medical PDF, therefore it is a medical device."
Not necessarily.
Producing or structuring a document is not automatically equivalent to producing information with a medical purpose within the regulatory meaning.
"The physician validates the result, therefore it is not a medical device."
This reasoning is not sufficient.
Human intervention must be taken into account in the analysis of the system, but the presence of a physician at the end of the chain does not automatically neutralise the medical purpose of the software.
"We write 'support tool' in the T&Cs, therefore the MDR does not apply."
This would be a dangerously simplistic approach.
The intended purpose must be assessed in light of all relevant elements relating to the product and its intended use.
An isolated contractual clause must not be used as an artificial regulatory circumvention mechanism.
15. The Case of Artificial Intelligence
Suppose now that the software qualified as a medical device also uses artificial intelligence.
A second analysis begins.
It is then necessary to examine its status under:
Regulation (EU) 2024/1689 — the AI Act.
Two lines of reasoning must therefore be kept separate:
SOFTWARE
↓
MDR / IVDR — Medical device? → Classification
AI ACT — AI system? → Regulatory classification
↓
Articulation of obligations
It is precisely this articulation that is the subject of the FAQ MDCG 2025-6 published in June 2025.
Medical AI may therefore face several regulatory layers simultaneously.
16. Beware of Software Evolution
Regulatory qualification must not be treated as a snapshot taken only once at product launch.
Software evolves.
New features appear.
A tool initially intended to:
"transcribe a consultation"
may progressively become one that:
"structures information"
then:
"detects anomalies"
then:
"suggests examinations"
then:
"recommends a course of treatment."
At each significant evolution, the intended purpose, functions, performance, and risks must be reassessed against the applicable framework.
An additional feature may therefore profoundly alter the regulatory profile of a product.
17. The Elysium MedTech Eight-Question Test
Before concluding that software is — or is not — a medical device, at least eight questions should be documented.
1. What is its intended purpose?
Describe precisely what the system is intended to accomplish.
2. Is there a medical purpose falling within the regulatory framework?
Do not infer this purpose solely from the hospital context.
3. What does the software actually do with the data?
Storage? Transmission? Organisation? Calculation? Analysis? Interpretation? Prediction? Recommendation?
4. What information does it produce?
A document? An alert? A score? A detection? A recommendation? A prediction?
5. Is this information intended for a diagnostic or therapeutic decision?
If so, Rule 11 must be examined in particular.
6. Does it monitor a physiological process?
And if so, vital physiological parameters?
7. What would the consequences of erroneous information be?
This question becomes decisive for classification.
8. What regulation and classification follow?
MDR? IVDR? AI Act? Several frameworks simultaneously?
18. The Trap of the "Regulatory Disclaimer"
A MedTech company should never build its compliance model around a phrase such as:
"This tool does not replace the advice of a physician."
This statement may be relevant in certain contexts.
But it does not in itself constitute a regulatory qualification strategy.
Similarly, writing:
"For informational purposes only"
does not automatically transform a system that in practice produces medical information into administrative software.
Regulatory governance must begin with the actual functions and purpose of the product, then be coherently reflected in:
specifications;
documentation;
the interface;
commercial communications;
instructions;
risk management;
validation;
surveillance.
19. Qualification by Design
The right question should therefore not arise six months after development:
"Is our software a medical device?"
It should arise from the outset of design.
PRODUCT IDEA
↓
INTENDED PURPOSE
↓
FUNCTIONS
↓
QUALIFICATION
↓
CLASSIFICATION
↓
RISKS
↓
ARCHITECTURE
↓
VALIDATION
↓
DOCUMENTATION
↓
MARKET LAUNCH / DEPLOYMENT
↓
SURVEILLANCE
This approach avoids the late discovery that a core feature modifies the qualification of the product.
Above all, it allows regulation to become a component of the product's architecture rather than a legal corrective added at the end of development.
20. What to Remember
Software does not become a medical device because it:
uses artificial intelligence;
contains health data;
is installed in a clinic;
is used by a physician;
produces a medical document.
Qualification rests on a deeper regulatory analysis.
It is necessary to understand:
its intended purpose
↓
its functions
↓
the information it produces
↓
the intended use of that information
↓
its potential influence on a medical decision
↓
the potential consequences
Only then can the regulatory framework be correctly determined and, when the software constitutes a medical device, its classification.
Software does not become medical because it enters a hospital. It enters the scope of the medical device when its intended purpose and functions meet the applicable regulatory criteria.
Main Regulatory Sources
European Union — Regulation (EU) 2017/745 on medical devices (MDR) — in particular the definition of medical device, recital 19 and Annex VIII, Rule 11.
European Commission / Medical Device Coordination Group — MDCG 2019-11 rev.1, June 2025 — *Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR.*
European Commission / MDCG — MDCG 2025-6, June 2025 — *FAQ on Interplay between the Medical Devices Regulation (MDR) & In Vitro Diagnostic Medical Devices Regulation (IVDR) and the Artificial Intelligence Act (AIA).*
International Medical Device Regulators Forum — IMDRF/SaMD WG/N10FINAL:2013 — *Software as a Medical Device (SaMD): Key Definitions.*
European Union — Regulation (EU) 2024/1689 — *Artificial Intelligence Act.*
Methodological Note
MDCG documents are guidance documents intended to promote a harmonised understanding and implementation of the MDR and IVDR regulations. They do not replace legally binding texts.
The qualification and classification of software must be established individually in light of its intended purpose, its functions, and the characteristics of the specific product.
Editorial Note
This article provides general information on the European regulatory framework for medical software. It constitutes neither a qualification or regulatory classification decision for a specific product, nor an individualised legal or regulatory opinion.
Elysium MedTech
*Medical intelligence. Responsible technology. Governance by design.*