When is software a device? Clarifying qualification criteria for IVD software under the IVDR

Is your software an in vitro diagnostic medical device? In its latest position paper (June 2025), Team-NB introduces long-awaited clarity on how software should be qualified under the IVDR. The document provides practical criteria and updated examples to assist manufacturers and Notified Bodies in evaluating borderline cases—especially when it’s unclear whether software supporting laboratory workflows crosses the threshold into regulated territory.

What does software qualification under the IVDR mean?

Qualification is the initial regulatory step that determines whether software meets the definition of an in vitro diagnostic medical device (IVD) under Article 2(2) of Regulation (EU) 2017/746. It precedes classification, conformity assessment, and the application of essential safety, performance, and documentation requirements.

According to Team-NB, the intended purpose declared by the manufacturer is the determining factor. This means that software must be clearly described in terms of whether it:

• analyzes biological parameters to provide information on a person’s health condition,
• supports diagnostic decisions based on IVD-derived data,
• modifies, interprets, or filters biological data in a way that directly impacts diagnostic outcomes.

If yes, then the software qualifies as an IVD and is subject to full IVDR obligations.

Clear examples, clear boundaries

One of the most valuable parts of the document is a series of practical examples illustrating typical scenarios. For instance:

• Yes: software analyzing PCR test results to identify pathogens and support diagnosis is an IVD.

• No: a statistical tool that tracks lab productivity or staff performance is not an IVD.

These distinctions are crucial. They determine whether CE marking, Notified Body involvement, performance evaluation, and a quality management system are legally required.

Clinical impact

In ambiguous cases, Team-NB encourages applying a “clinical impact test”: does the software influence clinical decisions? If the answer is yes, there is a strong likelihood it qualifies as an IVD.

Importantly, the document advocates a precautionary approach. It’s safer to qualify software as an IVD and take the necessary steps than to risk non-compliance and market rejection due to incorrect qualification.

Why this matters for manufacturers and Notified Bodies alike

The new guidance is not only relevant for software developers. It also offers a shared reference framework for Notified Bodies, supporting more consistent qualification decisions across the EU.

Additionally, Team-NB emphasizes the value of early regulatory consultation—ideally during product design. Collaboration with regulatory experts, including advisory services available at some Notified Bodies, is strongly encouraged.

Team-NB Position Paper on Software Qualification