Team-NB guidance for software qualification under the IVDR

By QualitiBot
Jun. 30, 2025 Software

The Team-NB guide “Software Qualification Under IVDR: TeamNB Guidance on IVD Software Classification and Notified Body Expectations” (v2, June 2025) provides practical clarification on the qualification and classification of in vitro diagnostic device software under Regulation (EU) 2017/746 (IVDR). It is specifically intended for manufacturers of in vitro diagnostic medical devices (IVD MDs) and clarifies the expectations of notified bodies, supplementing existing regulatory texts and MDCG guidance documents.

Regulatory context

  • IVDR (EU) 2017/746: Entered into force on May 26, 2022, it introduces a risk-based classification and strengthens the role of notified bodies. From now on, approximately 80% of IVDs, including many software products, require assessment by a notified body before being placed on the market.
  • Persistent uncertainties: Despite the MDCG 2019-11 guidance, gray areas remain regarding the qualification and classification of IVD software.

Qualification decision-making process: the 3-step tree

The guidance proposes a structured decision tree to determine the regulatory status of software:

  1. Does the software control/influence an IVD MDs or is it an integral part of it?
    • If yes: the complete system (software + hardware) is classified according to its intended purpose.
  2. Is the software a IVD-MD in its own right according to the IVDR?
    • If yes: it is classified according to its intended use, regardless of the hardware.
  3. Is the software an accessory to a IVD?
    • If yes: it is classified according to its own use, as a separate device.
    • If not: it is not covered by the IVDR.

Definitions and clarifications

  • Software controlling/influencing a IVD: Software that acts on the functioning of a IVD device, without any medical purpose of its own (e.g., motor control software for a medical microscope).
  • Software that is an integral part of a IVD: Software that is essential for the functioning of the IVD, regardless of the mode of integration (embedded, remote, connected).
  • Software accessory: Software used with a IVD to enable its proper use or assist its medical function, without any medical purpose of its own.
  • Modules: The same software may include modules with a medical purpose (subject to the IVDR) and others without. The manufacturer must clearly identify the boundaries and interfaces of each module.
  • Expert system: Software that provides medical information by analyzing in vitro test results, possibly combined with other data.

Key points of the guide

1. Detailed practical examples

The guide provides numerous concrete examples for each qualification scenario, facilitating the application of the decision-making process:

  • Analyzer control software, result aggregation module, AI application for image analysis, etc.
  • Clear distinction between stand-alone, integrated, accessory, and non-IVDR-covered IVD software (e.g., LIMS, inventory management, non-diagnostic visualization tools).

2. Management of mixed modules

  • Requirement for the manufacturer to precisely identify modules with medical and non-medical purposes within the same software.
  • Each medical module must be assessed and documented separately in accordance with the IVDR.

3. Classification of software accessories

  • Software accessories are considered separate devices and must be classified according to their specific use, independently of the main IVD MD.

4. Weighting of data sources

  • For software that uses data from both MD-IVDs and other medical devices, Team-NB specifies that the contribution of each source must be assessed to determine whether the software falls under the IVDR or the MDR.

5. Clarification on IVDR non-coverage

  • Team-NB explicitly lists the types of software not covered by the IVDR (e.g., LIMS, inventory management, data storage, non-diagnostic visualization tools, synthetic data generators, etc.).

Expectations of notified bodies

  • Documentation: Clear justification of the status of the software, description of the modules, intended purpose, and qualification process followed.
  • Examples and use cases: Notified bodies expect concrete examples and a detailed analysis for each piece of software presented.
  • Reducing uncertainty: The guide aims to harmonize assessment practices and reduce differences in interpretation between manufacturers and notified bodies.

Points of attention for IVD MD manufacturers

  • Clearly define the intended purpose of each software or module.
  • Document the qualification process using the decision tree and examples in the guide.
  • Anticipate the classification of software accessories and prepare separate documentation if necessary.
  • Analyze the origin of data for software combining multiple sources.
  • Refer to the examples in the guide to justify qualification and classification choices to notified bodies.