HL7 FHIR

HL7 FHIR (Fast Healthcare Interoperability Resources) est une norme de l'organisation internationale HL7 pour l'échange d'informations de santé, construite à partir de ressources (resources) : de petits blocs d'information identifiables (comme « patient ») qui sont utilisables dans différents contextes^[1]. Cette page est volontairement brève ; les profils belges figurent sur Guides d'implémentation FHIR belges.

Quel problème FHIR résout-il ?

En Belgique, FHIR doit devenir le successeur moderne de KMEHR : les nouveaux flux de données utilisent de préférence FHIR et les nouvelles interfaces de préférence FHIR REST^[2]. L'INAMI souligne que la seule conformité aux normes FHIR internationales ne suffit pas : les systèmes ne peuvent collaborer correctement que s'ils utilisent aussi les mêmes normes et accords nationaux^[3] ; pour cela, selon le BIHR, l'utilisation d'un serveur de terminologie, de ValueSets cohérents, de CareSets et de bindings est importante^[3]. Dans les principes d'architecture du BIHR (mars 2026), cette répartition des tâches est explicite : FHIR règle la syntaxe de l'échange, les CareSets, les ValueSets et les bindings règlent la sémantique^[4]. La seule conformité FHIR ne rend donc pas les données interopérables ; il faut pour cela une conformité à des profils et à des accords partagés^[4].

La date de publication, la date d'entrée en vigueur et la version technique diffèrent : « R4 » est la release, 4.0.1 la version technique qui figure dans les package-lists des guides d'implémentation belges^[5] ; la liste complète par guide figure sur Guides d'implémentation FHIR belges. Les profils belges sont élaborés au sein de groupes de travail de HL7 Belgium^[11], l'affilié belge de HL7 International, reconnu en avril 2020^[12].

• Politique : FHIR est la norme préférentielle depuis le plan d'action e-Santé 2019-2021^[2]. En 2019, le conseil de programme du plan d'action 2019-2021 a décidé que toute initiative CareSet de l'INAMI doit partir de ressources FHIR^[13]. Au sein du BIHR, FHIR devient la norme d'échange, conformément aux profils belges ; selon la planification, les échanges nouveaux et adaptés se dérouleront via FHIR à partir de 2028^[3].
• Profils : la Plate-forme eHealth publie des profils FHIR belges et des guides d'implémentation sur ehealth.fgov.be/standards/fhir^[14], aussi proches que possible de la norme de base^[15]. Voir Guides d'implémentation FHIR belges.
• Vitalink : l'environnement FHIR est entré en production le 22/03/2024 à côté de l'environnement KMEHR, avec REST (au lieu de SOAP) et I.AM Connect^[7]. Les immunisations sont le type de données le plus important ; les dépistages du cancer du CVKO passent aussi par FHIR^[16]. Vaccinnet 2.0 utilise Vitalink et FHIR^[17].
• Les coffres-forts ensemble : Vitalink, Abrumet et RSW ont publié un cookbook FHIR commun, d'abord pour les allergies avec BeAllergyIntolerance^[18].
• Médication : dans la planification de l'INAMI (phase 2026-2027, actions prévues en 2026), l'INAMI soutient les coffres-forts et les fournisseurs de logiciels dans l'implémentation de FHIR pour les données de médication^[19] ; il s'agit d'une planification (voir Schéma de médication partagé).

La transition KMEHR→FHIR en bref

La transition est progressive : les flux existants sont encouragés à migrer, « best effort »^[13], et un « big bang » n'est pas possible selon la Plate-forme eHealth^[2]. Au sein du BIHR, les flux KMEHR restent pris en charge en lecture seule^[3]. Selon une présentation de l'INAMI (mars 2026, planification), FHIR devient opérationnel et KMEHR passe en lecture seule (read-only) lors d'une bascule coordonnée ; sur la diapositive, la mention « Point T = 12 months after the last Patient Summary CareSet publication » figure en pied de diapositive, à hauteur de cette étape^[20]. La question de savoir si Point T s'applique à tous les flux ou seulement au patient summary n'est pas spécifiée. La prescription de renvoi électronique (eReferral) dispose d'un CareSet FHIR publié, Digital Referral Prescription (DRP) ; interprétation : comme la source ne mentionne aucune variante KMEHR, ce flux semble passer directement du papier à FHIR, sans étape intermédiaire KMEHR^[21]. Les détails et les points ouverts figurent sur KMEHR ; la planification par flux de données figure sur BIHR (Belgian Integrated Health Record).

• Vaccinnet 2.0 et Vitalink (passage canonique) : selon la ministre flamande (réponse à la question écrite n° 327 du 5 février 2025), les hôpitaux écriront, avec Vaccinnet 2.0 (Vitalink FHIR), pour la première fois aussi des données dans Vitalink^[22] ; à ce moment-là, ils ne pouvaient que consulter Vitalink^[22]. Le statut de production pour les hôpitaux n'a pas été vérifié séparément. Lors du troisième BE FHIR-A-THON (septembre 2025), 14 intégrateurs, dont des hôpitaux, ont travaillé sur Immunisation dans Vitalink@FHIR^[23].
• Selon la planification actuelle du BIHR, les systèmes de DPI devraient, à partir de 2028, pouvoir contenir les modèles de données des CareSets afin que ceux-ci soient échangeables via FHIR^[3] ; il s'agit d'une planification, et non d'une obligation établie.
• Les conditions BMUC parlent d'un partage sous une forme permettant la réutilisation (CareSets, FHIR, SNOMED CT)^[24] (voir BMUC : financement du DPI intégré).
• Recommandation : évaluez les couplages FHIR des fournisseurs sur leur conformité aux profils belges et aux CareSets, et pas seulement sur « compatible FHIR » (voir les principes de l'INAMI ci-dessus).
• Recommandation : choisissez R4 (4.0.1) avec les profils belges comme version cible pour l'intégration. Il n'y a pas de guide d'implémentation belge sur R5/R6, mais la connaissance de R5 reste utile car, entre autres, BE Medication utilise des éléments R5 via des extensions cross-version dans R4.

Conditions de mise en œuvre et limites

L'accès FHIR à Vitalink exige REST, I.AM Connect^[7] et la pseudonymisation via la Plate-forme eHealth^[7]. La publication comme norme fédérale n'implique pas automatiquement une obligation légale de la mettre en œuvre immédiatement^[11]. Une conversion sans meilleur codage apporte peu^[2] ; pour les profils codés, SNOMED CT est le codage préféré^[25].

• La date de publication et le mélange normatif/STU de R4 figurent dans la recherche, mais la citation n'a pas pu être vérifiée ; ils ne sont pas mentionnés ici comme un fait.
• Aucun guide d'implémentation belge sur R5 ou R6 n'a été trouvé ; cela ne signifie pas qu'il n'existe aucun plan.
• La question de savoir si les hubs hospitaliers proposent déjà FHIR n'a pas été examinée.
• Préférence, aucune obligation trouvée : la Plate-forme eHealth formule FHIR comme norme préférentielle (« preferably ») pour les nouveaux flux de données^[26] ; une affirmation d'un fournisseur selon laquelle la migration KMEHR→FHIR est déjà « fixée par la réglementation » n'est couverte par aucun texte législatif trouvé (état au 2026-10-01)^[27]. Voir BIHR (Belgian Integrated Health Record) ; l'analyse par degré d'obligation (indicateur BMUC FHIR+LOINC, homologation des logiciels dentaires, protocole d'accord de 2023) figure sur Obligation ou planification ? Base légale pour SNOMED CT, CareSets et FHIR^[28][29].