HL7 v2 — Health Level Seven Messaging

La norme dominante d'échange de données cliniques depuis 1989. Pipe-delimited, pragmatique, omniprésente dans les SIH dans le monde entier.

Qu'est-ce que HL7 v2 ?

HL7 v2 est un standard de messagerie applicative pour l'échange de données cliniques, administratives et financières en santé. Il décrit comment encoder un événement clinique — admission d'un patient, demande d'analyse, résultat de laboratoire, mouvement de facturation — sous la forme d'un message texte délimité par des caractères réservés (|, ^, ~, \, &), et comment l'acheminer entre deux applications (SIH, SIL, RIS, PACS, ERP hospitalier…) sur un protocole tiers (MLLP en TCP, sFTP, files JMS, HTTPS).

La force du standard tient à sa pragmatique : il a été conçu par et pour les intégrateurs cliniques au tournant des années 1990 — quand chaque système hospitalier parlait son propre dialecte — et a privilégié la souplesse syntaxique sur la rigueur sémantique. Résultat : presque tous les éditeurs majeurs (Epic, Cerner/Oracle Health, Allscripts, MEDITECH, Maincare, Dedalus…) parlent v2, mais chacun avec des extensions locales que les guides d'implémentation (IG) sectoriels viennent contraindre.

HL7 v2 reste, en 2026, la norme la plus déployée en clinique malgré l'essor de FHIR : l'écosystème logiciel compte des dizaines de milliards de messages échangés par jour à l'échelle mondiale, et un projet FHIR sur trois s'appuie en pratique sur des passerelles v2 ↔ FHIR pour les flux temps réel.

Anatomie d'un message HL7

Un message HL7 v2 est une suite de segments séparés par <CR> (0x0D). Chaque segment commence par un identifiant à trois lettres (MSH, PID, PV1, OBR, OBX…), suivi de ses champs séparés par |. Les champs eux-mêmes peuvent être décomposés en composants (^), sous-composants (&) et répétitions (~). Voici une trame d'admission patient minimaliste (message ADT^A01, version 2.5.1) :

MSH|^~\&|HIS|HOSP01|EHR|CLINIC02|20260514102530||ADT^A01^ADT_A01|MSG00001|P|2.5.1
EVN|A01|20260514102530|||DRJONES^Jones^Sarah
PID|1||MRN567890^^^HOSP^MR||DOE^JOHN^A^^MR.||19720515|M|||100 MAIN ST^^ANYTOWN^CA^90210^USA||(555)555-1234|||S||ACCT123456
PV1|1|I|ICU^101^A^HOSP01|EM|||DRSMITH^Smith^James^A^^DR.|||CAR|||1|||DRSMITH^Smith^James^A^^DR.|ADM|VIP|||||||||||||||||||HOSP01|||||20260514102530

Le segment MSH (Message Header) est mandatoire et toujours en première position. Il porte :

• MSH-1 — séparateur de champs (| conventionnel).
• MSH-2 — caractères d'encodage (^~\&).
• MSH-3 / MSH-4 — application et facility émettrices.
• MSH-5 / MSH-6 — application et facility réceptrices.
• MSH-7 — date et heure d'émission (CCYYMMDDHHMMSS).
• MSH-9 — type de message (ici ADT^A01^ADT_A01).
• MSH-10 — identifiant de message unique (l'équivalent de l'UNH d'EDIFACT).
• MSH-11 — environnement (P=Production, T=Test, D=Debug).
• MSH-12 — version du standard (2.5.1).

Les segments suivants dépendent du type de message. Pour un ADT : EVN (Event Type), PID (Patient Identification), PV1 (Patient Visit), et éventuellement NK1 (Next of Kin), GT1 (Guarantor), IN1/IN2 (Insurance), AL1 (Allergy), DG1 (Diagnosis).

Versions

HL7 International publie la branche v2 depuis 1989. Les versions co-existent en production : un même intégrateur reçoit fréquemment du v2.3.1 d'un partenaire et du v2.5.1 d'un autre.

Familles de messages

HL7 v2 organise ses messages en grandes familles, identifiées par le code en trois lettres porté par MSH-9 et son trigger event :

Cas d'usage

• Identitovigilance (ADT) — chaque mouvement d'un patient (admission, transfert, sortie, mise à jour démographique) génère un message ADT diffusé du SIH vers tous les SI consommateurs (DPI clinique, PACS, laboratoire, pharmacie).
• Cycle de commande de laboratoire (OML/ORU) — le clinicien prescrit une analyse : un OML est envoyé du DPI vers le SIL ; le résultat revient en ORU dès validation biologique.
• Imagerie médicale (OMI/ORU) — la demande part en OMI vers le RIS, le compte-rendu rédigé revient en ORU. Les pixels eux-mêmes circulent en DICOM hors HL7.
• Pharmacie hospitalière — prescriptions et administrations médicamenteuses transitent via OMP / RDS / RDE selon le moment du cycle.
• Facturation hospitalière (DFT) — chaque acte ou consommable génère un flux DFT vers le module facturation de l'ERP hospitalier.

Comparaison avec EDIFACT

HL7 v2 et EDIFACT partagent l'idée d'une syntaxe à segments délimitée par des caractères réservés, mais s'opposent sur leur philosophie :

À noter : EDIFACT a publié des messages santé (MEDRPT, MEDPRE, MEDRUC) en parallèle de HL7 dans les années 1990, mais sans jamais s'imposer face à HL7 v2 sur ce périmètre. Les flux santé transfrontaliers européens (PEPPOL santé, projet eHDSI) basculent désormais vers FHIR plutôt que vers EDIFACT.

Pour aller plus loin

Pages détaillées des messages HL7 v2 sur ediverse :

• ADT^A01 — Admit / Visit Notification
• ORM^O01 — Order Message

Standards apparentés sur ediverse :

• HL7 FHIR R5 — la couche REST/JSON moderne de HL7
• X12 transactions 270/271/278/834/835/837 — la couche administrative HIPAA aux États-Unis
• Définition EDI — glossaire ediverse

Spécifications officielles à consulter :

• HL7 v2.5.1 — Product Brief (HL7 International, accès gratuit avec inscription).
• Liste des Product Briefs HL7 v2 pour toutes les versions de la branche v2.
• HL7 InM Working Group qui maintient la couche Infrastructure & Messaging.
• Caristix — Online HL7 Definition v2.5.1 référentiel public et navigable (segments, champs, tables).