HL7 version 2 est une norme internationale de messages pour l'échange événementiel entre applications de soins, par exemple des données de patients, des demandes de laboratoire et des résultats. Le profil IHE Laboratory Testing Workflow fixe, pour le laboratoire, les structures de messages et les transactions entre le DPI, le système d'information de laboratoire et l'automatisation du laboratoire. Les messages circulent généralement via MLLP avec des accusés de réception techniques. Pour les hôpitaux belges, HL7 v2 est surtout pertinent pour les interfaces internes ; une spécification nationale belge officielle n'a pas été trouvée.
", "last_verified": "2026-11-09", "verification_outdated": false, "sections": [ { "id": "qu-est-ce-que-c-est", "title": "Qu'est-ce que c'est ?", "kind": "tekst", "html": "HL7 version 2 (HL7 v2) est un standard international de messagerie pour l'échange entre applications au sein de\nl'hôpital et autour de celui-ci. La version 2.4 prend par exemple en charge les messages ORU afin de transférer des\nrésultats de laboratoire vers d'autres systèmes.[1] Le profil IHE Laboratory Testing Workflow (LTW)\ndéfinit cinq transactions, toutes basées sur HL7 version 2.5 ou 2.5.1.[2] Chaque transaction LTW\nutilise un sous-ensemble des structures de message OML, ORL, ORU et OUL.[2]
\nPour le transport sur le réseau, IHE prescrit le Minimal Lower Layer Protocol (MLLP).[4] IHE prend en\ncharge les deux modes d'acquittement de HL7 v2.5, Original et Enhanced Acknowledgement Mode.[4]
" }, { "id": "comment-est-il-structure", "title": "Comment est-il structuré ?", "kind": "tekst", "html": "IHE LTW spécifie les interfaces entre les systèmes d'information clinique, le SIL et l'automatisation de\nlaboratoire, de sorte qu'un de ces systèmes puisse être remplacé sans rompre les flux de données existants.\n[2] Une demande peut ainsi passer directement du système clinique du service vers le SIL, sans que le\nlaboratoire saisisse l'ordre manuellement.[2] Voir Interface entre SIL et dossier patient informatisé pour l'application belge et\nles alternatives.
\nLes sources traitées ne contiennent aucune source primaire de HL7 International sur l'historique des versions ou le\nstatut de HL7 v2 ; les versions mentionnées sur cette page proviennent de profils IHE et de documentation produit\n[1][2]. Mirth Connect a actualisé, dans la release 3.12.0, la bibliothèque HAPI pour\nHL7 v2.7 et versions ultérieures[3].
\nEn Belgique, des sous-comités techniques de HL7 Belgium traitent des sujets relatifs à\nl'implémentation de HL7 version 2.[5] Agoria propose depuis 2016 des académies portant\nnotamment sur HL7 FHIR, IHE XDS et HL7v2.[6]
\nMLLP et le traitement des ACK doivent être pris en charge des deux côtés[4]. La\nbibliothèque open source HAPI HL7v2 a été lancée par University Health Network et est indépendante de\nl'organisation HL7[7]. HAPI dispose d'une double licence MPL ou GPL et peut être utilisée sans\nredevance dans des logiciels open source comme closed source[8]. Le composant HL7 d'Apache Camel\ntraite le MLLP et les messages HL7 v2 avec HAPI[9]. Les produits InterSystems peuvent router des\nmessages HL7 v2 entre applications[10].
" }, { "id": "ou-est-il-utilise", "title": "Où est-il utilisé ?", "kind": "tekst", "html": "Les sources traitées ne contiennent aucune spécification belge officielle de la plate-forme eHealth, de HL7 Belgium\nou du SPF pour des messages HL7 v2 de demande ou de résultat entre le dossier patient informatisé et le SIL. La\npreuve d'un usage belge est indirecte :
\n| Preuve | \nNature | \nClaim | \n
|---|---|---|
| Un cahier des charges PACS d'un hôpital belge (2018) demandait des interfaces avec notamment le dossier patient informatisé et le hub, ainsi que des messages HL7 de type ADT, ORU et ORC (pas spécifiquement laboratoire) | \nfait (cahier des charges) | \n[11] | \n
| Des processors de la FHIR Box d'Amaron convertissent HL7 ORU (résultats), SIU (rendez-vous) et ADT (données patient) en FHIR | \naffirmation du fournisseur | \n[12] | \n
| Labo en Ligne maintenait en 2014, dans un laboratoire privé de Gand, une communication « HL7 IHE » bidirectionnelle avec GLIMS | \naffirmation du fournisseur | \n[13] | \n
| Clinisys CyberLab échange des données avec des SIL et des systèmes d'information hospitaliers via HL7 et HPRIM (aucune version mentionnée) | \naffirmation du fournisseur | \n[14] | \n
Interprétation : « HL7 » et « HL7 IHE » sans version dans la documentation des fournisseurs renvoient\nprobablement à HL7 v2 et à IHE LTW, mais les sources ne le disent pas explicitement\n[14][13].
" }, { "id": "qu-est-ce-que-cela-signifie-pour-un-hopital", "title": "Qu'est-ce que cela signifie pour un hôpital ?", "kind": "tekst", "html": "HL7 v2 n'est pas un standard d'échange national belge : les résultats destinés aux médecins généralistes circulent\ndans 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))\n[15]. Celui qui utilise HL7 v2 en interne et livre du FHIR ou du KMEHR vers l'extérieur peut déployer à\ncette fin une couche de traduction ; InterSystems Health Connect contient des transformations entre FHIR et\nHL7 v2[16]. Le service Azure FHIR positionne également la conversion de HL7v2 vers FHIR R4 comme\nélément d'un pipeline ETL[17].
\nRecommandation (propre) : lors d'un marché public portant sur un SIL ou un dossier patient informatisé, fixez\nl'interface de messagerie interne sous forme de transactions IHE LTW (avec version HL7 v2 et types de message), de\nsorte que l'un des deux systèmes puisse être remplacé plus tard ; demandez par ailleurs séparément la prise en\ncharge de FHIR pour les flux externes.
" }, { "id": "incertitudes-et-informations-contradictoires", "title": "Incertitudes et informations contradictoires", "kind": "tekst", "html": "