Moteurs d'interface HL7 comparés : Mirth Connect, Rhapsody, Iguana, Qvera et options cloud

Réponse directe

Un moteur d'interface HL7 (EAI santé) reçoit des flux HL7 v2, et de plus en plus FHIR, X12 et DICOM, les transforme, les route entre applications et conserve une file d'attente persistante pour ne rien perdre quand un destinataire tombe. En octobre 2026, la liste courte réaliste comprend Mirth Connect commercial (propriétaire depuis la 4.6), ses forks open source Open Integration Engine et BridgeLink, Rhapsody ou Corepoint, IguanaX, Qvera QIE et InterSystems Health Connect. Les services santé d'Azure, Google et AWS stockent et convertissent les données, mais aucun ne prend en charge un flux MLLP de bout en bout, acquittement compris, comme le fait un moteur. Le choix se fait sur les compétences de l'équipe, la volumétrie, l'outillage d'exploitation et les contraintes d'hébergement ; les listes de fonctionnalités se ressemblent presque toutes.

Ce que fait réellement un moteur d'interface

Tous les moteurs font cinq choses : écouter (MLLP sur TCP, HTTP, SFTP, scrutation de base de données), analyser, filtrer et transformer, router vers une ou plusieurs destinations, et persister les messages avec gestion des ACK et des reprises. Les différences tiennent à la manière d'écrire les transformations, à la promotion d'une modification de la recette vers la production, et au comportement du moteur à 3 h du matin quand le SIL cesse de renvoyer ses ACK.

Pour les messages eux-mêmes, types de messages HL7 et exemples détaille ADT, ORM/OML, ORU, SIU et MDM. Pour la structure interne d'un canal Mirth (source, filtres, transformateurs, destinations, traitement des réponses), voir l'architecture des canaux Mirth Connect.

Quel que soit le moteur retenu, il doit analyser, acquitter et encaisser les variantes malformées d'un message comme cette admission synthétique :

MSH|^~\&|ADT_SRC|HOSP_A|ENGINE|HOSP_A|20261006091500||ADT^A01^ADT_A01|MSG00001|P|2.5.1
EVN|A01|20261006091500
PID|1||123456^^^HOSP_A^MR||DOE^JANE^^^^^L||19800101|F
PV1|1|I|WARD1^101^A|||||||MED

Mirth Connect après la 4.6

Le 19 mars 2025, NextGen Healthcare a annoncé que Mirth Connect 4.6 passe d'un double modèle open source et commercial à une licence unique, commerciale et propriétaire. La version 4.5.2, publiée sur GitHub en septembre 2024 sous Mozilla Public License 2.0, est la dernière version open source. NextGen a proposé trois options aux utilisateurs open source : rester sur leur version actuelle, passer en 4.5.2, ou acheter une licence et migrer vers la 4.6. Les offres payantes citées dans l'annonce sont Enterprise, Gold et Platinum, et toutes incluent Mirth Command Center.

Le même code a aussi été commercialisé un temps sous le nom NextGen Connect : la documentation et les réponses de forum publiées sous l'un ou l'autre nom s'appliquent en général.

Rester en 4.5.2 signifie ne plus recevoir de correctifs open source de NextGen. L'historique de sécurité compte : CVE-2023-43208, une exécution de code à distance sans authentification corrigée en 4.4.1, a été ajoutée au catalogue CISA des vulnérabilités activement exploitées en mai 2024. Un Mirth antérieur à la 4.4.1 joignable depuis Internet doit être traité dès aujourd'hui comme un incident de sécurité.

Deux forks de la 4.5.2 sont actifs :

• Open Integration Engine (OIE). Fork communautaire sous MPL 2.0, désormais projet de la fondation Eclipse. OIE a publié sa 4.5.2 en juillet 2025 et la 4.6.0 le 9 juillet 2026. OIE 4.6.0 n'est pas la 4.6 de NextGen ; les numéros de version se télescopent, donc écrivez « OIE 4.6 » dans les tickets et les procédures d'exploitation.
• BridgeLink. Porté par Innovar Healthcare, BridgeLink part de Mirth 4.5.2, conserve le cœur sous MPL 2.0 (le module WebAdmin est sous Business Source License 1.1), numérote ses versions par année (la 26.9.0 est sortie le 1er octobre 2026) et exige Java 17 ou plus. Innovar vend des contrats de support et des plugins complémentaires.

Les moteurs commerciaux

Rhapsody et Corepoint

Les deux moteurs appartiennent à Rhapsody. L'éditeur se présente comme créé en 2018 lors du rachat de l'activité Rhapsody à Orion Health par Hg, puis complété par Corepoint Health ; Lyniate est un ancien nom. Rhapsody Integration vise les parcs volumineux et multi-standards (HL7, FHIR, X12, DICOM) et organise la transformation autour de son Mapper, avec du JavaScript quand les définitions de mapping ne suffisent pas. Corepoint Integration est l'option low-code pour les équipes internes qui préfèrent configurer plutôt que coder. Rhapsody indique que ses moteurs sont Best in KLAS depuis 2009.

IguanaX (iNTERFACEWARE)

iNTERFACEWARE maintient deux générations, Iguana 6 et IguanaX. Les deux se programment en Lua 5.1 dans l'IDE Translator. Dans IguanaX, chaque composant est du code Lua doté de son propre dépôt Git, et les interfaces passent du développement à la recette puis à la production via Git et des « collections » (utilisation de Git par les composants). Cela convient aux équipes déjà habituées aux pull requests. La contrepartie : un vivier de recrutement plus étroit en Lua qu'en JavaScript.

Qvera QIE

QIE se programme en JavaScript, couvre HL7, FHIR, DICOM (y compris DIMSE) et X12, et tourne sur site, en conteneurs ou dans votre propre compte AWS, Azure ou Google Cloud, sur SQL Server, MySQL ou MariaDB. Qvera indique que la haute disponibilité est incluse dans toutes les licences. Sa page tarifs présente trois modèles commerciaux (par canal, entreprise et OEM), chacun avec l'ensemble des fonctionnalités. Aucune édition gratuite n'est proposée ; un essai l'est. Qvera met aussi en avant la conversion des canaux Mirth, JavaScript compris : à tester sur vos propres canaux avant d'en faire une hypothèse de projet.

InterSystems HealthShare Health Connect

Health Connect construit les interfaces sous forme de productions (business services, processes et operations), avec un éditeur DTL graphique pour les mappings et ObjectScript pour le code spécifique. InterSystems annonce des transformations HL7 v2 et CDA vers FHIR, la mise en miroir avec bascule automatique, et deux modes de déploiement : service cloud entièrement géré ou exploitation par vos soins, sur site ou dans un cloud. Il convient aux établissements qui utilisent déjà des produits InterSystems, ou aux contextes où l'orchestration durable de processus longs compte plus que le scripting rapide.

Microsoft BizTalk Server

BizTalk Server 2020 est la dernière version, et Microsoft a publié une mise à jour du cycle de vie qui oriente les clients vers Azure Logic Apps. D'après la page de cycle de vie, le support standard s'arrête le 11 avril 2028 et le support étendu en avril 2030. Ne démarrez pas de nouveau projet HL7 dessus ; planifiez la sortie.

Services cloud : stockage et conversion, pas un moteur complet

Azure Health Data Services propose des services FHIR et DICOM managés. L'opération $convert-data du service FHIR convertit HL7 v2, C-CDA, JSON et FHIR STU3 en Bundle FHIR R4 de type batch, à l'aide des templates Liquid du projet open source FHIR Converter. Microsoft précise que les templates par défaut sont sous licence MIT, non supportés et non destinés à la production : hébergez votre propre copie dans Azure Container Registry et figez-en la version. Microsoft présente $convert-data comme une étape d'un pipeline ETL bâti sur Logic Apps ou Data Factory ; le service n'écoute pas en MLLP. Notez aussi qu'Azure API for FHIR a été retiré le 30 septembre 2026 : les documents d'architecture qui y font encore référence sont obsolètes.

{
  "resourceType": "Parameters",
  "parameter": [
    { "name": "inputData", "valueString": "MSH|^~\\&|ADT_SRC|HOSP_A|ENGINE|HOSP_A|20261006091500||ADT^A01|MSG00001|P|2.5.1\rPID|1||123456^^^HOSP_A^MR||DOE^JANE||19800101|F\r" },
    { "name": "inputDataType", "valueString": "Hl7v2" },
    { "name": "templateCollectionReference", "valueString": "myregistry.azurecr.io/hl7v2templates:1.0.0" },
    { "name": "rootTemplate", "valueString": "ADT_A01" }
  ]
}

Google Cloud Healthcare API dispose d'un magasin HL7v2 dédié. messages.ingest enregistre un message et renvoie un ACK HL7, les messages sont analysés en JSON, et Pub/Sub notifie les abonnés des nouveaux messages. Un adaptateur MLLP open source, exécuté sur GKE, fait le pont entre les flux TCP et l'API. Pour passer de HL7 v2 à FHIR, le modèle de référence de Google s'appuie sur Dataflow et Whistle, et Google signale que les exemples publiés utilisent Whistle 1, une version historique non supportée.

AWS HealthLake est un entrepôt de données FHIR R4. Ses tâches d'import acceptent du FHIR R4, et AWS renvoie vers ses partenaires pour convertir les autres formats en amont. La fonction intégrée Data Transformation, en préversion, couvre C-CDA et CSV, pas HL7 v2. Si vos sources sont en v2, il faut un autre composant pour les convertir.

En pratique, le schéma cloud associe un moteur (auto-hébergé ou conteneurisé) qui termine le MLLP, renvoie l'ACK et gère les reprises, puis pousse du FHIR vers l'entrepôt managé. La stratégie de migration HL7v2 vers FHIR traite du mapping, et le comparatif des serveurs FHIR de la destination.

Tableau comparatif

Grille de choix

• Volumétrie et pics. Mesurez les messages par jour, le pic par minute et le plus gros message (un ORU qui embarque un PDF en base64 dans OBX-5 peut peser plusieurs mégaoctets). Rejouez votre propre trafic lors d'une preuve de concept plutôt que de vous fier aux chiffres de débit des éditeurs.
• Compétences de l'équipe. JavaScript (famille Mirth, QIE), Lua (IguanaX), ObjectScript et DTL (InterSystems), mapper ou low-code (Rhapsody, Corepoint). Demandez-vous qui maintiendra les interfaces dans trois ans et si vous pouvez recruter sur ce langage.
• Haute disponibilité. Actif/passif ou actif/actif, et devenir des messages en file et en cours de traitement lors d'une bascule. Demandez à l'éditeur de le démontrer en arrêtant un nœud pendant un test de charge.
• Supervision et alertes. Profondeur des files, latence des ACK, taux d'erreur, et alertes sur le silence : aucun ADT pendant 15 minutes un jour ouvré, c'est un incident. Vérifiez que métriques et journaux d'audit remontent vers votre supervision et votre SIEM existants.
• Gestion de version des canaux. Les canaux de la famille Mirth s'exportent en XML, comparable mais verbeux ; IguanaX est nativement sous Git. Définissez comment une modification passe du développement à la production et qui la valide.
• Hébergement et réglementation en Europe. Les magasins de messages contiennent des données de santé au sens de l'article 9 du RGPD : fixez la rétention et la purge de façon délibérée. Un moteur managé suppose un contrat de sous-traitance, une région européenne nommée et de la clarté sur le lieu depuis lequel le support de l'éditeur accède au contenu des messages. En France, héberger des données de santé pour le compte d'un tiers exige la certification HDS ; voir l'hébergement de données de santé HDS.
• Coût de sortie. Comment récupérer canaux, mappings et historique des messages si vous partez.

Notes de migration : quitter Mirth 4.5 open source

1. Tout inventorier. Canaux, code templates, scripts globaux, configuration map, alertes, JAR spécifiques, pilotes de base de données, certificats, et chaque point de connexion avec son responsable. Faites une sauvegarde complète de la configuration depuis l'Administrator et versionnez chaque export de canal dans Git.
2. Choisir la voie. Licence NextGen 4.6+, passage à un fork, ou changement de plateforme. Un fork conserve vos canaux quasiment tels quels ; un changement de plateforme impose de réécrire chaque transformation, donc chiffrez-le canal par canal.
3. Vérifier la compatibilité du fork. OIE 4.6.0 exige Java 17, retire les bibliothèques Xerces et xml-apis embarquées (le code qui utilise org.apache.xerces doit passer à javax.xml.parsers ou à SAX) et rend les identifiants insensibles à la casse par défaut. Analysez vos exports avant la mise à jour :

grep -rl "org.apache.xerces" ./mirth-export/

4. Faire tourner en parallèle. Rejouez un échantillon représentatif de messages dans les deux moteurs sur un environnement maîtrisé, normalisez les champs volatils comme MSH-7 et MSH-10, puis comparez les sorties. Basculez une interface à la fois, en commençant par des flux sortants à faible risque.
5. Garder l'historique consultable. L'ancien magasin de messages est souvent la seule piste d'audit pour les litiges d'interface passés. Gardez l'ancien moteur en lecture seule jusqu'à la fin de la durée de conservation, ou exportez ce que vous devez garder.

Les flux de laboratoire et d'imagerie sont en général les plus difficiles à déplacer, à cause du volume de résultats et du rapprochement demande/résultat ; l'intégration des workflows radiologie et laboratoire couvre ces flux. Si vous comparez ces options ou préparez la sortie de Mirth 4.5.2, l'accompagnement Mirth Connect couvre l'inventaire, l'évaluation des forks et le plan de bascule.