How to understand if a software is a medical device according to the MDR
In the current health digitalisation context, many app developers and companies of the healthcare sector ask themselves if their software should be considered a medical device according to Regulation (EU) 2017/745 (MDR).
The answer to this question is not always immediate: the European regulations have introduced stricter requirements and new categories, especially for software, and many companies find themselves unprepared when facing regulatory obligations.
In this article, we will answer the 20 most frequent questions we have been asked by companies, start-ups, and developers operating in the sector of telemedicine, digital diagnostics, and clinical data management.
Our answers are based on the regulations in force, on the MDCG guidelines and on the direct experience gained by our consultancy firm.
1. Is my software a medical device according to the MDR?
A software is considered as a medical device if it has an intended medical purpose, such as diagnosis, prevention, monitoring, treatment or relief of a disease. The classification does not depend on the technology but on the intended use.
2. What requirements should a software have to be classified as medical device?
Not all software used in healthcare are automatically medical devices. The MDR establishes well defined criteria to distinguish a simple digital tool from an actual medical device.
The key element is the intended use declared by the manufacturer: if the software is designed for diagnostic, therapeutic or clinical monitoring purposes, then it should be considered (and managed) as a medical device, with all resulting obligations.
In short, it should:
- have a specific medical purpose;
- intended to be used in humans;
- be autonomous or part of a system;
- produce direct effects on health or support clinical decisions.
3. Is a health monitoring app a medical device?
It depends: if it is limited to general wellness (e.g. pedometers, or sleep trackers), it is not a MD. However, it might be if it monitors vital signs for clinical purposes (e.g. heart rate to identify arrhythmias).
4. What is the difference between medical software and wellness software?
A wellness software improves one’s life style and has no medical purposes. A medical software has a diagnostic or therapeutic purpose. The line separating the two can be thin, but it is decisive when it comes to regulatory matters.
5. What is meant by medical purposes of a software?
The medical purposes of a device are the crucial element determining if a software falls into the definition of a medical device.
It is not how the software works from a technical point of view, but why it was designed and what it is used for, according to the information declared by the manufacturer. Defining this purpose correctly is essential to categorise the product according to the regulatory framework of the MDR.
Therefore, having medical purposes means that the software is intended for:
- diagnosing a condition;
- monitoring the progress of a disease;
- support a therapeutic process;
- prevent a pathological condition.
6. When is a software considered as an “accessory” and not as a medical device?
According to Regulation (UE) 2017/745, a software can be qualified as “accessory” when it does not perform a medical function directly, but it is designed to specifically support one or more devices in their intended function.
In other words, an accessory has no autonomous medical purpose, but it is essential or useful to allow a medical device to work properly, or it optimises its use, facilitate measuring, or support the clinical process associated with the device.
Here are some examples:
- A software allowing the calibration or setting of a mechanical ventilator: it is an accessory of the ventilator.
- An app used for remote control of an infusion pump, used for the remote of an infusion pump, without processing any clinical value: also in this case, it can be considered an accessory, provided that it does not intervene in the clinical decision process directly.
- A program transmitting the data collected by a device to a central system without changing them or processing them: it is an accessory, not an autonomous MD.
If, on the other hand, the software processes, interpret or analyses clinical data in order to support a diagnosis, monitoring or treatment, then it becomes a medical device itself, even if it is used in combination with other devices.
What does the MDR provide for accessories?
The MDR includes accessories in their own field of application (art. 1.1 and art. 2.2), which means that they should comply to the general safety and performance requirements, however their regulatory assessment may follow a different parthway, depending on their classification and associated risk.
7. Is my software an SaMD (Software as a Medical Device)?
Yes, if it works autonomously, not being integral part of a medical hardware, performs a clinical function, it falls into the definition of SaMD.
8. Should a software processing clinical data be CE marked?
Yes, if the processing has a clinical purpose (e.g. supports diagnoses, sends alerts on out-of-range values). If, on the other hand, it only collects or displays data, it might not be required.
9. How can I classify the risk of my software according to the MDR?
The risk is based on:
- Severity of the impact on health;
- Intended use;
- Use context (e.g. hospital, domestic);
- Possible consequences in case of malfunctioning. The classification may range from Class I to Class III.
10. What are the documental obligations for a software classified as medical device?
A software falling into the definition of a medical device according to Regulation (UE) 2017/745 (MDR) should be accompanied by a complete technical documentation, systematically demonstrating the compliance with the essential safety and performance requirements. These obligations apply regardless the risk class, although the complexity and the level of details vary depending on the device classification.
Here are the main documents required:
- Technical dossier
- Risk analysis
- Clinical evidence
- Labelling and instructions for use
- Post-marketing surveillance
Technical dossier (Technical Documentation):
It is the core of regulatory conformity. It must include all information describing the software, its intended purpose, life cycle, functions, architecture, scope, applicable legal requirements and performed tests.
Risk analysis (Risk Management)
Risk analysis, in compliance with ISO 14971, is mandatory for all devices. It should identify, assess and mitigate the risks associated with the use of the software.
Clinical evidence (Clinical Evaluation)
The manufacturer should provide a clinical evaluation in compliance with annex XIV of the MDR, demonstrating the scientific validity, analytical performance and clinical performance of the software. It may include:
- Clinical studies or scientific bibliography
- Post-market data (real world evidence)
- Comparisons with equivalent solution already on the market.
Labelling and instructions for use (IFUs)
Every software should include labelling and IFUs complying with the requirements indicated under Chapter III of Annex I of the MDR.
Post-Market Surveillance (PMS)
The manufacturer is bound to implement a proactive system to collect and analyse data on the use of the software once is put on the market. It should include:
- Performance and safety monitoring procedures;
- Feedbacks collected from users;
- Updates of the software to respond to adverse events or performance issues;
- Integration of the data collected from the cycle of continuous improvement and risk management.
Post market clinical follow up (PMCF) plan and report
In the cases provided for by the law, especially for a software in Class IIa or above, a post market clinical follow up plan is also requested, in order to monitor the clinical efficacy of the software in time.
11. Does my software need a certification from a notified body?
Only if it is in Class IIa or above. A Class I software can be self-certified, by with very strict technical requirements.
12. Which are the European regulations applying to medical software?
- MDR 2017/745
- Related directives (GDPR, cybersecurity directive)
- ISO 13485 (quality)
- IEC 62304 (software life cycle)
13. Is there any guideline to establish if a software is a medical device?
Yes: MDCG 2019-11 is the official guideline to interpret the definition of a software as medical device.
14. What does the MDCG 2019-11 guideline say about software?
It provides decisional criteria (with flow charts) to establish if a software has a medical purpose, if it is part of a device or it is autonomous, and how it should be classified.
15. How is the software classification changed with the switch from the MDD to the MDR?
The switch from Directive 93/42/EEC (MDD) to Regulation (UE) 2017/745 (MDR) has had a significant impact on medical software classification. The new regulation has introduced more stringent criteria, in particular through the introduction of rule 11 of Annex VIII, specifically dedicated to software.
Before (MDD): more permissive classification
Under the MDD, much software was classified as Class I, often almost automatically, since there was no physical interaction with patients or functions considered as “critical”. The norm did not include any specific rule for software, leaving wide grey areas and room for interpretation.
After (MDR): new Rule 11 for software
With the MDR, software classification has become much more detailed and restrictive. Rule 11 provides for that the class risk does not depend so much on the related hardware, but rather on the function of the software itself and on the clinical consequences of its use.
Here is a summary of Rule 11:
- Class IIa: if the software is intended to provide information used for diagnostic/therapeutic decisions.
- Class IIb: if such decisions may result in a serious risk for the patient (e.g. irreversible damage, surgery).
- Class III: if the software is used for decisions that may have lethal or invalidating consequences.
- Class I: only if the software has no direct medical purpose or if it provides administrative/managing support without affecting health.
Much software that was self-certified under the MDD (Class I), now have to be assessed by a Notified Body, with a more rigorous evaluation.
This involves new documentary obligations, more structured clinical tests and a longer timeline before accessing the market.
Companies should review their software development and validation strategy to fit the new classification.
16. Should a software used by physicians be always certified as medical device?
Only if it has a direct medical purpose. If it is a mere managing or administrative tool, then no. But if it helps diagnosis or decisions on therapies, then yes.
17. Is a software supporting clinical decisions a medical device?
Yes. CDSS (Clinical Decision Support System) are medical devices if they affect the clinical process directly.
18. Is an AI algorithm a medical device?
If its output has a clinical influence (e.g. automatic diagnosis), then yes. AI is not exempted from the MDR, on the contrary, it requires special attention.
19. Can I sell my software without CE marking?
Only if it is not a medical device. If it is, the CE marking is mandatory for the marketing in the EU.
20. What is the difference between a “stand-alone” software and a software embedded in a medical device?
A stand-alone software is independent (e.g. a mobile app). An embedded software only works inside a device (e.g. an infusion pump firmware). They can be both regulated by the MDR.
How can we help?
Determining whether a software is a medical device is not only a question of regulations, but also a strategic operation and a legal responsibility. An erroneous classification may result in blocks in the marketing, sanctions or product recalls.
Our consultancy firm has a long-standing experience in the support of companies, start-ups and developers in the software and health tech sector:
- We evaluate the proper classification of the software
- We prepare technical dossiers, risk analyses and CE marking;
- We interact with notified bodies;
- We support regulatory conformity also on related topics such as the GDPR and cybersecurity.
Contact us if you have questions regarding your software or if you wish to plan a custom-made regulatory strategy. No obligation. We are here to simplify what may appear very complex.
Previous Post
Next Post