Claudia Dannehl
Senior consultant, Medical Device RA – GBA Key2Compliance
Many software development companies fear the classification of their software as a medical device, because developing a medical device means following many regulations. However, there are also few advantages to having software applications that qualify as medical device software (MDSW).
In this blog post, we aim to clarify key definitions, provide examples, and outline the benefits and processes involved in developing software that qualifies as a medical device under the EU medical device regulations.
Advantages of Classifying Your Software as a Medical Device
Regulatory Compliance and Reimbursement
MDSW carrying a CE mark can qualify for reimbursement by health insurance providers. Currently, 59 software apps are listed in the German DiGA (Digital Health Application) directory. Similar fast-track systems exist in France and Belgium, enabling manufacturers to receive reimbursement of their MDSW within a 1-year validation phase.
Competitive Advantage
Having a CE-marked device can also provide a competitive advantage. This is because CE marking demonstrates that the device meets high safety, health, and environmental protection requirements, which can enhance the product’s credibility and trustworthiness in the market. Additionally, it allows the product to be marketed and sold within the European Economic Area (EEA) without additional regulatory barriers, providing access to a larger market.
What makes MDSW so difficult compared to non-MDSW?
The legal framework is totally different. Medical devices (comparable to pharmaceuticals) are highly regulated everywhere in the world. And let’s face the truth, MDSW requires much more documentation than non-MDSW. A rough overview of key differences is provided in Table 1.
Table 1: Challenges with MDSW compared to non-MDSW in Europe
| Aspect | Challenges with MDSW |
|---|---|
Safety and performance | Need for clearly establishing safety and performance requirements |
Content | CE marking (and compliance) according to MDR/IVDR required as well as harmonized standards Can require certification by external parties (Notifies Bodies) Requires establishing a quality management system, which requires internal resources |
Legal restrictions | Possible limitations in sales and distribution, as those activities are regulated for medical devices |
Frequent Updates | Regulatory assessment required for software updates |
Data Integrity and Management | High demands on data quality, avoiding bias, and ensuring reproducibility. |
These challenges make early regulatory planning essential for companies developing MDSW.
What is a medical device?
A medical device is any product intended to diagnose, monitor, prevent, or treat health-related conditions, supported by scientific and clinical evidence. MDSW may fall under the In Vitro Diagnostic Regulation (IVDR) rather than MDR, depending on its intended purpose.
The Medical Device Regulation (MDR, EU 2017/745) defines a medical device broadly, encompassing software used for diagnosis, monitoring, treatment, or compensation for injury and disability. The In Vitro Diagnostic Regulation (IVDR, EU 2017/746) further specifies medical software that analyzes biological samples to provide diagnostic insights.
Table 2: Examples for essential characteristics of IVDs, as per MDCG 2024-11
| Information | Examples |
|---|---|
Concerning a physiological process or state | Devices intended for detection of menopause, ovulation, or pregnancy |
Concerning a pathological process or state | A self-test for HIV screening, devices for screening or staging of cancer, device for identification of IgG antibodies against Helicobacter pylori |
Concerning congenital physical or mental impairments | Devices intended for evaluating the risk of trisomy 21, devices intended for newborn screening for congenital hypothyroidism, severe combined immunodeficiency (SCID), or spinal muscle atrophy (SMA) |
Concerning the predisposition to a medical condition or disease | Devices intended for detection of lactose or gluten intolerance, devices intended for detecting genetic carriers of cystic fibrosis, devices intended to detect genetic alterations of the BRCA1 gene for hereditary breast cancer |
To determine the safety and compatibility with potential recipients | Devices intended for ABO system blood grouping, or HLA typing |
To predict treatment response or reactions | Devices intended for screening of the HLA-B*5701 allele to determine the risk of hypersensitivity to abacavir in HIV-infected individuals, devices intended for SLCO1B1 variants to predict statin-induced myopathy, devices intended for determining principal gene variants of MTHFR to identify patients with reduced activity of the enzyme MTHFR who are at increased risk of serious adverse events in patients treated with methotrexate |
To define or monitor therapeutic measures | Devices intended for monitoring of blood glucose levels, devices intended for T-helper cells to monitor therapeutic measures, devices intended for measuring the levels of digitoxin. |
Examples of Software That May Qualify as MDSW
Here are a few examples to illustrate the distinction between MDSW and non-MDSW:
Example A: Blood Glucose Record Software
- Description: Patient enters data to track their blood glucose levels.
- Classification: Likely not a medical device as the software only records and displays data without providing actionable information (=’patient diary’)
Example B: Blood Glucose Monitoring with Alerts
- Description: software for automated tracking of blood glucose levels. Software provides alerts to patient when levels are too high.
- Classification: Considered MDSW as it includes an algorithm that evaluates data and gives actionable feedback about a physiological state. The MDSW directly influences medical decision making.
Example C: Nutrition Optimization Software for Sports
- Description: Evaluation of blood test results and provision of supplement recommendations for healthy individuals.
- Classification: Not an IVD as it targets general well-being, not medical purposes (per Article 2(2) IVDR and MDCG 2024-11)
Example D: AI for Spectral Analysis in Labs
- Description: AI evaluates InfraRed spectra from patient samples. Used in a medical laboratory. The AI has been trained with data from healthy and unhealthy individuals to obtain insights into a certain health status/disease.
- Classification: Considered MDSW under IVDR. Depending on the indications for use, the AI software is at least a Class B device, while the laboratory hardware generating the InfraRed spectra is considered a Class A device.
Example E: Patient management system with optional module on calculating drug dosage
- Description: Software for patient admission, scheduling appointments, insurance and billing. A drug planning system can be purchased upon request
- Classification: The software is considered a Hospital Information System as per MDCG 2019-11. Those systems do not fall under the definition of MDSW. However, the additional module on drug planning (=’decision support’) qualifies as MDSW.
Key Steps to Achieve Compliance
If your software qualifies as a medical device, follow these steps:
- Risk Classification: Determine if your software falls into Class I, IIa, IIb, or III under MDR (or Class A, B, C, D under IVDR). Read more about medical device classification →
- Technical Documentation: Prepare documentation, including intended use, risk assessment, validation data, and clinical evaluation.
- Quality Management System (QMS): Implement a QMS aligned with ISO 13485.
- Performance and Clinical Validation: Demonstrate software safety and effectiveness through evaluation and real-world testing.
- Regulatory Submission: Submit for CE marking or Notified Body assessment, depending on risk classification.
- Post-Market Surveillance: Ensure ongoing monitoring, reporting, and risk management.
For a detailed breakdown, book a consultation → with our experts. If you are unsure, start by using our initial evaluation checklist to determine if your software falls under the definition of a medical device. Download the checklist →
Advice to get started
Understanding whether your software qualifies as a medical device can be challenging. MDR and IVDR focus on the intended use of the software, meaning how it is described and its impact on medical decisions.
- Clearly define your product scope based on current medical practices.
- Involve product managers, medical professionals, and regulatory experts early in the process.
- Develop a strategy for regulatory compliance and clinical validation.
- Implement applicable standards, such as ISO 13485 and EN 62304
Conclusion & Next Steps
Navigating MDR and IVDR classifications is critical for launching compliant medical device software. By defining your product’s intended use, evaluating risk, and planning regulatory steps early, you can streamline your compliance process.
Take action now:
- Need expert guidance? Contact us
- Want to avoid common compliance mistakes? Download our guide
Staying proactive in compliance will save time and resources while ensuring your software meets regulatory standards.
With the right preparation and expert guidance, your software can successfully navigate regulatory challenges and reach the market faster.
References and further readings:
- MDR: Medical Device Regulation (EU 2017/745)
- IVDR: In Vitro Diagnostic Regulation (EU 2017/746)
- MDCG 2019-11: Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR, October 2019
- MDCG 2024-11: Guidance on qualification of in vitro diagnostic medical devices, October 2024
- EN ISO 13485: Medical devices — Quality management systems — Requirements for regulatory purposes
- EN 62304: Medical device software — Software life cycle processes
- EN ISO 14971: Medical devices – Application of risk management to medical devices
- EN 62366-1 Medical devices Part 1: Application of usability engineering to medical devices
- Blog post on borderline medical devices