Clinical evaluation for Medical Device Software (MDSW) under the EU MDR follows the same legal requirements as any other medical device. Article 61(1) still demands clinical evidence sufficient to confirm conformity with the General Safety and Performance Requirements (GSPRs). What changes is the execution: the data sources you draw on, a software-specific three-phase framework set out in MDCG 2020-1, and a broader reading of what “clinical benefit” means. This article walks through what is genuinely different about evaluating MDSW, and what only looks different.
A note on scope before we start: MDSW is a term from the EU-MDR, so software for in-vitro diagnostic purposes (MDSW under the IVDR) is out of scope here. Other markets and the International Medical Device Regulators Forum (IMDRF) may instead use the concept of software as a medical device (SaMD), which differs slightly in concept and expectations across jurisdictions.
Before getting into the intricacies of MDSW clinical evaluation, it is worth taking a step back to ask what it means to talk about software with a specific intended medical purpose. The answer starts with MDCG 2019-11, “Qualification and classification of software – Regulation (EU) 2017/745 and Regulation (EU) 2017/746.” It offers a step-by-step approach to characterizing the software and verifying that the proposed device is a medical device. The most important questions are:
If the answer to all three is yes, you can assume the proposed device is indeed MDSW and proceed to examine how its clinical evaluation works.
MDCG 2020-1, “Guidance on clinical evaluation (MDR) / Performance Evaluation (IVDR) for medical device software,” was published in March 2020 and distinguishes two different concepts of MDSW. The first is software with a specific intended medical purpose that leads to a clinical benefit. The second is software intended to drive or influence another medical device without having a medical purpose of its own.
For that second category, the clinical evidence should relate to the device being driven or influenced, so standard clinical evaluation practices apply, and we will not consider it further here. For the first category, the clinical evaluation focuses on demonstrating that the software itself complies with the applicable GSPRs.
For that purpose, MDCG 2020-1 proposes a framework built on three phases:
The sections below take each phase in turn and compare it with “ordinary” clinical evaluation.
The concept of establishing a valid clinical association is unique to MDSW. The EU-MDR does not mention it, and neither does MEDDEV 2.7/1 rev. 4. The goal is to verify that the output of the MDSW, whether calculations, audio data, DICOM images, or similar, is generally accepted and clinically relevant.
Although the concept is new, the means of achieving it are not. A systematic literature review, together with a review of guidelines, product standards, and other public sources of clinical data, will provide what you need in most cases. Since a thorough state-of-the-art review is required anyway, these activities would be performed regardless. So while establishing a valid clinical association is a new idea, the data sources it relies on are already on the clinical evaluation menu, which means it integrates easily into the regular state-of-the-art review process.
Evidence of MDSW’s technical performance comes from verification and validation activities. The goal is to demonstrate that the software generates output accurately, reliably, and consistently, in line with its intended purpose in real-world use.
For a standard medical device evaluation, pre-clinical data can be used to substantiate certain performance and safety aspects, such as biocompatibility, usability, or sterilization validation. For MDSW, the focus shifts to accuracy, data quality, and cybersecurity. Still, the underlying concept of collecting and analyzing pre-clinical data to support the foundation of clinical evidence remains the same.
One point is worth highlighting: MDCG 2020-1 uses the term “real-world usage.” Technical performance characteristics may also be substantiated using real-world data, that is, by analyzing existing, previously collected patient data. Where that data was collected by the manufacturer at an earlier stage rather than sourced from publicly available databases, it is important to consider whether patients have consented to this type of use. So, compared with the standard evaluation, the pre-clinical verification and validation for MDSW do not differ conceptually. Other types of data may be used, and this part of the evaluation may carry more weight.
The final step is validating the device’s clinical performance, which is no different from a standard clinical evaluation. The goal is to substantiate all clinical safety and performance claims with sufficient, high-quality clinical data, confirming that the device is safe, performs as intended, and that the clinical benefit outweighs the associated risks.
Formulating and substantiating the clinical benefit can be challenging even for a conventional medical device. For MDSW, it can be even harder because the interaction between the device and the patient is often more indirect, so it is not always obvious how the patient benefits or how that benefit can be quantified. That difficulty is worth examining in its own right.
By the definition in EU-MDR Article 2(48), the clinical benefit of a medical device is the positive impact of the device on a person’s health, expressed in meaningful, measurable, patient-relevant clinical outcomes (including outcomes related to diagnosis) or on patient management or public health.
Reading that definition, there are essentially two routes to a clinical benefit:
For many MDSWs, the second route is a better fit. Imaging software that automatically detects anatomical structures does not directly affect an individual’s health, but it indirectly supports physicians, with a clear positive impact on patient management.
Here, the guidance documents pull in different directions. The second route does not appear to have been included in MDCG 2019-11, which states that the actions performed must be for the benefit of individual patients. MDCG 2020-1, by contrast, broadens the concept: it states that a clinical benefit for MDSW may differ from that for other devices, since the benefit may lie in providing accurate medical information even when the final clinical outcome still depends on further diagnostic or therapeutic decisions. So the two documents are not fully aligned. MDCG 2019-11 narrows the definition while MDCG 2020-1 widens it. Reading them against the Article 2(48) definition above, it makes sense to adopt the broader understanding presented in MDCG 2020-1.
It helps to remember how different MDSW can be from a conventional device. A catheter is nothing like a hospital information system; a hip implant is not comparable to imaging software. Algorithms are not tangible. They do not need to be sterile, they have no sharp edges, and they cause no allergic reactions. Yet despite those obvious differences, the EU-MDR contains no special requirements just for software. The level of clinical evidence required is at the manufacturer’s discretion, provided it is appropriate to the device’s characteristics and intended purpose.
That is why, conceptually, clinical evaluation for MDSW is not that different; the requirements are the same. The differences are practical:
In conclusion, clinical evaluation for MDSW is not fundamentally different from that of any other medical device. At the same time, a broader perspective is needed to apply the principles effectively and meet the general requirements set out in the EU-MDR.
Want to go deeper on how this applies to your device? Learn more about our clinical evaluation services, or reach out to our team to discuss your specific MDSW evaluation.