{"id":34622,"date":"2025-08-27T14:21:27","date_gmt":"2025-08-27T12:21:27","guid":{"rendered":"https:\/\/www.thema-med.com\/?p=34622"},"modified":"2025-10-28T12:02:00","modified_gmt":"2025-10-28T11:02:00","slug":"ivd-software-qualification-the-team-nb-guide","status":"publish","type":"post","link":"https:\/\/www.thema-med.com\/en\/2025\/08\/27\/ivd-software-qualification-the-team-nb-guide\/","title":{"rendered":"IVD Software Qualification: The Team-NB Guide"},"content":{"rendered":"

Translated with AI<\/strong><\/span><\/p>\n<\/p>\n

The Team-NB,<\/strong> the European association of Notified Bodies for Medical Devices, published the second version of its Position Paper on June 27, 2025<\/strong>, titled “TEAM NB Position Paper on Software qualification under the IVDR.”<\/strong><\/a> Developed by the IVD Software Working Task Force, the document is a valuable resource for IVD manufacturers, addressing one of the topics with the greatest uncertainty: the qualification of software under the IVDR (EU) 2017\/746<\/strong>.<\/p>\n

The second version of the Position Paper<\/strong>, which updates the 2021 version, was developed to align with the recent guideline MDCG 2019-11 rev.1 of June 17, 2025<\/strong><\/a>. The document reflects the perspective of Notified Bodies <\/strong>and provides practical and concrete clarifications to help manufacturers decide whether or not to submit their software to a Notified Body.<\/p>\n

IVD Software Qualification<\/strong><\/p>\n

The document addresses the central theme of software qualification. A software is considered an in vitro diagnostic medical device<\/strong> if it is intended to be used for a specific medical purpose, as defined in Regulation (EU) 2017\/746.<\/strong> This rule applies regardless of whether the software is stand-alone, part of a device, or influences its use.<\/p>\n

This definition is fundamental for manufacturers<\/strong>, who can thus determine whether their software falls within the scope of the IVDR and what the regulatory expectations are. It provides a clear boundary between software that has a diagnostic or clinical function and software used for purely administrative purposes.<\/p>\n

The Three Qualification Paths<\/strong><\/p>\n

In addition to various clarifications of terms and definitions, the Paper proposes a decision tree<\/strong> that helps to establish if and how a software falls within the IVDR scope, distinguishing three scenarios:<\/p>\n

    \n
  1. Part\/Integration of a Device:<\/strong> the software is an integral part of or guides\/influences the operation of a hardware device (e.g., software that controls the motors of a digital medical microscope). In this case, the software follows the regulatory fate of the device itself.<\/li>\n
  2. Stand-Alone Device:<\/strong> if the software has its own IVD purpose and functions on its own (e.g., an application that analyzes histological images to identify tumor cells), it is considered an IVD device and must be classified and evaluated independently.<\/li>\n
  3. Accessory:<\/strong> a product that, while not an IVD device itself, is intended to be used together with one or more IVDs to enable their use or specifically assist their medical functionality.<\/li>\n<\/ol>\n

    Software Excluded from the IVDR<\/strong><\/p>\n

    The document also provides practical examples of software that do not fall within the scope of the IVDR, provided they are confined to administrative or training functions:<\/p>\n