Réponse courte : le Règlement sur les dispositifs médicaux (MDR, 2017/745) couvre les dispositifs qui agissent sur le patient ou collectent des données directement auprès de lui : moniteurs, imagerie, applications qui évaluent des symptômes. Le Règlement sur les dispositifs médicaux de diagnostic in vitro (IVDR, 2017/746) couvre les dispositifs qui examinent des échantillons dérivés du corps humain (sang, urine, tissus, écouvillons) pour fournir des informations sur un état physiologique ou pathologique, y compris les logiciels qui pilotent un analyseur ou interprètent ses résultats. Si l'objectif médical de votre logiciel est dérivé de données de laboratoire ou génétiques, vous êtes probablement sous l'IVDR, dont la classification (A à D) implique des organismes notifiés pour presque toutes les classes. S'il utilise des signaux, des images ou des symptômes rapportés, vous êtes sous le MDR. Les logiciels qui font les deux sont classifiés sous chacun et suivent le chemin le plus strict.
La ligne de démarcation
La distinction entre le MDR et l'IVDR pour les logiciels réside dans l'origine des données : un logiciel dont l'usage prévu inclut la fourniture d'informations dérivées de l'examen in vitro d'échantillons provenant du corps humain (sang, urine, tissu, matériel génétique) est un dispositif médical de diagnostic in vitro (DM-DIV) selon l'IVDR ; un logiciel utilisant l'imagerie, des capteurs, des ECG, des questionnaires ou des observations cliniques relève du MDR.
Le MDCG 2019-11 donne le test. Un logiciel est un dispositif médical de diagnostic in vitro lorsque son objectif prévu inclut la fourniture d'informations dérivées de l'examen in vitro d'échantillons : interprétation d'un test génétique, calcul d'un score de risque à partir de valeurs de laboratoire, signalement d'un résultat comme diagnostique d'une affection, contrôle d'un analyseur. Un logiciel est un dispositif médical sous le MDR lorsque les informations proviennent d'autres sources : imagerie, ECG, capteurs, questionnaires, observations cliniques. L'origine de l'échantillon des données, et non l'endroit où le logiciel s'exécute, est déterminante.
Exemples relevant de l'IVDR : logiciel qui calcule un stade de maladie rénale basé sur l'eGFR et le qualifie comme tel pour le diagnostic ; un outil de conseil tumoral qui interprète des variants de séquençage ; un middleware qui valide et libère automatiquement les résultats d'analyseur. Sous le MDR : une application qui évalue un questionnaire sur la dépression ; une IA de radiologie ; une alerte de tendance de la pression artérielle. N'est pas un dispositif sous l'un ou l'autre : un enregistrement qui stocke et affiche les résultats de laboratoire avec les indicateurs et les plages de référence du laboratoire, car il ne crée aucune nouvelle information médicale.
Côte à côte
Parallèlement, le MDR (2017/745) et l'IVDR (2017/746) diffèrent par leur champ d'application (dispositifs utilisant des données du corps versus dispositifs examinant des échantillons), leurs classes (I à III versus A à D), l'implication des organismes notifiés (environ un tiers des dispositifs versus 80 à 90 % des DM-DIV), les preuves (évaluation clinique versus évaluation des performances) et les délais de transition, tout en partageant les normes ISO 13485, IEC 62304, UDI et la base de données EUDAMED.
| MDR 2017/745 | IVDR 2017/746 | |
|---|---|---|
| Champ d'application | Dispositifs agissant sur le corps ou utilisant des données provenant de celui-ci | Dispositifs examinant des échantillons provenant du corps, y compris les logiciels |
| Classes | I, IIa, IIb, III | A, B, C, D |
| Règle logicielle | Annexe VIII Règle 11 | Règles de l'Annexe VIII selon l'usage prévu ; le logiciel pilotant ou influençant un dispositif prend sa classe ; le logiciel IVD autonome est classifié selon son propre objectif (règles 1-7) |
| Organisme notifié | Pas pour la classe I (sauf Im/Is/Ir) | Pas pour la classe A non stérile uniquement ; B, C, D toujours |
| Part nécessitant un organisme notifié | Environ un tiers des dispositifs | Environ 80-90 % des DIV |
| Preuves cliniques | Évaluation clinique (Annexe XIV) | Évaluation des performances : validité scientifique, performance analytique et clinique (Annexe XIII) |
| Date d'application | 26 mai 2021 | 26 mai 2022 |
| Transition pour les dispositifs existants | Prolongée par le Règlement 2023/607 jusqu'en 2027-2028 par classe | Prolongée par le Règlement 2024/1860 jusqu'en décembre 2027 (D), décembre 2028 (C), décembre 2029 (B, A stérile) |
| Point commun | SMQ (ISO 13485), IEC 62304, ISO 14971, UDI, EUDAMED, surveillance post-commercialisation, vigilance, RPPC | Identique |
Classes IVDR pour les logiciels
L'IVDR classe les logiciels de diagnostic in vitro en fonction des conséquences d'un résultat erroné pour l'individu et pour la santé publique : classe D pour le dépistage transfusionnel et les maladies transmissibles potentiellement mortelles, classe C pour la plupart des tests diagnostiques, pronostiques, génétiques et compagnons, classe B par défaut, et classe A pour l'usage général en laboratoire. Un logiciel qui interprète un test hérite de la classe de ce test.
L'IVDR classe en fonction de la conséquence d'un résultat erroné pour l'individu et pour la santé publique. Classe D : détection d'agents transmissibles dans le sang destiné à la transfusion, maladies potentiellement mortelles avec un risque élevé de propagation (VIH, hépatite). Classe C : la plupart des tests diagnostiques et pronostiques où un résultat erroné pourrait entraîner la mort ou une incapacité grave, y compris les diagnostics compagnons, les tests génétiques, les marqueurs tumoraux, le dépistage. Classe B : le défaut pour tout ce qui n'est pas couvert ailleurs, et l'autotest pour les paramètres non critiques. Classe A : réactifs et instruments pour usage général en laboratoire, récipients pour échantillons, et logiciels dont l'objectif est uniquement l'usage général en laboratoire. Un logiciel qui interprète le résultat d'un test de classe C hérite de la classe C.
Pourquoi l'IVDR est perçu comme plus lourd
L'IVDR est perçu comme plus contraignant que le MDR car la plupart des diagnostics in vitro étaient auto-certifiés sous la directive précédente, alors que sous l'IVDR, la grande majorité nécessite un organisme notifié, moins d'organismes notifiés sont désignés pour les DM-DIV, et l'évaluation des performances exige une validité scientifique, une performance analytique et une performance clinique documentées que les équipes logicielles produisaient rarement auparavant.
Sous la directive précédente, la plupart des DIV étaient auto-certifiés. Sous l'IVDR, la grande majorité nécessite un organisme notifié, et il y a moins d'organismes notifiés désignés pour les DIV que pour les dispositifs MDR. L'évaluation des performances demande trois choses que les équipes de développement logiciel documentaient rarement auparavant : la validité scientifique (ce marqueur est-il lié à cette affection ?), la performance analytique (le logiciel le calcule-t-il correctement pour différentes entrées ?) et la performance clinique (le résultat aide-t-il dans la population visée ?). C'est pourquoi les délais de transition ont été prolongés deux fois.
Logiciels qui font les deux
Un logiciel qui interprète à la fois des données d'échantillons (valeurs de laboratoire) et des données non-échantillons (ECG) a deux usages prévus et est classé à la fois sous l'IVDR et le MDR, avec une évaluation de conformité pour chacun, souvent par le même organisme notifié sous un système qualité unique. Maintenir le module DM-DIV séparable, avec son propre usage prévu et dossier de risque, évite de rouvrir les deux évaluations.
La conception modulaire aide : gardez le module DM-DIV séparable, avec son propre usage prévu, dossier de risque et classe IEC 62304, de sorte qu'une modification du module MDR ne rouvre pas l'évaluation DM-DIV.
Ce que cela signifie pour un dossier de santé
Pour un dossier de santé, stocker un rapport de laboratoire, afficher des valeurs avec les unités du laboratoire, les indicateurs et les plages de référence, convertir les unités, tracer les tendances et partager le rapport avec un clinicien ne créent aucune information diagnostique, donc ni l'IVDR ni le MDR ne s'appliquent. Indiquer ce qu'une valeur signifie pour la santé de la personne fait du logiciel un DM-DIV, généralement de classe B ou C.
Stocker un rapport de laboratoire, afficher les valeurs avec les unités, indicateurs et plages de référence du laboratoire, convertir les unités avec un facteur publié, tracer une tendance et partager le rapport avec un clinicien ne créent aucune nouvelle information diagnostique : pas d'IVDR, pas de MDR. Dès que le logiciel indique ou implique ce que la valeur signifie pour la santé de la personne (un stade, une probabilité, une recommandation), il devient un logiciel IVD et, pour la plupart des analytes, de classe B ou C. Anpheros reste du premier côté de cette ligne par conception, et ses fonctionnalités de laboratoire affichent ce que le laboratoire a rapporté, converti et ordonné dans le temps, avec les propres indicateurs d'interprétation du laboratoire ; voir Comment lire vos résultats de laboratoire et Logiciel en tant que dispositif médical.
Cette page explique la réglementation pour les équipes produit et ingénierie. Ce n'est pas un avis juridique ; les textes liés dans Sources font autorité, et votre délégué à la protection des données, organisme notifié ou conseiller décide pour votre cas. Dernière révision : octobre 2026.
Pages connexes
- Logiciel en tant que dispositif médical : classes MDR et IEC 62304
- Une application de santé est-elle un dispositif médical ? Règle 11 du MDR de l'UE
- Comment lire vos résultats de laboratoire
- FHIR DiagnosticReport expliqué
- Carte de la réglementation des données de santé
Sources
- Règlement (UE) 2017/746 (IVDR), EUR-Lex
- Règlement (UE) 2017/745 (MDR), EUR-Lex
- Règlement (UE) 2024/1860 (extension de transition IVDR), EUR-Lex
- Règlement (UE) 2023/607 (extension de transition MDR), EUR-Lex
- MDCG 2019-11 : Qualification et classification des logiciels (MDR et IVDR)
- Commission européenne : dispositifs médicaux de diagnostic in vitro
Questions fréquentes
Un convertisseur d'unités de laboratoire est-il un DIV ?
Non. Convertir mg/dL en mmol/L avec un facteur publié ne crée pas d'informations diagnostiques ; cela reformule le résultat du laboratoire. Ajouter une interprétation de la valeur convertie le ferait.
Mon logiciel affiche uniquement les résultats d'analyseur au laboratoire. Quelle réglementation ?
S'il affiche et transmet uniquement, aucune des deux. S'il valide, libère automatiquement ou signale les résultats par rapport à des règles qu'il applique lui-même, il pilote le processus diagnostique et relève de l'IVDR, généralement dans la classe des tests qu'il traite.
Lequel a la transition la plus longue ?
L'IVDR, après le Règlement 2024/1860 : dispositifs existants de classe D jusqu'à fin 2027, classe C jusqu'à fin 2028, classes B et A stérile jusqu'à fin 2029, à condition que le fabricant ait déposé une demande auprès d'un organisme notifié en temps voulu.
La FDA fait-elle la même distinction ?
La FDA réglemente les DIV comme une catégorie de dispositifs médicaux sous la même loi, le Center for Devices and Radiological Health traitant des deux. La logique de classification diffère dans les détails, mais la question de savoir si les données proviennent d'un échantillon est également pertinente là-bas.
Essayez gratuitement dans le sandbox
Votre premier appel FHIR en 5 minutes. Une API HL7 FHIR R4 avec le consentement du patient intégré : essayez-la dans le bac à sable, puis connectez votre propre application ou système de clinique.
Gratuit · 30 patients synthétiques · sans carte
Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.
À propos d'Anpheros →