--- title: "Your IVD Software's Risk Class Alone Won't Tell You What Evidence You Need" description: "Risk class alone does not determine the clinical evidence needed for IVD software. Learn what should actually drive your IVDR evidence strategy." url: https://qbdgroup.com/en/blog/ivd-software-risk-class-clinical-evidence type: "Blog post" language: en published: 2026-09-30 author: "Pieter Smits & Pieter Bogaert" category: "Software Solutions & Services" publisher: "QbD Group" citation: "QbD Group, \"Your IVD Software's Risk Class Alone Won't Tell You What Evidence You Need\", https://qbdgroup.com/en/blog/ivd-software-risk-class-clinical-evidence" --- # Your IVD Software's Risk Class Alone Won't Tell You What Evidence You Need > Risk class alone does not determine the clinical evidence needed for IVD software. Learn what should actually drive your IVDR evidence strategy. When we polled manufacturers at our recent webinar, most believed that risk classification largely drives the clinical evidence required for IVD medical device software. It is an understandable assumption. **It is also where many evidence strategies start to drift.** Risk classification matters, but under the IVDR, it is only one of several factors that shape the depth of clinical evidence required. ## In This Blog Post - Why risk class alone does not determine your clinical evidence needs - Which factors should shape an IVD software evidence strategy - What actually drives your evidence strategy under the IVDR - Why clinical benefit needs to be defined as a tangible benefit for patients ## Risk Class Is One Signal, Not the Roadmap MDCG 2022-2 lists **sixteen factors** that shape the depth of clinical evidence. Device classification is just one of them. Other factors include: - the intended purpose - the intended users - the state of the art - the novelty of the technology - the disease state - population variability - the risk to the patient from an incorrect or delayed result **The implication is important: risk class alone cannot tell you what your clinical evidence strategy should look like.** Take two fictitious devices. An AI model that scores HER2 positivity in breast cancer falls into **Class C**. A rule-based algorithm that flags gestational diabetes risk falls into **Class B**. Both face the same clinical evidence requirements. What changes is the robustness of the clinical performance studies, and even that is determined case by case. **Risk class is one signal. It is not the evidence roadmap.** ## What Actually Drives Your IVD Software Evidence Strategy? Under the IVDR, your approach must be anchored in **GSPR 1 and 3 and Annex XIII, Section 1.3**. In practice, that means asking how you can demonstrate that your software achieves its intended purpose in a safe and effective manner. That assessment needs to take into account: - the current clinical workflow - how the software modifies that workflow - the consequences of software failures on diagnostic results - potential use errors The evidence strategy should therefore consider the software in the context in which it will actually be used, rather than starting from its classification alone. Relevant considerations include: - a description of the current state of the art - a critical analysis of the inputs and algorithms used by the software - an evaluation of the software's ability to generate correct output from those inputs and algorithms - validation of correct use and interpretation by the intended users Together, these elements help demonstrate whether the software can achieve its intended purpose safely and effectively. ## Watch the Clinical Benefit You Claim There is another important consideration when defining your evidence strategy: **the clinical benefit you claim.** Your software's clinical benefit should be defined as a tangible benefit for patients, not simply as an economic or operational benefit. The distinction can be subtle, but it matters. **Reducing laboratory workload is not a clinical benefit.** **Reducing time to result for critically ill patients is.** Your evidence needs to demonstrate benefit to the patient, so define that benefit accordingly from the start. ## Start With Intended Purpose, Not Risk Class The takeaway is straightforward. Everything starts with: - your software's intended purpose - its place in the overall clinical workflow - the medical information it generates **Not its risk classification.** Risk classification remains an important part of the regulatory picture, but it does not replace the need to understand what the software does, how it is used and what evidence is needed to support its intended purpose and clinical benefit. That is the foundation of a meaningful evidence strategy for IVD medical device software. ## Build the Right Evidence Strategy for Your IVD Software Planning clinical evidence for IVD medical device software requires more than applying a classification rule. QbD Group's Software Solutions & Services team can help you translate your software's intended purpose, clinical context and regulatory requirements into an appropriate evidence strategy. **Planning evidence for an IVD MDSW? [Get in touch with our Software Solutions & Services team](/en/services/software-solutions-services) to discuss the right approach for your device.** --- Source: https://qbdgroup.com/en/blog/ivd-software-risk-class-clinical-evidence — © QbD Group. Quote freely with attribution and a link back.