Moteurs d'interface expliqués

Réponse courte : un moteur d'interface (moteur d'intégration) est un middleware conçu pour la messagerie de santé. Il écoute sur de nombreux protocoles (MLLP pour HL7 v2, HTTP pour FHIR et SOAP, fichiers, bases de données, files d'attente), transforme les messages (mappage de champs, traduction de codes, conversion de formats comme HL7 v2 vers FHIR), les achemine vers une ou plusieurs destinations avec des filtres, et conserve des files d'attente, des tentatives, des journaux et des tableaux de bord afin qu'un message ne soit jamais perdu et que chaque échec soit visible. Les hôpitaux en utilisent un pour que chaque système soit connecté au moteur une seule fois au lieu d'être connecté à tous les autres systèmes. Les produits les plus connus sont Mirth Connect (NextGen Connect, historiquement open source), Rhapsody, InterSystems HealthShare / IRIS for Health, Infor Cloverleaf, Qvera QIE, Orion et une longue liste ; les fournisseurs de cloud proposent des équivalents gérés.

Les composants

Les éléments constitutifs d'un moteur d'interface sont les canaux (un flux d'une source vers ses destinations), les connecteurs ou écouteurs sources tels que MLLP et HTTP, les filtres qui décident si un message continue, les transformateurs qui mappent les champs et les codes, les connecteurs de destination, les files d'attente avec nouvelle tentative, la surveillance avec alertes, et une piste d'audit des modifications de canaux et de l'historique des messages.

Quel que soit le vocabulaire, chaque moteur possède les mêmes parties :

Canal (interface) : un flux d'une source vers une ou plusieurs destinations, avec ses propres paramètres et statistiques.
Connecteur / écouteur source : MLLP (TCP avec encadrement pour HL7 v2), points d'accès HTTP(S), SFTP et interrogation de fichiers, requêtes de base de données, files JMS ou autres, DICOM dans certains produits.
Filtre : une règle qui décide si un message continue (uniquement ADT^A01 pour cette classe de patient).
Transformateur : scripts ou mappages qui modifient le message : renommer des champs, mapper des codes locaux à LOINC via une table de correspondance, construire une Observation FHIR à partir d'un segment OBX, ajouter un segment Z qu'un système hérité attend.
Connecteur de destination : où va le résultat, avec son propre protocole et sa gestion des erreurs.
File d'attente et tentative : les messages persistent jusqu'à accusé de réception ; les échecs sont retentés avec un délai progressif ; les messages "empoisonnés" atterrissent dans une file d'erreurs pour les humains.
Surveillance et alertes : compteurs par canal, latence, taux d'erreurs, alertes lorsqu'un canal devient silencieux (l'alerte la plus utile dans l'intégration de santé).
Audit : qui a modifié quel canal, et l'historique des messages pour le dépannage, avec des contrôles de rétention et d'accès car il s'agit de données patient.

Tâches typiques

Les tâches typiques d'un moteur d'interface de santé sont la diffusion ADT depuis le SIH vers les départements, le routage des résultats de laboratoire vers plusieurs destinataires, la traduction des codes locaux en LOINC, ATC et UCUM, l'interconnexion des formats HL7 v2, FHIR, CDA et CSV, l'exposition d'une façade FHIR sur une base de données existante, la normalisation des flux d'appareils, et l'adaptation de MLLP en interne à HTTPS en externe.

Diffusion ADT : recevoir les admissions du SIH, filtrer et traduire par département, livrer au laboratoire, à la radiologie, à la pharmacie, à la gestion des lits et au portail patient.
Acheminement des résultats : ORU du LIS vers le DME, vers le système du médecin prescripteur, vers le dossier régional, vers le dossier FHIR du patient, chacun avec un sous-ensemble et un format différents.
Traduction de codes : codes de tests locaux vers LOINC, codes de médicaments locaux vers ATC, unités en texte libre vers UCUM, via des tables de correspondance maintenues (mappage des codes de laboratoire à LOINC).
Pont de formats : HL7 v2 vers FHIR et vice-versa, CDA vers FHIR, CSV d'un ancien système vers n'importe quoi.
Une façade FHIR : le moteur expose des points d'accès FHIR et y répond en interrogeant la base de données hérité ou en envoyant des requêtes v2, de sorte que les applications voient un serveur FHIR là où il n'en existe pas.
Intégration d'appareils : flux de moniteurs propriétaires normalisés en observations IHE PCD.
Adaptation de protocole : MLLP à l'intérieur du bâtiment, HTTPS avec OAuth vers l'extérieur.

Choisir un moteur

Le choix d'un moteur d'interface se résume à six critères : le volume des messages et l'importance de la latence et des interruptions, les protocoles et normes pris en charge dès la sortie de la boîte (HL7 v2, FHIR R4, DICOM, formats nationaux), l'expérience des développeurs, les opérations telles que le clustering et le basculement, les conditions de licence, qui ont changé pour certains produits en 2025, et les compétences disponibles pour maintenir les canaux.

Volume et criticité : messages par jour, latence acceptable, et si une panne de deux minutes est problématique (elle l'est pour ADT et les résultats).
Protocoles et normes prêts à l'emploi : versions et analyseurs HL7 v2, prise en charge de FHIR R4 avec validation, DICOM, X12 aux États-Unis, formats nationaux.
Expérience développeur : langage de script (JavaScript dans Mirth, propriétaire dans d'autres), contrôle de version des définitions de canaux, outils de test, déploiement sur plusieurs environnements.
Opérations : clustering, basculement, intégrations de surveillance, chemin de mise à niveau, modèle de support.
Licence : éditions open source ou communautaires, abonnement par canal ou par cœur, offres cloud gérées ; les licences de certains produits historiquement ouverts ont changé en 2025, vérifiez donc les conditions actuelles.
Compétences disponibles : le moteur n'est bon que si les personnes qui maintiennent les canaux le sont.

Utiliser un moteur en toute sécurité

Faire fonctionner un moteur d'interface en toute sécurité signifie traiter les définitions de canaux comme du code sous contrôle de version, tester avec des messages synthétiques avant la production, gouverner les tables de correspondance de code avec des propriétaires nommés, alerter lorsqu'un canal devient silencieux, restreindre et purger l'historique des messages car il s'agit de données patient, documenter le but de chaque canal, et ne jamais laisser le moteur devenir le système d'enregistrement.

Traitez les définitions de canaux comme du code : dans un système de contrôle de version, revues, déployées via des environnements de test et de pré-production avec des messages synthétiques. Gardez les tables de correspondance (cartes de codes) sous gouvernance avec des propriétaires. Définissez des alertes sur le silence, pas seulement sur les erreurs. Restreignez l'accès à l'historique des messages, qui sont des données patient, et purgez-le selon un calendrier. Documentez le but et le propriétaire de chaque canal ; le canal non documenté est celui qui arrête un département lorsque son auteur part. Et ne laissez jamais le moteur devenir le système d'enregistrement : il déplace et transforme les données, il ne les possède pas.

Quand vous n'en avez pas besoin

Un moteur d'interface n'est pas nécessaire lorsque tous les partenaires d'un nouveau système parlent FHIR, auquel cas un serveur FHIR avec des abonnements et une passerelle API couvrent le routage et l'authentification, ou lorsqu'une seule interface HL7 v2 peut être gérée par une bibliothèque telle que HAPI HL7v2 ou hl7apy. Le moteur justifie sa place avec de nombreux systèmes et formats.

Un système "greenfield" dont les partenaires parlent tous FHIR peut utiliser un serveur FHIR avec des abonnements et une passerelle API pour l'authentification, la limitation de débit et le routage, avec des transformations dans des services ordinaires. Une seule interface HL7 v2 peut être gérée par une petite bibliothèque (HAPI HL7v2 en Java, hl7apy ou python-hl7 en Python) dans l'application. Le moteur justifie sa place lorsqu'il y a de nombreux systèmes, de nombreux formats et le besoin d'une console d'opérations que les non-développeurs peuvent surveiller.

Chez Anpheros

Anpheros Platform se situe du côté FHIR du moteur : les hôpitaux y acheminent les flux qu'ils souhaitent partager (résultats, documents, rencontres) via leur moteur ou via le connecteur laboratoire, et lisent les données via des API FHIR et des webhooks. Le site développeur présente le mappage HL7 v2 vers FHIR appliqué par le connecteur.

Pages connexes

Sources

Questions fréquentes

Un moteur d'interface est-il la même chose qu'un ESB ou un iPaaS ?

Même famille, spécialisé : un moteur d'interface est livré avec la prise en charge de HL7 v2, DICOM, CDA et FHIR, MLLP, une surveillance spécifique à la santé et l'intégration de vocabulaire utilisée par les équipes. Les ESB et iPaaS généraux peuvent faire le travail avec plus de construction.

Le moteur peut-il convertir automatiquement HL7 v2 en FHIR ?

Plusieurs moteurs incluent des mappages basés sur le guide HL7 v2 vers FHIR, et ils gèrent les segments courants. Les conventions locales, les segments Z et le mappage de codes nécessitent toujours un travail de projet.

Le moteur stocke-t-il des données patient ?

Il persiste les messages en transit et conserve l'historique des messages pour le dépannage, ce qui constitue des données patient et doit être protégé et purgé. Il ne doit pas être utilisé comme un stockage à long terme ou un système d'enregistrement.

Open source ou commercial ?

Les deux sont en production dans de grands hôpitaux. La décision dépend généralement du support, des compétences, des besoins en clustering et des conditions de licence actuelles, qui ont changé pour certains produits ; vérifiez avant de vous engager.

Anpheros Platform

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.

Créer un sandbox gratuit Lire les guides développeurs →

Gratuit · 30 patients synthétiques · sans carte

Ce guide est informatif et ne remplace pas une consultation médicale. Pour toute décision concernant votre santé, parlez-en à votre médecin. En cas d’urgence, appelez le numéro d’urgence local (112 en Europe).

Rédigé par

L'équipe Anpheros

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 →