Un logiciel relève des règles européennes sur les dispositifs médicaux lorsque le fabricant lui assigne une finalité médicale ; un logiciel d'usage général ne le devient pas du seul fait de son utilisation dans les soins. La règle 11 du MDR classe les logiciels d'aide à la décision et de monitoring selon les conséquences possibles, tandis que les logiciels IVD suivent l'IVDR. Pour les logiciels fabriqués et utilisés en interne, les institutions de soins ne peuvent appliquer une exception que sous conditions. Pour les hôpitaux, cela concerne l'achat, le développement, l'évaluation clinique, la notification d'incidents et certaines applications mobiles remboursées.
", "last_verified": "2026-10-05", "verification_outdated": false, "sections": [ { "id": "de-quoi-s-agit-il", "title": "De quoi s'agit-il ?", "kind": "tekst", "html": "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 ?
" }, { "id": "qu-est-ce-qui-est-obligatoire-pour-qui-et-a-quelles-conditions", "title": "Qu'est-ce qui est obligatoire, pour qui et à quelles conditions ?", "kind": "tekst", "html": "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]
\n| Fonction du logiciel | \nClasse | \nSource | \n
|---|---|---|
| Informations utilisées pour prendre des décisions à des fins diagnostiques ou thérapeutiques (règle de base) | \nIIa[1] | \nMDR, annexe VIII, règle 11 | \n
| Idem, si les décisions peuvent entraîner une grave détérioration de l'état de santé ou une intervention chirurgicale | \nIIb[1] | \nMDR, règle 11 | \n
| Idem, si les décisions peuvent entraîner le décès ou une détérioration irréversible de l'état de santé | \nIII[1] | \nMDR, règle 11 | \n
| Surveillance de processus physiologiques | \nIIa[1] | \nMDR, règle 11 | \n
| Surveillance de paramètres physiologiques vitaux dont les variations peuvent présenter un danger immédiat | \nIIb[1] | \nMDR, règle 11 | \n
| Logiciel IVD qui commande un dispositif ou influe sur l'utilisation de ce dispositif | \nMême classe que ce dispositif[3] | \nIVDR, annexe VIII, 1.4 | \n
| Logiciel IVD indépendant | \nClassé à part entière[3] | \nIVDR, annexe VIII, 1.4 | \n
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.
\nLa 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]
\nPour 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 :
\nMise 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]
\nL'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]
\nmHealthBelgium : 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]
" }, { "id": "en-vigueur-depuis-quand-quelles-sont-les-prochaines-etapes", "title": "En vigueur depuis quand, quelles sont les prochaines étapes ?", "kind": "tekst", "html": "| Moment | \nÉtat ou prochaine étape | \n
|---|---|
| Cadre en vigueur | \nLe MDR et l'IVDR déterminent la qualification, la classification et la conformité des logiciels médicaux[1][3] | \n
| Depuis le 1er octobre 2023 | \nLes demandes d'intégration d'une application médicale mobile dans un processus de soins remboursé passent par l'INAMI[8] | \n
| Juin 2025 | \nMDCG 2019-11 rev.1 décrit les modules logiciels médicaux et non médicaux dans une guidance non contraignante[2] | \n
| À partir du 2 août 2028 | \nLe régime à haut risque du Règlement sur l'IA s'ajoute pour certains produits relevant du MDR et de l'IVDR[13][4] | \n
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.
\nRecommandation : 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).
\nVoir 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).
" }, { "id": "qu-est-ce-que-cela-signifie-pour-un-hopital", "title": "Qu'est-ce que cela signifie pour un hôpital ?", "kind": "tekst", "html": "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]
" }, { "id": "incertitudes-et-informations-contradictoires", "title": "Incertitudes et informations contradictoires", "kind": "tekst", "html": "