Le Registre central de traçabilité collecte les notifications relatives à la pose et au retrait d'implants médicaux. Les prestataires de soins enregistrent et consultent via des services web ; SADMI donne en outre accès à la source authentique des dispositifs eux-mêmes. Pour les implants désignés, la notification est obligatoire et l'accès exige une relation thérapeutique. Les hôpitaux ont besoin pour cela d'une interface système et doivent tenir compte de la transition de version des services SADMI.
", "last_verified": "2026-11-10", "verification_outdated": false, "sections": [ { "id": "in-het-kort", "title": "In het kort", "kind": "in-het-kort", "html": "Le Registre central de traçabilité (CTR) collecte, dans le cadre du Plan Medische Hulpmiddelen, les notifications relatives à la pose et au retrait d'implants médicaux[1]. Selon le catalogue de production de la Plate-forme eHealth, le projet centralise les notifications relatives au cycle de vie d'un implant au moyen d'une banque de données, d'une interface utilisateur et d'un couplage de système à système[7]. Via le service web CTR, les prestataires de soins et les institutions de soins enregistrent ou consultent la pose ou le retrait d'implants chez les patients qu'ils traitent[1].
\nOutre le registre, il existe une source authentique des dispositifs eux-mêmes : tous les dispositifs médicaux implantables présents sur le marché belge figurent, au sein de l'AFMPS, dans l'Authentieke Bron van de Medische Hulpmiddelen, qui est publique et consultable via un service web (SADMI)[3].
\nLe CTR rend les implants traçables jusqu'au patient et permet à l'AFMPS de prendre des mesures à l'égard des acteurs concernés en cas d'incidents graves avec un type d'implant[2]. Selon l'AFMPS (2020), le patient peut lui aussi consulter via l'application web toutes les notifications d'implantations et d'explantations qui le concernent[8] ; il se connecte pour cela via un navigateur web et un lecteur eID ou itsme[8]. La source ne dit pas si cette application web est aujourd'hui accessible via Masanté (voir questions ouvertes).
" }, { "id": "comment-le-registre-est-il-structure", "title": "Comment le registre est-il structuré ?", "kind": "tekst", "html": "Statut : production. L'AFMPS figure sur la page eSanté comme institution responsable[2]. La base légale est l'article 51 de la loi du 15 décembre 2013 relative aux dispositifs médicaux ; l'AR du 27 septembre 2020 rend obligatoire, à partir du 1er mai 2021, la notification des implants repris en annexe[4]. Depuis avril 2014, la notification était déjà possible, mais non obligatoire, pour tous les implants[8]. Outre la notification obligatoire pour les implants listés, les professionnels des soins de santé peuvent aussi déclarer volontairement toutes les autres implantations[2].
\nL'AFMPS distingue trois groupes d'utilisateurs : les hôpitaux utilisent le service web[8], les cliniques privées une application web accessible avec un lecteur eID ou itsme[8], et les patients la même application web pour consulter leurs propres notifications[8].
\nCelui qui consulte le registre ou déclare une implantation ou une explantation doit avoir une Relation thérapeutique avec le patient ; du personnel administratif peut préparer une notification que le prestataire de soins valide[4].
\nDu côté des dispositifs, les entreprises qui mettent des dispositifs médicaux implantables sur le marché en Belgique doivent s'enregistrer par voie électronique auprès de l'INAMI et communiquer les détails de ces dispositifs[9].
\nService web CTR (SOAP). Le CTR KMEHR Cookbook décrit les messages KMEHR des services web CTR, en complément du cookbook SOAP technique[1].
\nCTR REST. Selon le catalogue de production, l'API REST permet aux prestataires de soins et à leurs systèmes de gérer les notifications d'implantations et de retraits[7]. Pour une utilisation comme service REST, l'intégration doit être demandée via une procédure d'onboarding (Onboarding I.AM Connect RCT V2, version 1.0 du 11/03/2022)[1] ; voir I.AM Connect.
\nFHIR. Le document CTR-FHIR (version 0.2, 22/10/2020) complète le cookbook REST ; seules les méthodes qui transmettent de l'information médicale ont été converties vers HL7 FHIR[1].
\nSADMI. Avec le service web SADMI, les acteurs de soins consultent des données relatives à un dispositif, comme le nom, le code de notification du dispositif et le numéro de notification du distributeur (cookbook v2.2, endpoints /Sadmi/v3)[10].
\nIndépendamment du CTR, HD4DP v2 envoie, pour quelques collectes de données (entre autres des implants comme les défibrillateurs et les prothèses de hanche et de genou), des données nominatives en parallèle vers l'interface MyCareNet du Collège Intermutualiste National, afin de satisfaire à l'obligation administrative de déclaration auprès des organismes assureurs[11] ; voir aussi MyCareNet.
\nÉtat du registre des API au 28 septembre 2026 (catalogues de production et d'acceptation de la Plate-forme eHealth) :
\n| API | \nInterface et version | \nEnvironnement | \nCommentaire | \n
|---|---|---|---|
| RCT | \nSOAP 1.0 | \nproduction et acceptation | \nservice web CTR (enregistrer et consulter)[7] | \n
| RCT REST | \nREST 1.0 | \nproduction et acceptation | \ngérer les notifications via REST, onboarding via I.AM Connect[7][1] | \n
| Sadmi | \nSOAP 2.0 | \nproduction | \nretrait annoncé dans la release R20262 (prévu 13-20/10/2026)[6][6] | \n
| Sadmi | \nSOAP 3.0 | \nproduction et acceptation | \nconsultation des données de dispositifs (cookbook v2.2)[10] | \n
| Sadmi | \nSOAP 4.0 | \nacceptation uniquement | \ncontrat EUDAMED, production annoncée avec R20262[6][6] | \n
Sadmi v4 (EUDAMED, prévu). Selon les release notes de R20262 (un document de planification), cette release introduit une nouvelle version du service SOAP SADMI, /Sadmi/v4, avec un contrat adapté à l'intégration avec EUDAMED (champs ajoutés, supprimés ou renommés)[6]. Selon le principe canary, R20262 doit passer en production du 13 au 20 octobre 2026[6] ; au 28 septembre 2026, /Sadmi/v4 ne figure que dans le catalogue d'acceptation[6].
\nSadmi v3. Les intégrations existantes sur /Sadmi/v3 ne subissent aucun impact tant que v3 reste disponible ; qui veut le contrat EUDAMED doit migrer explicitement vers /Sadmi/v4[6]. Les release notes ne mentionnent pas de date de retrait pour v3 (voir questions ouvertes).
\nSadmi v2 (retrait prévu). La release R20262 (production prévue du 13 au 20 octobre 2026) mettra Sadmi v2 hors service ; les utilisateurs doivent passer à /Sadmi/v3 ou /Sadmi/v4[6][6]. Ce n'est qu'après une nouvelle vérification dans le catalogue des API, après la release, que l'Atlas pourra mentionner v2 comme retiré.
\nObligation : depuis le 1er mai 2021, la notification de la pose ou du retrait est obligatoire pour les implants repris en annexe de l'AR du 27 septembre 2020[8].
\nCanal : pour tous les hôpitaux, le service web CTR est le seul canal d'interaction avec le registre[1]. Il s'agit d'un couplage machine-to-machine ; l'intégration dans le système informatique d'un hôpital exige le développement d'un connecteur spécifique[8].
\nRègle d'accès : le déclarant ou celui qui consulte a besoin d'une relation thérapeutique avec le patient ; du personnel administratif peut préparer, le prestataire de soins valide[4].
\nMigration SADMI : un hôpital qui récupère des données de dispositifs via Sadmi v2 doit passer à v3 ou v4 avant le retrait prévu avec R20262[6].
\nRecommandation (propre) : vérifiez quelle application appelle Sadmi dans l'hôpital et sur quelle version, et choisissez consciemment entre v3 (pas d'impact tant qu'elle reste disponible) et v4 (contrat EUDAMED, champs modifiés).
\nUne utilisation comme service REST exige une demande d'onboarding distincte[1]. Pour la variante FHIR, seules les méthodes contenant de l'information médicale ont été converties, et le document est une version 0.2 de 2020[1].
\nHistorique incomplet. Comme l'obligation de notification ne s'applique qu'à partir du 1er mai 2021 pour les implants repris en annexe de l'AR du 27/09/2020, des notifications antérieures à cette date ou portant sur des implants non listés peuvent manquer dans le CTR[8]. Une consultation vide ne prouve donc pas qu'un patient n'a pas d'implant (interprétation).
" }, { "id": "incertitudes-et-informations-contradictoires", "title": "Incertitudes et informations contradictoires", "kind": "tekst", "html": "Seul canal ou aussi interface utilisateur ? La page du service qualifie le service web de seul canal d'interaction pour les hôpitaux[1], alors que la description du catalogue mentionne aussi une interface utilisateur[7]. Ce n'est pas une véritable contradiction : selon l'AFMPS, les hôpitaux utilisent le service web[8] et les patients l'application web[8]. La même page de l'AFMPS destine aussi l'application web aux cliniques privées[8].
\nDeux institutions autour des données de dispositifs. Les entreprises déclarent leurs dispositifs implantables par voie électronique auprès de l'INAMI[9], alors que la source authentique de ces dispositifs se trouve au sein de l'AFMPS[3]. La manière dont ces deux flux de données s'articulent n'a pas été trouvée.
\nDénomination. Le même service s'appelle CTR (page du service), RCT (catalogue des API) et CRT (description du projet dans le catalogue)[1][7].
\nStatut FHIR. Rien n'a été trouvé sur la question de savoir si la spécification CTR-FHIR (v0.2, 2020) a encore été développée après 2020[1].
\n