L’interopérabilité n’est plus un sujet d’architecture pour les DSI hospitalières : c’est une condition de continuité des soins. Quand le laboratoire, l’imagerie, la pharmacie et le dossier patient tournent sur des silos, c’est le clinicien qui reconstitue manuellement le fil. HL7 v2 et FHIR ne résolvent pas seuls ce problème, mais ils fixent un langage commun que le SIH doit savoir gouverner.
Pourquoi l’hôpital ne peut plus tolérer le point-à-point
Chaque connecteur ad hoc entre deux applications crée une dette : mapping de codes, gestion des versions, surveillance des pannes, documentation souvent absente. L’ANS décrit le cadre d’interopérabilité des systèmes d’information de santé autour de services partagés, d’identité patient et de standards d’échange. L’objectif n’est pas d’uniformiser tous les éditeurs, mais de réduire le nombre de dialectes propriétaires que l’établissement doit maintenir.
En pratique, le directeur des systèmes d’information doit tenir un registre des interfaces : source, destination, standard (HL7 v2, FHIR, DICOM, API REST), volumétrie, responsable métier, contrat de service. Sans ce registre, un changement de version sur un automate de biologie peut couper silencieusement la remontée des résultats vers le DPI.
HL7 v2 : toujours dominant, rarement documenté
HL7 v2 reste le workhorse des échanges ADT, ORU (résultats) et ORM (prescriptions) dans la majorité des hôpitaux français. Sa force est la maturité ; sa faiblesse, la variabilité des implémentations. Deux éditeurs qui « parlent HL7 » peuvent diverger sur les segments obligatoires, les codes de statut ou la gestion des reprises sur erreur.
Un SIH sérieux centralise la réception et l’émission des messages dans une couche d’intégration traçable : chaque message entrant est journalisé, validé, routé, et les échecs déclenchent une alerte opérationnelle plutôt qu’une perte silencieuse. Le clinicien ne doit jamais découvrir qu’un résultat est bloqué en coulisse.
FHIR : le pivot vers les API modernes
FHIR structure les ressources (Patient, Encounter, Observation, MedicationRequest…) en JSON ou XML avec des profils d’usage. L’programme d’implémentation FHIR France aligne progressivement les cas d’usage nationaux (CR Bio, identité, partage de documents). Pour l’hôpital, FHIR simplifie l’intégration avec les portails patients, les tiers de confiance et les composants cloud, à condition de respecter les profils et non d’inventer un dialecte local.
La coexistence HL7 v2 / FHIR est la norme pour les dix prochaines années. Le SIH doit donc exposer les deux : v2 pour les automates et systèmes legacy, FHIR pour les nouveaux services. La gouvernance des identifiants patient (INS, IPP local, identifiants externes) est le point de rupture le plus fréquent.
Test pratique : simulez une panne de l’interface résultats labo pendant une heure. Combien de temps faut-il pour détecter l’arrêt, identifier les messages en attente et les rejouer sans doublon ni perte ? Si la réponse dépasse trente minutes, votre interopérabilité est fragile.
Gouvernance des interfaces dans le SIH
La gouvernance repose sur quatre piliers : catalogue des flux, environnement de recette, supervision en production et gestion des versions. Chaque nouveau flux passe par un scénario de test reproductible (patient fictif, prescription, résultat, compte rendu) avant mise en production. Les changements de référentiel (codes LOINC, nomenclatures locales) sont versionnés et communiqués aux partenaires.
- Catalogue — inventaire à jour des interfaces, propriétaires métier et techniques.
- Recette — jeux de tests automatisés sur chaque release SIH ou partenaire.
- Supervision — tableaux de bord latence, taux d’erreur, files d’attente.
- Reprise — procédure documentée de rejeu sans duplication de données cliniques.
Lien avec le DPI et les modules spécialisés
Le dossier patient informatisé reste le point d’ancrage : les résultats de biologie, les comptes rendus d’imagerie RIS/PACS et les ordonnances validées par la pharmacie doivent apparaître sur la timeline patient avec la même identité et le même horodatage que dans le système source.
Promed HIS traite l’interopérabilité comme une capacité plateforme : FHIR R4 et HL7 v2 pour relier modules internes et partenaires externes, avec traçabilité des échanges. L’enjeu n’est pas la liste des acronymes sur une fiche produit, mais la fiabilité du parcours patient de bout en bout.
Cartographiez vos flux HL7/FHIR et testez vos scénarios de reprise avant la prochaine montée de version.
