HL7 version 2

HL7 version 2 (HL7 v2) est un standard international de messagerie pour l'échange entre applications au sein de l'hôpital et autour de celui-ci. La version 2.4 prend par exemple en charge les messages ORU afin de transférer des résultats de laboratoire vers d'autres systèmes.^[1] Le profil IHE Laboratory Testing Workflow (LTW) définit cinq transactions, toutes basées sur HL7 version 2.5 ou 2.5.1.^[2] Chaque transaction LTW utilise un sous-ensemble des structures de message OML, ORL, ORU et OUL.^[2]

Pour le transport sur le réseau, IHE prescrit le Minimal Lower Layer Protocol (MLLP).^[4] IHE prend en charge les deux modes d'acquittement de HL7 v2.5, Original et Enhanced Acknowledgement Mode.^[4]

IHE LTW spécifie les interfaces entre les systèmes d'information clinique, le SIL et l'automatisation de laboratoire, de sorte qu'un de ces systèmes puisse être remplacé sans rompre les flux de données existants. ^[2] Une demande peut ainsi passer directement du système clinique du service vers le SIL, sans que le laboratoire saisisse l'ordre manuellement.^[2] Voir Interface entre SIL et dossier patient informatisé pour l'application belge et les alternatives.

Éditions, gestion et statut

Les sources traitées ne contiennent aucune source primaire de HL7 International sur l'historique des versions ou le statut de HL7 v2 ; les versions mentionnées sur cette page proviennent de profils IHE et de documentation produit ^[1][2]. Mirth Connect a actualisé, dans la release 3.12.0, la bibliothèque HAPI pour HL7 v2.7 et versions ultérieures^[3].

En Belgique, des sous-comités techniques de HL7 Belgium traitent des sujets relatifs à l'implémentation de HL7 version 2.^[5] Agoria propose depuis 2016 des académies portant notamment sur HL7 FHIR, IHE XDS et HL7v2.^[6]

Transport, acquittement et composants logiciels

MLLP et le traitement des ACK doivent être pris en charge des deux côtés^[4]. La bibliothèque open source HAPI HL7v2 a été lancée par University Health Network et est indépendante de l'organisation HL7^[7]. HAPI dispose d'une double licence MPL ou GPL et peut être utilisée sans redevance dans des logiciels open source comme closed source^[8]. Le composant HL7 d'Apache Camel traite le MLLP et les messages HL7 v2 avec HAPI^[9]. Les produits InterSystems peuvent router des messages HL7 v2 entre applications^[10].

Les sources traitées ne contiennent aucune spécification belge officielle de la plate-forme eHealth, de HL7 Belgium ou du SPF pour des messages HL7 v2 de demande ou de résultat entre le dossier patient informatisé et le SIL. La preuve d'un usage belge est indirecte :

Interprétation : « HL7 » et « HL7 IHE » sans version dans la documentation des fournisseurs renvoient probablement à HL7 v2 et à IHE LTW, mais les sources ne le disent pas explicitement ^[14][13].

HL7 v2 n'est pas un standard d'échange national belge : les résultats destinés aux médecins généralistes circulent dans le trajet DIGIRELAB sous forme de message FHIR que le SIL génère lui-même (voir Guide d'implémentation FHIR belge pour les résultats de laboratoire (hl7.fhir.be.lab)) ^[15]. Celui qui utilise HL7 v2 en interne et livre du FHIR ou du KMEHR vers l'extérieur peut déployer à cette fin une couche de traduction ; InterSystems Health Connect contient des transformations entre FHIR et HL7 v2^[16]. Le service Azure FHIR positionne également la conversion de HL7v2 vers FHIR R4 comme élément d'un pipeline ETL^[17].

Recommandation (propre) : lors d'un marché public portant sur un SIL ou un dossier patient informatisé, fixez l'interface de messagerie interne sous forme de transactions IHE LTW (avec version HL7 v2 et types de message), de sorte que l'un des deux systèmes puisse être remplacé plus tard ; demandez par ailleurs séparément la prise en charge de FHIR pour les flux externes.

• L'usage belge de HL7 v2 autour du laboratoire n'est étayé que par des affirmations de fournisseurs et par un cahier des charges en dehors du laboratoire ; les types de message et les versions par installation sont inconnus. ^[12][11]
• Aucune information n'a été trouvée sur l'utilisation d'ORM ou d'OML par les dossiers patients informatisés belges ; c'est une lacune, non une preuve d'absence.