Réponse courte : un hôpital utilise des dizaines de systèmes, et l'intégration consiste à les faire s'accorder sur un patient. Au centre se trouve le SIH (système d'information hospitalier) ou DSE (dossier de santé électronique), qui détient l'identité du patient, les admissions et le dossier clinique. Autour de lui : le système de laboratoire (SIL), de radiologie (RIS et PACS), de pharmacie, de bloc opératoire, d'urgence, de facturation, les appareils (moniteurs, pompes à perfusion), et de plus en plus les applications patient, les objets connectés et la télémédecine. Un moteur d'interface au milieu reçoit, transforme et achemine les messages, de sorte que chaque système est connecté une seule fois plutôt qu'à tous les autres. Le trafic est principalement constitué de messages HL7 v2 sur MLLP pour les événements (admissions, commandes, résultats), de DICOM pour les images, de CDA ou PDF pour les documents, et de FHIR sur REST pour tout ce qui est nouveau, destiné au patient ou externe.
Les systèmes et ce qu'ils échangent
Le paysage d'intégration d'un hôpital est composé du SIH ou DSE, qui détient l'identité du patient, les séjours et le dossier clinique, ainsi que du système de laboratoire, de radiologie (RIS et PACS), de la pharmacie, des appareils, des applications patient, de la télémédecine et des systèmes régionaux. Ils échangent des messages HL7 v2 tels que ADT, des commandes et des résultats ORU, des images DICOM, des documents CDA et des ressources FHIR.
| Système | Détient | Envoie | Reçoit |
|---|---|---|---|
| SIH / DSE | Identité du patient, rencontres, commandes, dossier clinique | ADT (admissions, transferts), commandes ORM/OML, planification SIU | Résultats ORU, documents MDM, frais DFT |
| SIL (laboratoire) | Échantillons, analyses, résultats, plages de référence | Résultats ORU^R01, réponses de commande ORR | Commandes ORM/OML, ADT pour la démographie |
| RIS / PACS | Commandes d'imagerie, listes de travail, rapports, images | Rapports ORU, DICOM vers visualiseurs, SIU | Commandes ORM/OMI, ADT ; listes de travail DICOM vers modalités |
| Pharmacie | Formulaire, dispensation, stock | RDS dispensation, RAS administration | Commandes de médicaments OMP/RDE, ADT |
| Appareils et moniteurs | Signes vitaux, formes d'onde, alarmes | Observations ORU^R01 (IHE PCD), propriétaires | ADT pour le contexte du patient |
| Portail patient / applications | Données saisies par le patient, accès | Observations FHIR, questionnaires, messages | Lecture FHIR des résultats, rendez-vous, documents |
| Télémédecine | Visites vidéo, surveillance à distance | Rencontre FHIR, Observation, DocumentReference | Rendez-vous, contexte patient, lancement SMART |
| Systèmes régionaux et nationaux | Dossiers partagés, registres, prescriptions électroniques | Documents CDA (XDS), FHIR, messages nationaux | Requêtes, notifications |
Le moteur d'interface
Un moteur d'interface est le centre de messagerie de l'hôpital : il reçoit le trafic HL7 v2, FHIR, fichiers et bases de données de chaque système, le transforme et le route vers tous les autres systèmes qui en ont besoin, et gère les files d'attente, les nouvelles tentatives, la surveillance et l'audit. Sans lui, N systèmes nécessitent jusqu'à N×(N−1)/2 interfaces construites à la main ; avec lui, chaque système se connecte une seule fois.
Le moteur (Mirth Connect / NextGen Connect, Rhapsody, InterSystems HealthShare et IRIS for Health, Infor Cloverleaf, Qvera QIE, entre autres) fournit des écouteurs (MLLP, HTTP, fichiers, bases de données), des transformations (mapper des champs, corriger des codes, convertir v2 en FHIR), du routage (envoyer un ADT à huit systèmes avec huit filtres), des files d'attente et nouvelles tentatives, de la surveillance et de l'audit. C'est aussi là que l'identité du patient est réconciliée lorsque les systèmes divergent, et où une façade FHIR est souvent construite par-dessus une base de données existante. Voir Les moteurs d'interface expliqués.
Les flux les plus importants
Les flux d'intégration hospitalière les plus importants sont les ADT (admissions, sorties, transferts et mises à jour démographiques diffusés depuis le SIH), les commandes et résultats entre le DSE et le laboratoire ou la radiologie, les commandes de médicaments et leur délivrance, les documents tels que les lettres de sortie, les données des appareils de surveillance, et l'échange orienté patient des résultats, des rendez-vous et des mesures à domicile via FHIR.
- ADT : chaque admission, sortie, transfert, enregistrement et mise à jour démographique (A01, A03, A02, A04, A08, A40 fusion) est diffusé depuis le SIH vers tous les autres. Si l'ADT est tardif ou incorrect, chaque système en aval classe les données sous le mauvais patient ou la mauvaise rencontre. Voir Messages HL7 v2 expliqués.
- Commandes et résultats : ORM/OML sortant, ORU retour, avec des numéros de placeur et de remplisseur les reliant ; LOINC et UCUM dans les résultats. Voir Messages de commande HL7 v2 et Intégrer un système de laboratoire avec un DSE.
- Imagerie : commandes vers le RIS, listes de travail DICOM vers les scanners, images vers le PACS, rapports retour sous forme d'ORU, visualiseurs via DICOMweb. Voir PACS vs RIS vs VNA.
- Médicaments : commandes à la pharmacie, dispensation et administration en retour, avec la boucle fermée (code-barres au chevet) comme objectif de sécurité.
- Documents : lettres de sortie, comptes rendus opératoires et documents numérisés sous forme de messages MDM, CDA ou PDF dans un dépôt de documents, publiés dans les registres régionaux.
- Appareils : moniteurs alimentant les signes vitaux dans le dossier via les profils IHE PCD ou des passerelles de fournisseurs, la gestion des alarmes étant une discipline distincte.
- Destinés au patient : résultats, rendez-vous et documents vers le portail et les applications via FHIR ; questionnaires, mesures à domicile et données d'objets connectés en retour, avec une provenance les marquant comme rapportés par le patient. Voir Surveillance à distance des patients avec FHIR.
Modèles qui fonctionnent
Les modèles d'intégration hospitalière qui fonctionnent sont : un système maître pour l'identité du patient, tous les autres s'abonnant aux ADT ; la mise en correspondance des codes avec LOINC, SNOMED CT et ATC une fois au niveau du moteur ; les accusés de réception, les files d'attente et les nouvelles tentatives pour chaque message ; des résultats et documents idempotents ; une couche FHIR pour les applications patient et les partenaires externes ; et des environnements de test avec des patients synthétiques avant la mise en production.
- Un seul maître pour l'identité. Le SIH (ou un index maître des patients) détient les identifiants ; tous les autres s'abonnent à ADT et n'inventent jamais de patients.
- Codes à la frontière. Mapper les codes locaux à LOINC, SNOMED CT, ATC au niveau du moteur, une seule fois, et conserver le code local à côté.
- Accuser réception, mettre en file d'attente, réessayer. Chaque message v2 reçoit un ACK ; le moteur persiste et rejoue ; personne ne perd un résultat parce qu'un système redémarrait.
- Idempotence. Les résultats et les documents portent des identifiants ; une relecture met à jour plutôt que de dupliquer.
- Une couche FHIR pour tout ce qui est nouveau. Les applications patient, la télémédecine, les extractions pour la recherche et les partenaires externes communiquent en FHIR avec une façade ou un serveur FHIR dédié alimenté par les flux internes, plutôt qu'avec le SIH directement.
- Environnements de test avec des patients synthétiques, et une étape de conformité (profils IHE Connectathon, suites de test nationales) avant que quoi que ce soit n'atteigne la production.
Modes de défaillance observés partout
Les modes de défaillance observés dans presque toutes les intégrations hospitalières sont les doublons de patients dus à des fautes de frappe à l'enregistrement, les résultats classés dans le mauvais séjour après une fusion, les codes locaux non mappés, les erreurs de fuseau horaire et d'heure d'été dans les horodatages, les unités en texte libre, les interfaces qui s'arrêtent silencieusement sans surveillance, les segments Z des fournisseurs qui cassent les analyseurs, et les flux CSV temporaires qui ne sont jamais retirés.
Patients dupliqués à cause de fautes de frappe lors de l'enregistrement ; résultats classés dans la mauvaise rencontre après une fusion ; codes de test locaux non mappés ; fuseaux horaires et heure d'été dans les horodatages des messages ; unités en texte libre ; une interface qui s'est arrêtée silencieusement et personne n'a surveillé ; segments Z spécifiques au fournisseur qui cassent les analyseurs ; et le flux CSV "temporaire" qui fonctionne encore dix ans plus tard.
Où FHIR change la donne
FHIR change l'intégration hospitalière en périphérie plutôt qu'au cœur. À l'intérieur de l'établissement, HL7 v2 et DICOM restent car les analyseurs, scanners et modules existants les utilisent ; FHIR prend le relais pour l'accès patient, les applications SMART on FHIR, le support décisionnel CDS Hooks, les abonnements, les échanges régionaux et nationaux sous EHDS et TEFCA, et les extractions pour la recherche.
En interne, HL7 v2 et DICOM resteront pendant des années, car chaque analyseur, scanner et module existant les utilise. FHIR gagne du terrain en périphérie : accès patient, applications lancées à l'intérieur du DSE (SMART on FHIR), aide à la décision (CDS Hooks), abonnements pour l'intégration pilotée par les événements, échange régional et national dans le cadre de l'EHDS et de TEFCA, et extractions pour la recherche. De nombreux hôpitaux exploitent désormais un serveur FHIR alimenté par le moteur comme couche d'intégration pour tout ce qui se trouve à l'extérieur du bâtiment ; voir Normes d'interopérabilité des soins de santé : la carte.
Chez Anpheros
La plateforme Anpheros se situe en périphérie FHIR de l'intégration hospitalière : un dossier FHIR R4 auquel un hôpital ou une clinique peut écrire et lire avec le consentement du patient, alimenté par l'intégration propre de l'hôpital via le connecteur de laboratoire (HL7 v2 ORU, CSV ou JSON), avec des webhooks et la provenance par source. Elle ne remplace pas le SIH ni le moteur.
Anpheros Platform se situe à cette périphérie : un enregistrement FHIR R4 que l'hôpital ou la clinique peut écrire et lire avec le consentement du patient, alimenté par l'intégration de l'hôpital (le connecteur de laboratoire prend HL7 v2 ORU, CSV ou JSON), avec des webhooks pour la notification de changement et la provenance par source. Il ne remplace pas le SIH ou le moteur ; il donne au patient un dossier qui le suit hors du bâtiment.
Pages associées
- Moteurs d'interface expliqués
- Comment intégrer un système de laboratoire avec un DSE
- Messages HL7 v2 expliqués : ADT et ORU
- PACS vs RIS vs VNA
- Surveillance à distance des patients avec FHIR
- Normes d'interopérabilité des soins de santé : la carte
- Intégrer les systèmes de clinique avec FHIR (site développeur)
Sources
- Suite de produits HL7 Version 2
- Cadre technique IHE IT Infrastructure
- Domaine IHE Devices (profils Patient Care Device)
- HL7 FHIR R4 : Messagerie et flux de travail
- Guide d'implémentation HL7 v2 vers FHIR
Questions fréquentes
Un nouvel hôpital doit-il tout intégrer avec FHIR ?
Pas tout. Les analyseurs, les scanners et la plupart des systèmes départementaux utilisent HL7 v2 et DICOM, et cela ne changera pas de sitôt. Utilisez FHIR pour les intégrations destinées au patient, externes et nouvelles, et un moteur pour faire le pont.
Quelle est la différence entre un SIH et un DSE ?
L'usage varie selon les pays. SIH désigne souvent le système hospitalier administratif et clinique ensemble ; DSE met l'accent sur le dossier clinique. En termes d'intégration, les deux sont le système qui détient l'identité, les rencontres et le dossier.
Combien d'interfaces un hôpital de taille moyenne a-t-il ?
Généralement entre cinquante et quelques centaines de flux de messages transitent par le moteur, en comptant chaque direction et chaque système récepteur. L'écran de surveillance du moteur est l'endroit où vivent les équipes d'intégration.
Qui est responsable de l'intégration dans un hôpital ?
L'équipe d'intégration informatique de l'hôpital, généralement avec le soutien du fournisseur du moteur, et chaque fournisseur départemental pour sa part. Les programmes nationaux et les profils IHE réduisent mais n'éliminent pas le travail de projet.
Essayez gratuitement dans le sandbox
Votre premier appel FHIR en 5 minutes. Une API HL7 FHIR R4 avec le consentement du patient intégré : essayez-la dans le bac à sable, puis connectez votre propre application ou système de clinique.
Gratuit · 30 patients synthétiques · sans carte
Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.
À propos d'Anpheros →