Faire dialoguer les systèmes : interopérabilité avec FHIR et les HIE
# Faire dialoguer les systèmes : interopérabilité avec FHIR et les HIE
Une patiente arrive inconsciente aux urgences à 2 h du matin. Elle a été transférée depuis un hôpital plus petit situé à 60 km. Les ambulanciers remettent un résumé imprimé. Trois pages, en partie illisibles, sans la liste de ses traitements en cours. L'hôpital d'accueil utilise un dossier patient informatisé (DPI) différent de celui de l'établissement d'origine. Sur le papier, les deux hôpitaux sont « numériques ». Au chevet du patient, le trou dans les données est réel et dangereux.
Cette leçon suit ce transfert pour montrer comment trois éléments (les APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → HL7 FHIR, les health information exchanges et le cadre TEFCA) comblent ou ne comblent pas ce trou.
Pourquoi les systèmes ne se parlent pas par défaut
Un DPI est le logiciel qu'un hôpital utilise pour stocker les dossiers patients : notes, résultats de laboratoire, médicaments, imagerie, facturation. Sur le marché américain, une poignée d'éditeurs domine les grands hôpitaux, tandis que de nombreux éditeurs plus petits équipent les cliniques et les établissements ruraux.
Le problème : chaque DPI a été conçu comme un système fermé. Historiquement, les données étaient stockées dans des formats propriétaires. Les faire sortir passait souvent par le fax, l'impressionimpressionLe nombre total de fois qu'une publicité ou un contenu est affiché, indépendamment des clics. Chaque affichage compte pour une impression, même auprès de la même personne.Voir la définition complète → ou un projet d'intégration sur mesure coûteux.
L'interopérabilité est la capacité de systèmes différents à échanger des données et à réellement les exploiter. Pas seulement déplacer un PDF, mais faire circuler des données structurées qu'un système récepteur peut lire, trier et utiliser.
Deux modes de défaillance comptent pour notre patiente :
- Aucune connexion. Les systèmes n'ont pas de tuyau commun.
- Une connexion inexploitable. Les données arrivent sous forme de bloc non structuré (un document scanné), et le clinicien doit encore lire trois pages pour trouver une allergie.
HL7 et FHIR : une langue commune
HL7 (Health Level Seven) est l'organisme de normalisation qui définit la façon dont les systèmes de santé formatent et échangent les données. Les normes HL7 plus anciennes (messages v2, format de document CDA) sont largement utilisées mais lourdes et pénibles à manipuler.
FHIR (Fast Healthcare Interoperability Resources, prononcé « fire ») est la norme moderne de HL7. Son intérêt : elle reprend les technologies web qui font tourner les applications ordinaires, à savoir les APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → REST et le JSON. Si vous avez déjà utilisé une application qui récupère le solde de votre compte bancaire, c'est le même principe architectural.
FHIR découpe les données de santé en « ressources », chacune étant une unité standardisée : Patient, MedicationRequest, AllergyIntolerance, Observation (pour un résultat de laboratoire ou une constante), Condition (un diagnostic).
Voici à quoi ressemble un médicament sous forme de ressource FHIR, en version simplifiée :
{
"resourceType": "MedicationRequest",
"status": "active",
"medicationCodeableConcept": {
"text": "Warfarin 5 mg oral tablet"
},
"subject": { "reference": "Patient/12345" },
"dosageInstruction": [
{ "text": "Take 1 tablet once daily" }
]
}C'est cette structure qui compte. Le système de l'hôpital d'accueil peut lire status: active et Warfarin comme des champs de données, pas comme du texte enfoui dans une page scannée. Il peut signaler automatiquement une interaction dangereuse.
Aux États-Unis, la réglementation fédérale impose désormais aux DPI certifiés de proposer une APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → FHIR standard. Le 21st Century Cures Act et ses règles sur l'« information blocking » (appliquées à partir de 2021) rendent illégal, pour la plupart des acteurs de santé, le fait d'entraver déraisonnablement l'accès aux informations de santé électroniques. En pratique, cela a poussé les éditeurs à exposer des endpoints FHIR. La spécification est consultable sur hl7.org/fhir.
FHIR résout le problème de la *langue*. Mais une langue commune ne signifie pas que les deux hôpitaux sont connectés. Il faut encore que quelqu'un pose les tuyaux.
Les health information exchanges : les tuyaux
Un health information exchange (HIE) est une organisation qui relie de nombreux acteurs de soins pour qu'ils puissent partager les dossiers patients. Voyez-le comme un standard téléphonique. Plutôt que chaque hôpital construise un lien direct avec chaque autre hôpital (un nombre de connexions impossible), chacun se connecte une fois au HIE, et le HIE route les requêtes.
Les HIE existent sous plusieurs formes :
- HIE régionaux ou d'État, souvent à but non lucratif, couvrant une zone géographique.
- Réseaux d'éditeurs, où les hôpitaux partageant le même DPI échangent via le réseau propre à l'éditeur.
- Réseaux nationaux qui relient les connecteurs entre eux.
Revenons à notre patiente. Si l'hôpital d'origine et l'hôpital d'accueil participent tous deux au même HIE régional, l'urgentiste peut interroger le réseau et récupérer son dossier : une prescription de Warfarine active, une crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éatininémie récente, une allergie documentée à la pénicilline. Le trou dans les données se comble.
S'ils ne partagent pas de réseau, la requête ne renvoie rien, et l'on en revient au fax illisible.
L'ancien obstacle : trop de réseaux séparés
Pendant des années, les États-Unis ont vécu avec un patchwork. Un hôpital pouvait appartenir à un HIE d'État et à un réseau d'éditeur ; son voisin à un cadre national différent. On interrogeait l'un et on ratait les autres. Le transfert réussissait ou échouait selon la chance géographique et le choix d'éditeur, pas selon le besoin du patient.
C'est précisément cette fragmentation que la couche la plus récente vise à corriger.
TEFCA : un réseau de réseaux
TEFCA signifie Trusted Exchange Framework and Common Agreement. C'est une initiative américaine, crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →éée dans le cadre du Cures Act et coordonnée par le bureau fédéral de l'informatique de santé (ONC), destinée à relier les grands réseaux entre eux sous un ensemble de règles communes.
Le concept clé : le QHIN (Qualified Health Information Network). Un QHIN est un grand réseau qui satisfait aux exigences de TEFCA et accepte d'échanger des données avec tous les autres QHIN. Les premiers QHIN ont été désignés fin 2023, et le cadre s'étend depuis.
L'idée est élégante. Un hôpital se connecte à un QHIN. Ce QHIN peut atteindre tous les autres QHIN. Les urgences de notre histoire interrogent donc leur propre réseau, et la requête circule via TEFCA jusqu'à l'endroit où se trouve le dossier de la patiente. Fini le « sommes-nous tous les deux sur le même HIE ? ».
🎬 [VIDEO: "What is TEFCA?" - youtube.com - une courte explication par des formateurs en informatique de santé sur la manière dont le Trusted Exchange Framework relie les réseaux à l'échelle nationale]
Pourquoi cela peut quand même échouer au chevet du patient
TEFCA n'a rien de magique, et en 2026 le dispositif est encore en cours de maturation. Des lacunes réelles subsistent :
- La participation. Un réseau n'aide que si les deux hôpitaux l'ont effectivement rejoint. L'onboarding prend du temps et de l'argent, et les petits établissements ruraux sont en retard.
- La qualité des données. La requête peut aboutir et renvoyer un dossier dont la liste de médicaments n'a jamais été mise à jour. Garbage in, garbage out.
- L'appariement du patient. Les réseaux doivent confirmer que « Jane Smith, née en 1975 » à l'hôpital A est bien la même personne qu'à l'hôpital B. Les États-Unis n'ont pas d'identifiant patient national : l'appariement repose sur les données démographiques et peut échouer, ou renvoyer le mauvais dossier.
- Finalité et consentement. Des règles encadrent le *pourquoi* d'une demande de données (soins, paiement, santé publique). Les lois de protection de la vie privée propres à chaque État ajoutent de la variabilité, en particulier pour les données sensibles comme la santé mentale.
Le tuyau peut donc exister et livrer malgré tout une image incomplète ou mal appariée. L'interopérabilité est une chaîne : la norme (FHIR), plus le réseau (HIE ou QHIN), plus la qualité des données, plus l'appariement du patient, plus le consentement. Elle ne vaut que par son maillon le plus faible.
Vérification des acquis
1. Un hôpital envoie à un autre établissement un PDF scanné de trois pages du dossier d'un patient, que celui-ci peut ouvrir et afficher. Pourquoi s'agit-il malgré tout d'un échec d'interopérabilité ?
2. Pourquoi les DPI traditionnels ont-ils historiquement été incapables de partager facilement des données avec d'autres systèmes ?
3. Qu'est-ce qui décrit le mieux la relation entre HL7 et FHIR ?
4. Sélectionnez TOUTES les bonnes réponses. Deux hôpitaux se décrivent tous deux comme « numériques », et pourtant un vrai trou dans les données existe au chevet du patient lors d'un transfert. Quels facteurs expliquent cette contradiction apparente ?
Sélectionnez toutes les réponses correctes.
5. Sélectionnez TOUTES les bonnes réponses. Parmi les propositions suivantes, lesquelles sont de véritables modes de défaillance pour faire « dialoguer » les systèmes, tels que décrits dans la leçon ?
Sélectionnez toutes les réponses correctes.
Relire le transfert à travers les trois couches
Projetons le transfert de 2 h du matin sur la pile, parce que c'est ainsi qu'il faut penser tout problème d'interopérabilité.
Couche 1, la langue (FHIR). Les deux DPI sont certifiés et exposent des APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → FHIR. Bien. Les données de médicaments et d'allergies peuvent être représentées sous forme de ressources structurées.
Couche 2, le réseau (HIE / QHIN). L'hôpital d'accueil appartient à un QHIN. Le réseau de l'éditeur de l'hôpital d'origine également. Sous TEFCA, la requête des urgences traverse et renvoie le dossier. C'est cette couche qui décide si la moindre donnée circule.
Couche 3, les vérifications de réalité. La patiente a été correctement appariée (ses données démographiques étaient propres). Sa liste de médicaments avait été mise à jour lors de sa dernière consultation. Les règles de consentement autorisaient une requête de soins. Les trois conditions étaient réunies, si bien que la Warfarine apparaît à l'écran des urgences avant que le médecin ne prescrive un geste qui aurait provoqué une hémorragie.
Changez une seule variable et l'histoire finit autrement. Si l'hôpital d'origine n'a jamais rejoint de réseau, la couche 2 échoue et rien ne circule. Si son nom a été mal orthographié à l'admission, la couche 3 échoue et la requête ne renvoie rien ou, pire, le dossier de quelqu'un d'autre.
Pour une introduction large et neutre sur l'état de la politique américaine d'interopérabilité, le bureau fédéral de l'informatique de santé maintient des ressources publiques sur healthit.gov.
Ce que cela implique pour les décideurs
Si vous dirigez ou conseillez une organisation de soins, l'interopérabilité n'est pas un achat unique. C'est une série de questions :
- À quels réseaux participons-nous, et atteignent-ils les partenaires avec lesquels nous échangeons réellement des patients ?
- Nos endpoints FHIR fonctionnent-ils, et sont-ils testés, ou simplement « activés » techniquement ?
- Quelle est la qualité de notre appariement des patients ? Un taux élevé de doublons est une défaillance d'interopérabilité silencieuse.
- Nos données sont-elles à jour au moment où elles quittent l'établissement ?
La technologie est de plus en plus standardisée. La valeur restante, et le risque restant, se situent dans la participation, l'hygiène des données et l'appariement.
Points clés
- FHIR est la langue commune. Elle transforme les données de santé en ressources standardisées et lisibles par machine via des APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → web ordinaires, si bien qu'un système récepteur peut agir sur les données au lieu de se contenter d'afficher un document.
- Les HIE et les QHIN sont les tuyaux. Une langue commune ne sert à rien si les deux systèmes ne sont pas connectés au même réseau ; TEFCA vise à relier les grands réseaux pour qu'une seule connexion permette d'atteindre tout le pays.
- La chaîne a des maillons faibles. Même avec FHIR et TEFCA, les transferts échouent pour cause de non-participation, de données périmées, de mauvais appariement des patients (pas d'identifiant patient national) ou de restrictions de consentement.
- Diagnostiquez l'interopérabilité par couches. La langue, le réseau, puis la qualité des données et l'appariement. Quand les données n'arrivent pas au chevet du patient, c'est une couche précise qui a lâché, et la nommer est la première étape pour la réparer.