Guides d'implémentation FHIR belges

• Quoi : les guides d'implémentation FHIR belges sont les paquets hl7.fhir.be.* que la plate-forme eHealth publie sur ehealth.fgov.be/standards/fhir ; le portail en énumère 18, dont DRP est deprecated au profit de Referral^[1][2].

• Comment : des groupes de travail de HL7 Belgium élaborent les profils et une équipe de validation les valide ^[3] ; les guides du portail s'appuient sur FHIR R4 (4.0.1) et appartiennent à la série de publication 'Trial Use'^[4].

• État : la release la plus récente est BE Public Health 1.0.4 du 18 septembre 2026^[5] ; au 8 octobre 2026, Glucose Monitoring et Patient Monitoring Outcome sont encore des CI-builds sans publication autorisée^[6][7] ; pour Glucose Monitoring 1.0.0, une demande de publication figure dans le repository ; il s'agit d'une préparation, pas d'une publication^[8][6].

• Où utilisé : Vitalink documente Be Vaccination, Be Allergy Intolerance et Be Public Health ^[9] ; BE MyCareNet porte les flux eAgreement^[10] ; BE Core fixe la manière dont le numéro d'identification de la sécurité sociale figure dans une ressource patient^[11].

• Hôpital : la publication comme norme fédérale n'implique pas d'obligation légale automatique de mise en œuvre ^[3] ; qui implémente BE Core Clinical a besoin d'une licence SNOMED CT Affiliate^[12].

• Plus grande incertitude : selon sa propre page d'accueil, Referral 1.0.0 est encore en développement ^[13] et le guide labo reste work-in-progress^[14] ; 'Trial Use' est le nom de la série, pas une garantie que les profils resteront inchangés.

Un guide d'implémentation (IG) fixe la manière dont un pays ou un secteur utilise la norme internationale HL7 FHIR : quels champs sont obligatoires, quels codes sont autorisés et comment les ressources sont liées entre elles. Les IG belges sont les paquets hl7.fhir.be.* : profils, extensions, ValueSets et exemples construits par-dessus FHIR. La Plate-forme eHealth publie, lorsque c'est nécessaire, des profils FHIR et des IG spécifiques pour des initiatives fédérales sur ehealth.fgov.be/standards/fhir^[1]. Le principe est d'utiliser FHIR au plus près de la norme de base et de n'ajouter que les nuances belges^[15]. La ressource ImplementationGuide de BE Core 2.2.0 a l'eHealth Platform comme publisher^[16] et la licence CC0-1.0^[16].

Pourquoi ils sont nécessaires : la seule conformité internationale à FHIR ne suffit pas, les systèmes doivent utiliser les mêmes normes et conventions nationales^[17] ; selon le BIHR, un serveur de terminologie ainsi que des ValueSets, CareSets et bindings cohérents sont importants à cet effet^[17]. Les IG fixent ces conventions par domaine, et chaque initiative CareSet de l'INAMI doit partir de ressources FHIR^[18]. Selon les principes BIHR de l'INAMI, la seule conformité à FHIR ne rend pas les données interopérables ; la conformité aux profils partagés est requise^[19]. Voir BIHR (Belgian Integrated Health Record).

La première phase (BE Core, Q4 2019) comprenait Patient, Practitioner, PractitionerRole, Organization, Observation, Provenance et AllergyIntolerance^[15].

Gestion et publication

Des groupes de travail de HL7 Belgium élaborent le modèle de données et les profils^[3] ; une équipe de validation de HL7 Belgium valide les artefacts et se réunit actuellement toutes les deux semaines^[3]. Il existe deux niveaux de publication : norme communautaire HL7 via HL7 Belgium et norme fédérale via la plate-forme eHealth^[3]. Le portail utilise un code couleur par type d'IG^[1] : « Build » pour les IG en développement^[1] et « Federal » pour les IG publiés par la plate-forme eHealth et validés comme artefacts fédéraux^[1]. Il existe aussi une catégorie « IG's Published by HL7Be », mais aucun des 18 IG n'en relève effectivement : tous ont la plate-forme eHealth comme éditeur^[1], et le registre international des IG FHIR cite lui aussi la plate-forme eHealth comme autorité^[20].

Un CareSet de BeSafeShare est publié comme profil FHIR belge dans l'IG destiné aux fournisseurs de logiciels^[21]. La publication comme norme fédérale n'implique pas automatiquement une obligation légale de les implémenter immédiatement^[3].

Versions, série et statut

La version, la date de release, la version FHIR et la série de publication de chaque IG proviennent du fichier package-list.json de cet IG. « Trial Use » y est la valeur du champ sequence (la série de publication) et non du champ status : pour BE Core, status vaut « release », sequence « Trial Use » et fhirversion 4.0.1^[4]. Seul BE Lab a lui-même « trial-use » comme status^[22]. Selon la documentation HL7, status est la phase du cycle de vie d'une version et sequence un regroupement facultatif dans une série^[23] ; « release » désigne une release sans statut particulier^[23], « trial-use » une spécification prête pour un usage d'essai^[23], et certaines valeurs de statut n'ont de sens que pour HL7 ou pour d'autres organismes de normalisation^[23]. Pour les IG belges, « Trial Use » est donc le nom de la série ; le champ de statut « release » ne dit rien sur la maturité formelle, sauf pour BE Lab. Aucune explication belge à ce sujet n'a été trouvée. La valeur trial-use dans le frontmatter de cette page suit la série.

Les 18 IG du portail ont tous fhirversion 4.0.1 ; les CI-builds Glucose Monitoring et Patient Monitoring Outcome ont également fhirVersion 4.0.1^[24][25]. BE Medication indique qu'il s'agit d'un IG R4 fonctionnant sans modification avec des systèmes R4B, avec des paquets R4 et R4B^[26] ; la question de savoir si cela vaut pour tous les IG n'a pas été examinée.

Niveaux de publication et état des lieux

Dans le catalogue packages2.fhir.org, BE Public Health 1.0.4 est au 29 septembre 2026 la release belge la plus récente ; depuis le 26 septembre, aucune nouvelle n'est parue^[5]. Pour Glucose Monitoring, le repository GitHub contient une demande de publication pour la version 1.0.0 avec le statut « release » et la série « Trial Use »^[8], alors que le CI-build n'est pas encore une publication autorisée^[6] ; la demande cite la plate-forme eHealth comme autorité de registre, de sorte que l'IG est préparé comme IG fédéral^[8]. Voir HL7 Belgium Patient Monitoring Outcome FHIR Implementation Guide et Télésurveillance en Belgique. Sur la branche release-candidate de hl7-be/terminology se trouve une demande de publication pour hl7.fhir.be.terminology 1.0.0 (« eHealth Terminology package for Belgium ») dans la série Trial Use^[29] ; voir Serveur national de terminologie (FHIR). Au 8 octobre 2026, les CI-builds de Glucose Monitoring (branche release-candidate, version 1.0.0) et de Patient Monitoring Outcome (version 0.1.0, CI-build de HL7 Belgium) sont des builds continus et non des publications autorisées^[6][7][28] ; pour Patient Monitoring Outcome, aucune demande de publication n'a été trouvée.

Audit du registre (8 octobre 2026). Pour chacun des 18 IG du portail, la version que le registre de paquets FHIR packages2.fhir.org marque comme latest a été comparée au tableau ci-dessous ; les versions sont identiques, chaque fois sur FHIR 4.0.1^{[31][32][33][34][35][36][30][37][38][39][40][41][42][43][44][45][46][47]}. Le paquet le plus ancien, BE Lab 1.0.0 du 8 septembre 2022, y est lui aussi toujours la version la plus récente^[36]. Pour deux IG, la date du registre diffère de la date du package-list figurant dans le tableau. BE Core Clinical 1.3.0 : registre 19/08/2026^[32], package-list 20/08/2026^[48] ; une différence d'un jour (probablement le fuseau horaire). BE Patient Care 1.1.0 : registre 26 novembre 2025^[41], package-list 10 octobre 2025^[49] ; la date du registre est probablement la date d'enregistrement et non la date de release. Le tableau conserve la date du package-list.

Répartition en paquets

Un document de HL7 Belgium, « Proposed Rules for creating separate packages » (version 1.0, 11 décembre 2024, approuvé au sein du groupe de travail FHIR WG Core), décrit la manière dont les paquets sont délimités^[50]. Il s'agit d'une proposition de règles ; la question de savoir si les IG existants y satisfont déjà n'a pas été examinée.

Selon les règles proposées, HL7 Belgium et la plate-forme eHealth s'efforcent de maintenir les profils et artefacts fonctionnellement cohérents dans le même paquet technique^[50] ; le critère principal pour un nouveau paquet est fonctionnel^[50]. Des critères techniques jouent également : des dépendances cycliques peuvent influencer le contenu d'un paquet^[50] et les critères techniques évitent des erreurs de compilation^[50]. Un paquet peut être créé lorsque le contenu des ressources devient trop spécifique^[50] ; des profils très spécifiques, trop étroitement liés à un seul cas d'usage, sont placés dans un nouvel IG^[50]. Le HL7 Belgium FHIR Validation Group est responsable de la création des IG^[50], et chaque IG est géré par exactement un groupe de travail de HL7 Belgium, tandis qu'un même groupe de travail peut gérer plusieurs IG^[50].

La proposition distingue trois couches. Selon la proposition, le paquet core contient des ressources de base comme BePatient, BePractitioner et le système de nommage SSIN^[50] et il ne peut recevoir que des références entrantes provenant d'autres paquets belges^[50]. Les paquets généraux contiendraient des profils valables au niveau belge, indépendamment d'un cas d'usage spécifique^[50], avec en principe uniquement des références sortantes vers le paquet core^[50] ; BeCarePlan, BeObservation et BeGoal en sont des exemples^[50]. Les paquets spécifiques imposeraient une couche propre à un cas d'usage et restreindraient surtout la cardinalité, les listes de valeurs, les systèmes de codes et les systèmes de nommage^[50] ; BeObesityGoal, BeDiabetesCarePlan et BeGlucoseObservation en sont des exemples^[50]. Selon la proposition, chaque ressource spécifique est conçue, à titre de bonne pratique, comme un raffinement d'une ressource générale^[50] ; une infrastructure capable de traiter une BeObservation doit, selon la proposition, prendre en charge également une BeGlucoseObservation^[50].

Il existe aussi un CI-build d'un « HL7 Belgium terminology IG » (hl7.fhir.be.terminology) avec un canonical sous hl7belgium.org^[51] ; ce build indique explicitement que l'IG ne doit pas être utilisé parce que la propriété et la gouvernance des terminologies font défaut^[51]. La demande de publication sur la branche release-candidate du même repository (hl7-be/terminology) utilise le même package-id hl7.fhir.be.terminology et renvoie au même CI-build^[29]. Le rapport entre cet avertissement et la publication préparée n'a pas été trouvé.

Terminologie

SNOMED CT est le codage préféré dans les profils fédéraux^[52] ; les ValueSets de BE Core Clinical sont expansés via dte-tx.ehealth.fgov.be sur la base de l'édition belge de SNOMED CT^[53]. Dans BE Lab, les résultats de laboratoire doivent être codés en LOINC selon le sous-ensemble du SPF, sinon en codes Albert^[54], avec les unités en UCUM^[54]. BE Core Clinical 1.3.0, BE Core 2.2.0 et BE Public Health 1.0.4 utilisaient dte-tx.ehealth.fgov.be/r4 comme serveur de terminologie primaire lors de leur publication^[55][56][57] ; la release plus ancienne BE Medication 1.1.1 utilisait encore tx.fhir.org^[58], et dans le rapport de build de BE PSS 1.1.0, l'Ontoserver du SPF faisait office de serveur autoritatif pour SNOMED CT^[59]. Voir SNOMED CT et Serveur national de terminologie (FHIR).

Aperçu par IG

Les bannières de publication confirment les versions et la base FHIR R4 ; BE Core 2.2.0 et BE Public Health 1.0.4 étaient au 25 septembre 2026 les versions publiées^[60][61]. La date de release est la date de publication selon package-list.json. La colonne « Série » correspond au champ sequence ; sauf mention contraire, status vaut « release ».

« … » représente https://www.ehealth.fgov.be/standards. Un tiret dans la colonne Terminologie signifie qu'aucun claim n'étaye un binding de terminologie. Pour les CI-builds, la date figurant dans le manifeste est une date de build et non une date de release.

• Vitalink et les coffres-forts santé : la documentation FHIR de Vitalink pour les fournisseurs de logiciels contient une section sur l'IG Be Public Health pour les dépistages de population du cancer du CVKO^[9], et des sections sur Be Vaccination et Be Allergy Intolerance^[9]. Les trois coffres-forts santé régionaux ont publié un FHIR cookbook commun, d'abord pour les allergies avec le profil BeAllergyIntolerance^[93]. Les immunisations sont le principal type de données dans Vitalink FHIR^[94]. La version de l'IG que Vitalink prend en charge ne ressort pas du texte de tableau cité, qui renvoie seulement à « de laatst ondersteunde versie »^[9]. Voir Vitalink.
• Médication : BE Medication définit entre autres BeMedicationLine (la contrepartie FHIR d'une ligne de schéma de médication partagé), BeMedicationDispense et BeMedicationPrescription^[69], et a été développé par la communauté HL7 Belgium^[26]. Voir Schéma de médication partagé.
• MyCareNet (eAgreement) : la Plate-forme eHealth publie l'IG Belgian MyCareNet Profiles avec l'équipe MyCareNet comme base pour des use cases MyCareNet^[10]. Ce sont surtout des profils eAgreement : un profil MessageHeader générique^[95] et des profils Claim pour la kinésithérapie et la logopédie^[95]. La version 1.0 (2021-07-01, FHIR R4) a ajouté les premiers profils eAgreement^[73] ; les versions 2.1.0 à 2.1.2 ont paru le 2025-02-17 et la 2.2.0 le 2026-04-24^[73], avec dans les release notes, entre autres, la suppression de la valeur « partialAgreement » et du système de codes BeCSPartialAgreementValues^[96]. Au 29 septembre 2026, le CI-build affichait encore 2.2.0^[97]. Pour les directives techniques, l'IG renvoie à l'environnement SharePoint non public^[98]. Voir MyCareNet.
• Prescription de renvoi : l'eReferral-IG de l'INAMI pour l'API eReferral d'UHMEP cite dans son glossaire le DRP-IG fédéral comme IG parent^[99], alors que le portail marque DRP comme deprecated au profit de Referral^[2] ; techniquement, les CI-builds eReferral 2.0.0 et 2.1.0 dépendent de Referral 1.0.0^[100]. Voir Guides d'implémentation FHIR belges pour la prescription de renvoi : Referral-IG, DRP-IG et eReferral-IG.
• Laboratoire : le Lab-IG est en production, dans une première itération, pour l'envoi via eHealthBox^[54] ; voir Guide d'implémentation FHIR belge pour les résultats de laboratoire (hl7.fhir.be.lab). Le Referral-IG 1.0.0 ne contient qu'un profil général, un profil infirmier et un profil d'imagerie, et aucun profil de prescription spécifique au laboratoire^[101] ; une proposition d'éléments supplémentaires pour le projet LAB2LAB est ouverte comme issue depuis décembre 2025^[102]. Voir Demande électronique d'analyses de laboratoire.
• Identification du patient (numéro d'identification de la sécurité sociale) : BePatient dans BE Core 2.2.0 est le profil de patient fédéral, à l'origine basé sur la description fonctionnelle de l'INAMI^[11]. Il comporte un identifier-slice SSIN avec l'URI de system fixe https://www.ehealth.fgov.be/standards/fhir/core/NamingSystem/ssin ; l'invariant be-inv-SSIN exige qu'un numéro d'identification de la sécurité sociale non pseudonymisé se compose de 11 chiffres sans signes de ponctuation^[11]. Le BeSSINNamingSystem nomme le système d'identification « NISS/INSZ », émis par la Plate-forme eHealth, avec l'OID 2.16.840.1.113883.3.6777.5.1^[103]. La guidance donne un exemple d'identifiant canonique et renvoie aux profils pour les URI précises^[104] ; l'exemple est destiné à un numéro de registre national^[104]. La slice a une cardinalité 0..*, de sorte que BE Core n'impose pas le numéro d'identification de la sécurité sociale comme identifiant de patient^[11]. La question de savoir si un IG spécifique le rend plus strict n'a pas été examinée.

• Pas d'obligation, mais la référence. La publication comme norme fédérale n'oblige pas à l'implémenter^[3], mais selon la planification BIHR, les systèmes de DPI devraient à partir de 2028 pouvoir contenir les informations issues des modèles de données CareSet en vue de l'échange via FHIR^[17]. Il s'agit d'une planification, pas d'une obligation établie ; voir Obligation ou planification ? Base légale pour SNOMED CT, CareSets et FHIR.
• Licence : les implémenteurs de BE Core Clinical doivent disposer d'une licence SNOMED CT Affiliate^[12].
• Vaccinnet 2.0 : Vitalink documente l'IG Be Vaccination^[9] ; la question de savoir si et quand les hôpitaux écrivent aussi via Vaccinnet 2.0 est traitée sur Vaccinnet et HL7 FHIR.
• Trial Use n'est pas un gel. Malgré la release 1.0.0, l'IG Referral indique que la documentation et les artefacts sont encore en développement et que les ValueSets ne sont que des exemples^[13] ; la plate-forme eHealth qualifie l'IG labo de work-in-progress^[14].
• Recommandation : déterminez pour chaque couplage quelle version de l'IG la contrepartie (coffre-fort santé, MyCareNet) prend en charge, au lieu de suivre systématiquement la dernière release ; de nombreux IG ont reçu une nouvelle release en août et septembre 2026. Traitez une demande de publication comme un signal pour planifier, non comme une base pour un couplage de production. Pour le NISS, utilisez l'URI de system du profil BePatient et du BeSSINNamingSystem (avec « /core/ »), et non celle de l'exemple de la guidance, et validez par rapport à be-inv-SSIN.

Non trouvé n'est pas une preuve d'absence.

• Referral et DRP : Referral est publié comme 1.0.0 dans la série Trial Use^[83], mais selon sa propre page d'accueil il est encore en développement^[13]. DRP a reçu une nouvelle release 1.1.1 en août 2026^[85] alors que le portail marque DRP comme deprecated^[2] ; l'INAMI cite encore DRP comme CareSet publié^[105], et le glossaire eReferral cite DRP comme IG parent^[99] alors que la dépendance technique pointe vers Referral^[100]. Détails sur Guides d'implémentation FHIR belges pour la prescription de renvoi : Referral-IG, DRP-IG et eReferral-IG.
• Date de release de BE Patient Care 1.1.0 : package-list.json indique le 10 octobre 2025^[49], le registre de paquets le 26 novembre 2025^[41] ; probablement une date d'enregistrement face à une date de release. Pour BE Core Clinical, le registre diffère d'un jour du package-list^[32][48].
• Serveur de terminologie : les releases depuis août 2026 utilisaient dte-tx.ehealth.fgov.be^[55][56][57], alors que la documentation du SPF cite l'URL de l'Ontoserver^[106] ; que dte-tx soit le serveur de publication pour tous les IG n'a pas été démontré IG par IG, et aucun endpoint de production univoque n'a été trouvé. Voir Serveur national de terminologie (FHIR).
• Paquet de terminologie : le CI-build de hl7-be/terminology avertit que l'IG ne doit pas être utilisé^[51], alors que sur la branche release-candidate du même repository une demande de publication portant le même package-id est pendante^[29] ; le rapport entre les deux n'a pas été trouvé.
• Éditeur : la légende du portail comporte une catégorie « IG's Published by HL7Be »^[1] et la gouvernance prévoit une publication comme norme communautaire^[3], mais le registre des IG cite pour tous les IG belges la plate-forme eHealth comme autorité^[20] ; aucun IG communautaire postérieur à 2021 n'a été démontré.
• URI du SSIN dans BE Core 2.2.0 : l'exemple de la guidance utilise https://www.ehealth.fgov.be/standards/fhir/NamingSystem/ssin (sans « /core/ »), alors que BePatient et le BeSSINNamingSystem fixent …/fhir/core/NamingSystem/ssin^[104][103] ; la guidance renvoie elle-même aux profils pour les URI précises^[104].
• Laboratoire via les hubs : aucune preuve n'a été trouvée que l'IG Lab soit en production via les hubs ; uniquement la première itération via eHealthBox^[54].