Logiciel dispositif médical (MDR)

Quand un logiciel utilisé dans les soins est-il un dispositif médical, dans quelle classe de risque relève-t-il et qu'est-ce que cela implique pour l'achat, le développement interne et le remboursement en Belgique ?

Qualification : s'agit-il d'un dispositif médical ?

Un logiciel à usage général n'est pas un dispositif médical, même lorsqu'il est utilisé dans un environnement de soins.^[1] Selon la guidance non contraignante MDCG 2019-11 rev.1 (juin 2025), un logiciel utilisé dans les soins peut comprendre à la fois des modules médicaux et non médicaux.^[2] Relève de l'IVDR le logiciel destiné à l'examen in vitro d'échantillons provenant du corps humain, à condition qu'il réponde également à la finalité requise en matière d'information.^[3]

Classification : règle 11 du MDR et règle 1.4 de l'IVDR

Interprétation : la règle 11 tient compte de l'incidence possible de la décision fondée sur les informations fournies par le logiciel, et non de la technologie ; même une aide à la décision simple peut ainsi relever de la classe IIa ou d'une classe supérieure.^[1] La catégorie résiduelle de la règle 11 (« tous les autres logiciels ») n'a pas encore été consignée sous forme de claim dans l'Atlas.

Conformité et évaluation clinique

La démonstration de la conformité aux exigences générales en matière de sécurité et de performances comprend une évaluation clinique conformément à l'art. 61 du MDR.^[1] Le Règlement sur l'IA renvoie expressément au MDR et à l'IVDR, en vertu desquels les produits à risque moyen et élevé font l'objet d'une évaluation par un tiers.^[4]

Logiciels internes (MDR, art. 5(5))

Pour les dispositifs fabriqués et utilisés exclusivement au sein d'une institution de soins établie dans l'Union, les exigences du MDR ne s'appliquent pas, à l'exception des exigences générales pertinentes en matière de sécurité et de performances énoncées à l'annexe I et à condition que toutes les conditions de l'art. 5(5) soient remplies.^[1] Ces conditions comprennent notamment les suivantes :

• le dispositif n'est pas transféré à une autre entité juridique ;^[1]
• la fabrication et l'utilisation sont effectuées dans le cadre d'un système de gestion de la qualité approprié ;^[1]
• l'institution justifie dans sa documentation que les besoins spécifiques du groupe cible de patients ne peuvent pas être satisfaits, ou ne peuvent pas l'être au niveau de performances approprié, par un dispositif équivalent disponible sur le marché ;^[1]
• l'institution examine l'expérience issue de l'utilisation clinique et prend toutes les mesures correctives nécessaires.^[1]

Mise en œuvre belge (AFMPS) : l'institution de soins établit la déclaration de fabrication au moyen du portail web de l'AFMPS.^[5] Les incidents graves et les mesures correctives relatifs aux dispositifs internes doivent être notifiés à l'AFMPS.^[6] L'AFMPS décrit la surveillance des logiciels médicaux, y compris les applications d'IA, pendant tout leur cycle de vie.^[7]

Remboursement des applications médicales mobiles (INAMI)

L'INAMI définit notamment une application médicale mobile comme un logiciel portant le marquage CE en tant que dispositif médical et notifié à l'AFMPS.^[8] Depuis le 1er octobre 2023, les fabricants, les associations scientifiques ou professionnelles et les hôpitaux peuvent demander à l'INAMI qu'une telle application soit intégrée dans un processus de soins remboursé.^[8] Dans la Télésurveillance et orientation thérapeutique en cas d'insuffisance cardiaque chronique, l'application mobile doit porter le marquage CE en tant que dispositif médical.^[9] Dans ce cadre, toute la technologie utilisée, à l'exception d'une balance non connectée, doit être un dispositif médical portant le marquage CE.^[10] L'INAMI ne rembourse pas des applications spécifiques, mais un parcours de soins, et n'établit donc pas de listes d'applications approuvées.^[11]

mHealthBelgium : fin 2023, la collaboration entre l'INAMI, beMedTech et Agoria pour la gestion de la plate-forme a pris fin ; beMedTech et Agoria poursuivent ensemble la plate-forme.^[12] La demande de validation est désormais introduite directement auprès de l'INAMI plutôt qu'auprès de mHealthBelgium.^[12] La liste des applications pour l'insuffisance cardiaque sur mHealthBelgium est gérée par beMedTech et Agoria, et non par l'INAMI.^[11]

Constat : la qualification d'un logiciel comme dispositif médical et la classe dont il relève dépendent de l'utilisation prévue par le fabricant et de l'incidence possible des décisions qui s'appuient sur ce logiciel.^[1][1] Pour l'IA intégrée dans des dispositifs pour lesquels le MDR ou l'IVDR exige une évaluation de la conformité par un tiers, le régime à haut risque du Règlement sur l'IA s'ajoute à partir du 2 août 2028.^[13][4] Interprétation : pour les dispositifs qui ne sont pas soumis à une évaluation obligatoire par un tiers (comme les logiciels de classe I sans organisme notifié), cette voie fondée sur le produit ne s'applique pas.

Recommandation : tenez un registre des logiciels cliniques et des modules du DPI, en indiquant pour chaque module l'utilisation prévue, la qualification et la classe au titre du MDR/de l'IVDR, le statut CE et, en cas de développement interne, les pièces justificatives requises par l'art. 5(5).

Relations avec d'autres concepts

Voir le frontmatter ; les principaux liens sont Règlement sur l'IA et IA dans les soins, Télésurveillance en Belgique et Exigences EHDS pour les systèmes de DME (chapitre III).

• Obligation légale (développement interne) : les logiciels médicaux internes sont soumis aux conditions de l'art. 5(5) du MDR, à une déclaration de fabrication au moyen du portail de l'AFMPS et à l'obligation de notifier les incidents graves.^[1][5][6]
• Achat : les progiciels de DPI peuvent combiner des modules médicaux et non médicaux ; chaque module doit donc être qualifié séparément (guidance non contraignante).^[2]
• Achat (à l'avenir, à partir de 2029/2031) : les fabricants de dispositifs médicaux et de dispositifs IVD qui revendiquent l'interopérabilité avec les composants logiciels harmonisés des systèmes de DME doivent démontrer leur conformité aux exigences essentielles (EHDS, art. 27(1)).^[14] L'art. 27 de l'Espace européen des données de santé ne s'applique qu'à partir du 26 mars 2029 ou du 26 mars 2031, selon la catégorie de données de santé (art. 105).^[14] Il ne s'agit donc pas aujourd'hui d'une obligation d'achat en vigueur. Pour l'IA à haut risque qui ne relève pas du MDR/de l'IVDR, l'art. 27(2) s'applique ; voir Règlement sur l'IA et IA dans les soins.^[14]
• Condition de financement : pour les applications mobiles remboursées, comme celles utilisées pour la télésurveillance en cas d'insuffisance cardiaque, le marquage CE en tant que dispositif médical est requis.^[8][9]
• Recherche : le projet SHAIPED de l'Agence des données de santé étudie le développement et l'utilisation d'outils d'IA comme dispositifs médicaux ; il s'agit de recherche, et non d'une autorisation pour les soins courants.^[15]

Conditions et limites de mise en œuvre

L'exception applicable aux dispositifs internes cesse dès qu'un logiciel est transféré à une autre entité juridique.^[1] Interprétation : cela concerne le développement partagé au sein de réseaux hospitaliers constitués de personnes morales distinctes ; l'interprétation belge de ce point n'a pas été étudiée. Même pour les logiciels internes, un système de gestion de la qualité et le suivi de l'utilisation clinique restent nécessaires.^[1][1]

• Informations contradictoires (mHealthBelgium) : selon l'INAMI, la pyramide de validation ne fait plus partie de la nouvelle procédure, et la demande comme l'approbation passent entièrement par l'INAMI.^[11] Le site web de mHealthBelgium présente encore une pyramide à trois niveaux, dont le niveau 1 correspond à un dispositif médical certifié CE et le niveau 3 aux applications financées par l'INAMI (présentation propre à la plate-forme).^[16] Recommandation : considérez la pyramide comme historique et non comme une condition de remboursement en vigueur.
• Lacunes : droit transitoire du MDR/de l'IVDR par produit ; date de l'art. 5(5)(d) de l'IVDR (non vérifiée sous forme de claim ; ne pas transposer le délai du MDR à l'IVDR) ; catégorie résiduelle de la règle 11 ; interprétation belge d'« entité juridique » (circulaire 655).
• Il ne s'agit pas d'une qualification complète propre à un produit : la classe au titre du MDR/de l'IVDR et la classe de risque de l'IA doivent être évaluées séparément en fonction de l'utilisation prévue, des conséquences et de la procédure d'évaluation de la conformité.