Le guide Team-NB « Software Qualification Under IVDR: TeamNB Guidance on IVD Software Classification and Notified Body Expectations » (v2 de juin 2025) apporte des clarifications pratiques sur la qualification et la classification des logiciels de diagnostic in vitro (IVD) selon le règlement (UE) 2017/746 (IVDR). Il s’adresse spécifiquement aux fabricants de dispositifs médicaux de diagnostic in vitro (DM-DIV) et précise les attentes des organismes notifiés, en complément des textes réglementaires et des guides MDCG existants.

Contexte réglementaire

• IVDR (UE) 2017/746 : Entré en vigueur le 26 mai 2022, il introduit une classification basée sur le risque et renforce le rôle des organismes notifiés. Désormais, environ 80% des DM-DIV, y compris de nombreux logiciels, nécessitent une évaluation par un organisme notifié avant mise sur le marché.
• Persistance d’incertitudes : Malgré le guide MDCG 2019-11, des zones d’ombre subsistent sur la qualification et la classification des logiciels IVD.

Processus décisionnel de qualification : l’arbre en 3 étapes

Le guide propose un arbre décisionnel structuré pour déterminer le statut réglementaire d’un logiciel :

1. Le logiciel pilote/influence un DM-DIV ou en est une partie intégrante ?
   • Si oui : le système complet (logiciel + matériel) est classé selon sa finalité.
2. Le logiciel est-il un DM-DIV à part entière selon l’IVDR ?
   • Si oui : il est classé selon son usage prévu, indépendamment du matériel.
3. Le logiciel est-il un accessoire d’un DM-DIV ?
   • Si oui : il est classé selon son usage propre, comme dispositif distinct.
   • Si non : il n’est pas couvert par l’IVDR.

Définitions et clarifications

• Logiciel pilotant/influençant un DM-DIV : Logiciel qui agit sur le fonctionnement d’un DM-DIV sans finalité médicale propre (ex : logiciel de contrôle moteur d’un microscope médical).
• Logiciel partie intégrante d’un DM-DIV : Logiciel essentiel au fonctionnement du DM-DIV, quel que soit le mode d’intégration (embarqué, distant, connecté).
• Accessoire logiciel : Logiciel utilisé avec un DM-DIV pour en permettre l’utilisation conforme ou assister sa fonction médicale, sans finalité médicale propre.
• Modules : Un même logiciel peut comporter des modules à finalité médicale (soumis à l’IVDR) et d’autres non. Le fabricant doit clairement identifier les frontières et interfaces de chaque module.
• Expert system : Logiciel fournissant des informations médicales en analysant des résultats d’examens in vitro, éventuellement combinés à d’autres données.

Points clés du guide

1. Exemples pratiques détaillés

Le guide fournit de nombreux exemples concrets pour chaque scénario de qualification, facilitant l’application du processus décisionnel :

• Logiciel de contrôle d’analyseur, module d’agrégation de résultats, application d’IA pour l’analyse d’images, etc.
• Distinction claire entre logiciels IVD autonomes, intégrés, accessoires ou hors champ IVDR (ex : LIMS, gestion d’inventaire, outils de visualisation non diagnostiques).

2. Gestion des modules mixtes

• Obligation pour le fabricant d’identifier précisément les modules à finalité médicale et non médicale dans un même logiciel.
• Chaque module médical doit être évalué et documenté séparément selon l’IVDR.

3. Classification des accessoires logiciels

• Les accessoires logiciels sont considérés comme des dispositifs distincts et doivent être classés selon leur usage propre, indépendamment du DM-DIV principal.

4. Pondération des sources de données

• Pour les logiciels utilisant des données issues à la fois de DM-DIV et d’autres dispositifs médicaux, Team-NB précise qu’il faut évaluer la contribution de chaque source pour déterminer si le logiciel relève de l’IVDR ou du MDR.

5. Clarification sur la non-couverture IVDR

• Team-NB liste explicitement les types de logiciels non couverts par l’IVDR (ex : LIMS, gestion d’inventaire, stockage de données, outils de visualisation non diagnostiques, générateurs de données synthétiques, etc.).

Attentes des organismes notifiés

• Documentation : Attente d’une justification claire du statut du logiciel, de la description des modules, de la finalité prévue et du processus de qualification suivi.
• Exemples et cas d’usage : Les organismes notifiés attendent des exemples concrets et une analyse détaillée pour chaque logiciel présenté.
• Réduction de l’incertitude : Le guide vise à harmoniser les pratiques d’évaluation et à réduire les divergences d’interprétation entre fabricants et organismes notifiés.

Points d’attention pour les fabricants de DM-DIV

• Bien définir la finalité prévue de chaque logiciel ou module.
• Documenter le processus de qualification en s’appuyant sur l’arbre décisionnel et les exemples du guide.
• Anticiper la classification des accessoires logiciels et préparer une documentation séparée si nécessaire.
• Analyser la provenance des données pour les logiciels combinant plusieurs sources.
• Se référer aux exemples du guide pour justifier les choix de qualification et de classification auprès des organismes notifiés.