Contact Report (BIHR) : enregistrement après chaque contact

Qu'est-ce que le Contact Report (BIHR) ? Selon les slides de la Summer Day (24 août 2026), le concept BIHR comporte deux flux principaux : chaque prestataire de soins enregistre, après chaque contact, les données pertinentes, et des tableaux de bord affichent, par utilisateur, les données pertinentes^[1]. Cette idée n'est pas nouvelle : la présentation de l'Interoperability Day du 24 mars 2026 citait déjà l'enregistrement de nouvelles données pertinentes par chaque prestataire de soins à chaque contact comme deuxième processus de base du BIHR^[2] et comme l'une des six briques^[2]. Les slides décrivent le chemin du « Contact Report » vers l'écosystème BIHR comme un enregistrement et un codage avec l'appui de SNOMED CT, suivis d'une publication FHIR vers des CareSets dans les rubriques des sources authentiques^[1].

Nature de la source. Il s'agit d'un concept de groupe de travail (slides sur le wiki de HL7 Belgium), et non d'une réglementation de l'INAMI. L'INAMI décrit l'enregistrement au sein du BIHR en termes généraux : saisie dans son propre DPI, codage et validation automatiques selon des standards convenus, puis partage sécurisé avec les sources de données appropriées ; le terme « contact report » n'apparaît pas sur la page de l'INAMI^[3]. Un fournisseur décrit le contact report comme un enregistrement à la fin de chaque contact avec un patient, dans son propre système et immédiatement dans une source authentique, au lieu de s'envoyer des rapports les uns aux autres, avec les données nécessaires pour soi-même, pour ses collègues et pour d'autres prestataires de soins (vendor-claim)^[4].

Contact report BIHR versus « Contact report » KMEHR

Le nom identique est donc trompeur : le « contact report » KMEHR est un rapport, tandis que le contact report BIHR vise l'enregistrement dans des sources authentiques^[5].

Quelles données ?

Selon les slides de la Summer Day, chaque profession de santé répond à trois questions pour déterminer les données du contact report (et donc aussi lors de l'élaboration d'un CareSet) : de quoi ai-je moi-même besoin, de quoi les collègues ont-ils besoin, et de quoi les autres prestataires de soins ont-ils besoin pour des soins intégrés^[1]. Voir BIHR : CareSets et feuille de route EHDS.

Épisode de soins et liste de problèmes

Le contact report est lié à l'épisode de soins. La note de concept B-IHR (2023) voulait structurer les données autour d'épisodes de soins avec un diagnostic comme titre d'épisode, comme dans le Problem-Oriented Medical Record^[6]. Dans la présentation de mars 2026, le travail avec des Episodes of Care pose la base de la liste de problèmes, de sorte que les données puissent être taguées et extraites par problème^[2]. La séance plénière 3 de la Summer Day portait sur la liste de problèmes et l'épisode de soins, avec l'ajout de tags lors de l'enregistrement^[1]. Les slides proposent de construire automatiquement la liste de problèmes à partir des titres d'épisode des rapports de contact des médecins généralistes et de mettre fin à la création manuelle d'un Sumehr par le médecin^[1]. Le rapport GDOS (juin 2026) définit un épisode de soins comme les données relatives à un seul problème de santé, de la première demande d'aide jusqu'au dernier contact à ce sujet^[7]. La notion elle-même figure sur Épisode de soins (Episode of Care).

Ce que disent les notes de VIVEL

Les slides de la Summer Day renvoient, pour la structuration du « Contact Report » dans un Episode of Care, à la note sur les épisodes de soins de VIVEL (2024)^[1]. Les notes de VIVEL parlent elles-mêmes de « contactregistratie » (position de VIVEL) :

• Connector : lorsque plusieurs sources authentiques alimentent les mêmes composants d'un épisode dans un enregistrement de contact, un « connector » combine les données lors de la visualisation et les envoie, lors du stockage, vers la bonne source authentique^[8] ; voir Connecteur BIHR (FHIR-broker).
• Plan de soins : dans un enregistrement axé sur l'épisode, le plan de soins naît de ce qui figure dans la « planning » des enregistrements de contact des épisodes actifs^[8].
• Hôpitaux : ils ne travaillent pas systématiquement avec des épisodes de soins dans un premier temps ; le spécialiste renvoie son rapport de manière structurée et une lettre de sortie dans les standards appropriés peut être utilisée dans les épisodes^[9].

Les notes ne mentionnent pas nommément « contact report », l'environnement de travail BIHR (BWO) ni « Only Once » ; le lien avec BWO phase 1 n'est donc pas documenté dans les notes elles-mêmes (constat lors de la recherche du 1er octobre 2026).

Constat : le contact report est un concept de groupe de travail BIHR récurrent (mars et août 2026) qui vise à remplacer les rapports par un enregistrement structuré par contact^[2][1]. Ce n'est pas une notion formelle de l'INAMI^[3] ni un rapport KMEHR^[5].

• Aucune obligation : aucune réglementation, aucun CareSet ni profil FHIR pour le contact report n'a été trouvé (état au 2026-10-01).
• Rapports structurés (position de VIVEL) : dans la vision de VIVEL, les hôpitaux renvoient provisoirement des rapports structurés et des lettres de sortie, utilisables dans les épisodes, au lieu de tenir eux-mêmes des épisodes^[9].
• Les rapports restent nécessaires : le rapport GDOS (juin 2026) estime que les lettres de sortie restent nécessaires lors d'une transition vers le domicile tant que le BIHR n'est pas pleinement opérationnel ; ensuite, les informations dans le BIHR peuvent les remplacer^[7]. La publication via le hub (Cas d'usage : partage des rapports et résultats hospitaliers via le hub) reste donc la pratique.
• Orientation : la liste de problèmes et le codage au moment de l'enregistrement sont au centre des groupes de travail^[1][2].
• Recommandation (propre) : vérifiez si le DPI peut consigner les diagnostics et les problèmes par épisode de manière structurée et codée, afin qu'une publication ultérieure vers des CareSets soit possible sans nouvel enregistrement.

Conditions de mise en œuvre et limites

La publication vers des sources authentiques suppose des CareSets publiés et un canal pour y accéder ; le Connecteur BIHR (FHIR-broker), qui assurerait cela, est lui-même encore un concept^[1]. L'enregistrement lui-même doit pouvoir être effectué par le prestataire de soins de la manière la plus naturelle possible dans son propre système^[1].

• Notion formelle ? « Contact report » n'a pas été trouvé dans les publications de l'INAMI, dans le plan d'action eSanté 2026-2029 ni comme CareSet dans la feuille de route EHDS de mai 2026^[3] ; non trouvé n'est pas une preuve d'absence.
• Tagging : une source officielle décrivant le tagging avec des codes de problème comme exigence du BIHR n'a pas été trouvée ; seulement des slides de groupe de travail et un fournisseur^[2][4].
• Notes de VIVEL : les notes sur les épisodes de soins (2024) et sur les sources authentiques (2026) ont été traitées (voir ci-dessus et Épisode de soins (Episode of Care)) ; elles n'utilisent pas le terme « contact report »^[8], et une réaction formelle de l'INAMI ou de la Plate-forme eHealth à ces notes n'a pas été trouvée.