Guide d'implémentation FHIR belge pour les résultats de laboratoire (hl7.fhir.be.lab)

Le Lab-IG est le guide d'implémentation HL7 FHIR belge du groupe de travail Laboratory Report ; les questions à ce sujet sont adressées au Standards Team de la plate-forme eHealth^[1]. C'est un guide d'implémentation avec des profils, qui fait partie de la famille des guides d'implémentation FHIR belges. La version publiée est la 1.0.0, avec le statut Trial Use, basée sur FHIR R4 et générée le 2022-09-08^[1].

La ressource principale du rapport de laboratoire est DiagnosticReport, avec le profil belge BeLaboratoryReport^[2]. Observation et Specimen ont chacune leur propre profil (BeObservationLaboratory, BeSpecimenLaboratory), complétés par un profil Composition pour l'envoi sous forme de FHIR Document^[2][6]. BeObservationLaboratory décrit une observation dans un rapport de laboratoire^[7].

Le guide fixe la manière dont un laboratoire envoie au demandeur un rapport structuré et codé, dans le cadre de DIGIRELAB et de l'échange des résultats de laboratoire cliniques. Pour le code de l'observation, LOINC doit être utilisé selon le sous-ensemble que le SPF Santé publique définit (ReTaM), pour la plupart des analyses courantes^[2]. ReTaM est la représentation interrogeable de la source authentique des codes de laboratoire, hébergée par le Centre de Terminologie et basée, là où c'est possible, sur LOINC^[8]. Les unités sont exprimées en UCUM ; la table KMEHR CD-UNIT n'est pas utilisée^[2]. Une représentation pdf est facultative via DiagnosticReport.presentedForm^[2].

La prescription de laboratoire sort du champ de ce guide : l'artefact FHIR pour la demande d'analyses de laboratoire se trouve dans le Referral-IG, basé sur ServiceRequest (voir Demande électronique d'analyses de laboratoire)^[2].

Gestion, versions et statut

Phase 1, eHealthBox (production). L'envoi de rapports de laboratoire sous forme de FHIR Document vers une eHealthBox est, selon la Guidance, la première itération en production^[2]. Le résultat voyage comme payload d'un message eHealthBox avec des métadonnées personnalisées HC-FunctionalType « fhir-lab »^[2]. Ce payload est un FHIR Document (Bundle avec Composition) avec toutes les ressources référencées^[2]. Le texte publié décrit encore cela comme une attente pour une « première itération » avec une phase pilote en 2021 et n'a pas été actualisé depuis^[2]. Le fournisseur d'intégration Amaron affirme que les rapports de diagnostic sont déjà aujourd'hui envoyés sous forme de message FHIR via l'eHealthBox au demandeur, le plus souvent le médecin généraliste^[9] (affirmation du fournisseur).

Phase 2, hubs. Pour les hubs, le document FHIR est incorporé dans la transaction KMEHR « Laboratory result 2.0 » ; ce document FHIR doit suivre les règles de ce guide^[5].

Phase 3, API de recherche (proposition). La proposition de phase 3 de DIGIRELAB (mars 2026, « to be finetuned ») décrit une API de recherche FHIR auprès des hubs, par laquelle les Observations sont recherchées par code LOINC^[10][10]. La proposition s'attend encore à des restrictions supplémentaires issues d'une « coalition of the willing »^[10] ; ce n'est pas la production.

• Les laboratoires hospitaliers qui envoient des résultats aux médecins généralistes produisent, en phase 1, un FHIR Document conforme à ces profils et l'envoient via l'eHealthBox^[2][2]. La base de sources ne contient aucune obligation légale en ce sens.
• Le système d'information de laboratoire doit pouvoir faire correspondre les codes d'observation au sous-ensemble LOINC de ReTaM et fournir les unités en UCUM^[2][2].
• Pour la publication vers un hub, c'est l'emballage KMEHR 2.0 qui compte ; outre le document FHIR, celui-ci contient aussi un pdf pour les clients sans support FHIR^[5].
• Recommandation : fixez dans les contrats avec les fournisseurs de systèmes d'information de laboratoire quelle version du guide d'implémentation (1.0.0 ou une version ultérieure) et quel package de validation sont utilisés, tant que la release publiée et la version de développement divergent.

Conditions de mise en œuvre et limites

• Le guide dépend, pour le transport, de l'eHealthBox et, pour la phase 2, de l'emballage KMEHR des hubs^[2][5].
• Terminologie : LOINC selon ReTaM, une source qui ne s'appuie sur LOINC que « là où c'est possible » (voir LOINC et le sous-ensemble belge (ReTaM))^[8].

• Projet ou production ? La release 1.0.0 est Trial Use^[1], mais le guide se qualifie lui-même de spécification à l'état de projet qui ne peut pas être utilisée pour l'implémentation^[4][1], tandis que l'envoi via eHealthBox est la première itération en production^[2].
• Versions : la version de développement 1.0.1 sur GitHub n'est pas une release publiée^[3] ; la base de sources ne contient aucune publication plus récente.
• Limite de la preuve : une obligation légale pour les résultats de laboratoire FHIR et une confirmation formelle de la production de la phase 2 auprès des hubs restent une lacune ; cela ne constitue pas une preuve d'absence.