MDR vs IVDR for Digital Biomarkers and Diagnostic Software

Software that measures tremor amplitude from a smartphone accelerometer to support the management of Parkinson’s disease. A machine-learning model that flags early signs of diabetic retinopathy from retinal images uploaded by a general practitioner. A cloud-based platform that aggregates continuous glucose monitoring data and generates alerts for patients and clinicians. These are all examples of digital health products that, in the European Union, may be regulated as medical devices. The critical question for developers, regulatory teams, and clinical leads is not whether the EU framework applies, but which legislative instrument governs the product: the Medical Devices Regulation (MDR, Regulation (EU) 2017/745) or the In Vitro Diagnostic Medical Devices Regulation (IVDR, Regulation (EU) 2017/746). The answer determines the conformity assessment route, the applicable classification rules, the role of a notified body, the technical documentation requirements, and the post-market surveillance obligations. It also determines whether a product that appears to be a single software application might be subject to different regulatory regimes depending on its intended purpose and the nature of the evidence it relies upon.

Both MDR and IVDR are EU-level regulations that are directly applicable in all Member States. They replace the previous Directives and aim to ensure a high level of health and safety while fostering innovation. National competent authorities, such as BfArM in Germany, ANSM in France, and AEMPS in Spain, oversee market surveillance and enforcement. The European Commission and the European Medicines Agency (EMA) also play coordinating roles, with the EMA providing scientific advice on certain device–drug combinations and high-risk devices. For software and AI, the regulatory landscape is further shaped by the AI Act (Regulation (EU) 2024/1689), which introduces obligations for high-risk AI systems that overlap with medical device legislation. However, the core classification and conformity assessment questions for digital biomarkers and diagnostic software remain anchored in MDR and IVDR.

At the highest level, the distinction is straightforward: MDR governs medical devices intended for a purpose that is not exclusively in vitro diagnostic, while IVDR governs in vitro diagnostic medical devices (IVDs). In practice, the borderline can be nuanced, particularly for software that processes data to generate information used in clinical decision-making. The intended purpose is the decisive factor, supported by the technological characteristics and the clinical evidence. A product that is intended to diagnose or monitor a condition by measuring physiological parameters directly from a patient may fall under MDR. The same product, if intended to diagnose by analyzing samples taken from the human body (including data derived from samples, such as genomic sequences), may fall under IVDR. Software that acts on data from a sample collected from the human body to provide information for diagnosis, prognosis, or monitoring of a disease is typically an IVD. Software that provides information for the diagnosis or monitoring of a condition by directly measuring physiological parameters from the patient, without analyzing a sample, is typically a medical device under MDR.

Core Definitions and the Legal Basis for Classification

The definitions in the two regulations are precise and purpose-driven. Under MDR, a medical device is any instrument, apparatus, appliance, software, implant, reagent, material, or other article intended by the manufacturer to be used for human beings for purposes such as diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease; diagnosis, monitoring, treatment, alleviation of, or compensation for an injury or disability; investigation, replacement, or modification of the anatomy or of a physiological or pathological process or state; or providing information by means of in vitro examination of specimens derived from the human body. The last clause is the bridge to IVDR: if the information is provided by means of an in vitro examination of specimens, IVDR applies.

Under IVDR, an in vitro diagnostic medical device is any device which is a reagent, reagent product, calibrator, control material, kit, instrument, apparatus, piece of equipment, software, or system intended by the manufacturer to be used in vitro for the examination of specimens derived from the human body, solely or principally, to provide information on physiological or pathological state, congenital abnormality, predisposition to a medical condition, or to monitor therapeutic measures. Specimen includes samples of blood, urine, stool, tissue, and also data derived from such samples, such as genomic sequences obtained from a blood sample. The key is that the device provides information based on an in vitro examination of a specimen.

These definitions are not merely descriptive; they determine the legal basis for conformity assessment. For MDR, the legal basis is Regulation (EU) 2017/745. For IVDR, it is Regulation (EU) 2017/746. The regulations are directly applicable, meaning that Member States cannot maintain national deviations. However, national implementation measures exist for aspects such as the designation of notified bodies, the organization of market surveillance, and the procedures for vigilance reporting. Competent authorities may also publish national guidance interpreting borderline cases, which can create subtle differences in practice across the EU. Developers should monitor guidance from their target markets, particularly for borderline software products.

Intended Purpose as the Decisive Factor

The intended purpose is the anchor for classification. It is defined in both regulations as the use for which a device is intended according to the labelling, instructions for use, or promotional materials. It is not simply what the software does technically; it is what the manufacturer claims it does in clinical practice. The intended purpose must be explicit, specific, and supported by clinical evidence. It is also the basis for risk classification. For software, the intended purpose often distinguishes between:

• Diagnostic uses: providing information for the identification of a disease or condition.
• Therapeutic uses: guiding treatment decisions or directly influencing therapy.
• Monitoring uses: tracking the status of a disease or a physiological parameter.
• Predictive or prognostic uses: forecasting the likelihood of future events, such as disease onset or progression.

For digital biomarkers, the intended purpose often involves monitoring or predicting a physiological or pathological state. For diagnostic software, the intended purpose is to identify or confirm the presence of a disease. The distinction between monitoring and diagnosis can be subtle but has significant regulatory consequences. For example, a software that continuously measures tremor amplitude to monitor Parkinson’s disease progression would typically be a medical device under MDR. If the same software claims to diagnose Parkinson’s disease based on tremor patterns, it may still be a medical device under MDR, but the clinical evidence requirements would be more stringent, and the classification may be higher. If the software analyzes a biological sample (e.g., a saliva sample) to measure biomarkers indicative of Parkinson’s disease, it would be an IVD under IVDR.

Software as a Device and SaMD vs SiMD

Software can be a medical device in its own right (Software as a Medical Device, SaMD) or an integral part of a hardware device (Software in a Medical Device, SiMD). Both MDR and IVDR cover standalone software. The classification depends on the intended purpose and the risk class. For SaMD, the key question is whether the software provides information for medical purposes. If it does, it is a device. If it does not, it may fall outside the scope of medical device legislation. For example, a general wellness app that provides lifestyle recommendations without diagnosing or monitoring a disease is not a medical device. However, if the same app claims to diagnose a condition or monitor a disease, it becomes a device.

For SiMD, the software is part of a larger device. The classification of the parent device typically determines the classification of the software. For example, software that controls an insulin pump is part of the pump system and is classified accordingly. For standalone software that processes data from other devices, the classification depends on the intended purpose of the software itself. A software platform that aggregates data from multiple devices and generates clinical recommendations is likely a standalone device, and its classification will be determined by the risk associated with those recommendations.

Borderline Scenarios: When MDR and IVDR Overlap

The borderline between MDR and IVDR is a common source of regulatory uncertainty. The following scenarios illustrate how intended purpose and the nature of the data drive classification.

Scenario 1: Digital Biomarkers from Wearables

A software application uses data from a wearable sensor (e.g., an accelerometer or a photoplethysmography sensor) to quantify tremor, gait, or heart rate variability. The intended purpose is to monitor the progression of a neurodegenerative disease or to detect arrhythmias. In this case, the software is measuring physiological parameters directly from the patient without analyzing a specimen. It is a medical device under MDR. The classification depends on the risk associated with the monitoring function. For example, software intended to monitor a life-threatening condition may be Class IIa or higher. If the software also claims to diagnose the condition based on sensor data, it remains under MDR, but the clinical evidence must support diagnostic performance, and the classification may increase.

Scenario 2: Diagnostic Software Using Image Analysis

A software algorithm analyzes medical images (e.g., chest X-rays, retinal photographs) to detect abnormalities. If the images are obtained directly from the patient and the software provides diagnostic information, the product is a medical device under MDR. If the images are derived from samples (e.g., histology slides prepared from tissue samples), the product may be an IVD under IVDR. The distinction can be nuanced. For example, a software that analyzes retinal photographs taken in a primary care setting to detect diabetic retinopathy is typically a medical device under MDR because it is diagnosing a disease based on images of the patient’s body. However, if the same software is intended to analyze digitized histology slides from a biopsy to diagnose cancer, it is an IVD because it is analyzing a specimen derived from the human body.

Scenario 3: Genomic Analysis and Companion Diagnostics

A software platform analyzes genomic sequences from a blood sample to identify mutations that predict response to a targeted therapy. This is a classic IVD under IVDR. If the test is intended to select patients for a specific therapy, it may be a companion diagnostic. Companion diagnostics are explicitly covered under IVDR and are typically Class C devices. The intended purpose is to identify patients who will benefit from a particular medicine, and the clinical evidence must demonstrate analytical and clinical validity in the context of the therapy. If the same software also provides general prognostic information unrelated to therapy selection, the intended purpose must be carefully defined to avoid regulatory overlap with MDR. In practice, companion diagnostics are governed by IVDR, with EMA involved in the joint evaluation of device–drug pairs.

Scenario 4: Laboratory Information Systems and Decision Support

A laboratory information system (LIS) that aggregates test results and provides interpretive reports may be a medical device if the interpretive function is intended to support diagnosis. For example, an LIS that calculates a risk score from laboratory results and suggests diagnostic pathways is likely a device under MDR. If the LIS simply transmits raw results without interpretation, it may not be a device. However, if the LIS includes algorithms that analyze in vitro test results to provide diagnostic information, it may be an IVD under IVDR. The key is whether the software analyzes specimens (including data derived from specimens) to provide diagnostic information.

Scenario 5: AI Models Trained on Multi-Modal Data

An AI model is trained on both imaging data and laboratory results to predict disease risk. The intended purpose may be to stratify patients for preventive care. If the model uses laboratory results derived from specimens, those components are IVDs. If the model uses imaging data directly from the patient, those components are medical devices under MDR. When a single software product integrates multiple functions, the manufacturer must define the intended purpose precisely and classify each function accordingly. In some cases, the product may be a hybrid, with different parts governed by MDR and IVDR. The technical documentation must reflect this, and the conformity assessment must address both regimes if applicable.

Scenario 6: General Wellness vs Medical Purpose

A software that tracks sleep patterns and provides general recommendations for better sleep hygiene is not a medical device. If the same software claims to diagnose sleep apnea based on heart rate variability and movement patterns, it becomes a medical device under MDR. The classification depends on the risk associated with the diagnosis. If the software is intended to be used in a home setting to screen for a life-threatening condition, it may be Class IIa or higher. The manufacturer must ensure that the intended purpose is supported by clinical evidence and that the labelling does not overstate the capabilities.

Classification Rules and Conformity Assessment

Classification determines the conformity assessment route and the involvement of a notified body. Under MDR, devices are classified into four classes based on risk: Class I (low risk), Class IIa (medium risk), Class IIb (higher risk), and Class III (high risk). Software is explicitly included, and classification rules consider the intended purpose and the potential impact on patients. For example, software intended to monitor a physiological parameter that could be life-threatening if not addressed in a timely manner may be Class IIa. Software intended to control a therapeutic device, such as an insulin pump, may be Class IIb. Software that provides diagnostic information for a life-threatening condition may be Class IIb or III, depending on the severity and the reliance on the software’s output for clinical decisions.

Under IVDR, classification is based on the risk class of the device, ranging from Class A (lowest risk) to Class D (highest risk). The classification rules consider the intended purpose, the nature of the information provided, and the risk to public health. For example, a self-test for pregnancy is Class A. A blood glucose monitor for home use is Class B. A test for HIV infection is Class C. A test for a high-risk infectious disease, such as Ebola, is Class D. Software that analyzes specimens to provide diagnostic information is classified according to these rules. For digital IVDs, the classification depends on whether the software is intended to diagnose a condition, monitor a condition, or provide prognostic information. Class C and Class D devices require notified body involvement, and Class D devices require additional oversight, including batch release by a reference laboratory.

For software, both regulations include specific provisions for standalone software. Under MDR, Rule 11 addresses software intended to provide information for diagnosing, monitoring, or treating a condition. The classification is based on the impact on the patient: software that drives or influences clinical decisions for life-threatening conditions is Class IIb or III. Software that provides information for diagnosis or monitoring of a non-life-threatening condition may be Class IIa. Under IVDR, software that analyzes specimens to provide diagnostic information is classified according to the risk of the condition and the role of the software in clinical decision-making. For example, software that provides a diagnosis of a life-threatening infectious disease is likely Class C or D.

Conformity Assessment Routes

Class I devices under MDR can be self-certified by the manufacturer, provided they are not sterile or have no measuring function. Class IIa, IIb, and III devices require notified body involvement. For software, this means that the quality management system (QMS) and technical documentation must be reviewed by a notified body for higher-risk classes. Under IVDR, Class A devices can be self-certified, while Class B, C, and D devices require notified body involvement. The involvement of a notified body is a significant operational consideration, as notified body capacity is limited and timelines can be long. Manufacturers should plan for notified body engagement early, especially for Class C and D IVDs and Class IIb and III medical devices.

The conformity assessment procedures include the preparation of technical documentation, clinical evaluation, risk management, and post-market surveillance. For software, additional considerations include software lifecycle processes, cybersecurity, and algorithm validation. The technical documentation must demonstrate that the software is safe and effective for its intended purpose, with clinical evidence appropriate to the risk class. For AI-based software, the documentation should address algorithm performance, robustness, and generalization, as well as measures to manage bias and ensure transparency.

Clinical Evidence and Performance Evaluation

Both MDR and IVDR require clinical evidence to demonstrate safety and performance. Under MDR, clinical evaluation is a systematic process for generating, collecting, and analyzing clinical data. It includes a clinical development plan, a gap analysis, and a synthesis of evidence from clinical investigations, literature, and real-world data. For software, clinical evidence may include retrospective studies using real-world data, prospective studies, or a combination. The level of evidence depends on the risk class and the intended purpose. For diagnostic software, the evidence must demonstrate diagnostic accuracy and clinical utility. For monitoring software, the evidence must demonstrate that the monitoring information leads to improved clinical outcomes.

Under IVDR, performance evaluation is analogous but tailored to in vitro diagnostics. It includes analytical performance, clinical performance, and scientific validity. Analytical performance covers accuracy, precision, sensitivity, specificity, and limits of detection. Clinical performance covers the ability to provide clinically meaningful information, such as predicting disease risk or monitoring therapeutic response. Scientific validity refers to the association between the biomarker and the clinical condition. For digital biomarkers derived from specimens, the manufacturer must demonstrate that the biomarker is scientifically valid and that the software accurately measures it. For companion diagnostics, the clinical performance must be demonstrated in the context of the intended therapy.

For AI-based software, both regulations require evidence that the algorithm performs as intended across relevant populations and clinical settings. This includes validation on independent datasets, assessment of bias, and monitoring of performance in the post-market phase. The AI Act introduces additional obligations for high-risk AI systems, including risk management, data governance, transparency, and human oversight. For medical devices and IVDs that are also high-risk AI systems, the obligations under the AI Act and the medical device regulations must be met concurrently. Manufacturers should integrate AI governance into their quality management systems and ensure that technical documentation addresses both sets of requirements.

Real-World Evidence and Post-Market Surveillance

Real-world evidence plays an increasing role in both MDR and IVDR. For software, real-world data from clinical practice can be used to monitor performance, detect drift, and update algorithms. Post-market surveillance plans must describe how the manufacturer will collect and analyze data after the product is placed on the market. For software, this includes monitoring for changes in data distributions, updates to algorithms, and cybersecurity vulnerabilities. The regulations require proactive surveillance, not just reactive incident reporting. Manufacturers should establish registries or data-sharing agreements to collect relevant outcomes and use this data to update clinical evaluations and performance evaluations.

Vigilance procedures are harmonized across the EU. Serious incidents must be reported to the competent authorities within defined timelines. For high-risk devices, the reporting requirements are more stringent. Manufacturers must also report