Le Contact Report (BIHR) est un concept à l'état de projet dans lequel un prestataire de soins enregistre, après\nchaque contact avec un patient, les données pertinentes de manière structurée et codée dans son propre système. Un\nconnecteur publierait ces données via FHIR vers des CareSets dans des sources authentiques. Le concept n'est pas\nencore une réglementation de l'INAMI ni une CareSet publiée et il diffère de la transaction KMEHR du même nom, qui\ntransfère un document. Pour les hôpitaux, c'est surtout le glissement possible de rapports isolés vers un\nenregistrement réutilisable qui importe.
", "last_verified": "2026-11-05", "verification_outdated": false, "sections": [ { "id": "qu-est-ce-que-c-est", "title": "Qu'est-ce que c'est ?", "kind": "tekst", "html": "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].
\nNature 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].
" }, { "id": "composants", "title": "Composants", "kind": "tekst", "html": "| Dimension | \nContact report BIHR | \nTransaction KMEHR « Contact report » | \n
|---|---|---|
| Origine | \ngroupes de travail BIHR, 2026[2][1] | \ntransaction KMEHR, version 1.0 (2002)[5] | \n
| Ce qui est transmis | \ndes données structurées et codées, via FHIR vers des CareSets dans des sources authentiques[1] | \nun document sur une consultation, une visite d'urgence ou une visite à domicile, sous forme de texte libre, de fichier incorporé ou avec des headings/items[5] | \n
| Nature | \nconcept, pas une spécification | \nspécification KMEHR existante | \n
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].
\nSelon 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.
\nLe 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).
\nLes 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) :
\nLes 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).
" }, { "id": "phase", "title": "Phase", "kind": "tekst", "html": "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].
" }, { "id": "qu-est-ce-que-cela-signifie-pour-un-hopital", "title": "Qu'est-ce que cela signifie pour un hôpital ?", "kind": "tekst", "html": "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].
" }, { "id": "incertitudes-et-informations-contradictoires", "title": "Incertitudes et informations contradictoires", "kind": "tekst", "html": "