HL7 1ini1 PDF

Les standards pour les systèmes
d’Information de Santé :
(Série documents d’initiation)
2.1 – HL7 : Health Level 7

Présention générale et HL7 version 2.x
Version 1.0
GMSIH – 374, rue de Vaugirard – 75015 Paris. Tel : 01 48 56 72 70. Fax : 01 48 56 07 70

Les standards en imagerie : 2.1 - HL7 (1ère partie) version 1.0
____________________________________________________________________
Auteur du document : Responsable Qualité

Date :24 septembre 2001
Joël Chabriais Statut : Validé
Date Version Commentaires Statut
31/01/2001 0.1 Création du document Non validé

12/03/2001 0.2 Division du document en 2 Non validé
parties :
- 2.1 concernant la
présentation générale et les
versions 2.x
- 2.2 décrivant la version 3
avec le RIM, la CDA et
CCOW
25/04/2001 0.3 Extension du document Non validé
02/07/2001 0.4 Modification du document Non validé
après première relecture
24/09/2001 1.0 Validation du document Validé
___________________________________________________________________
26/09/01 2/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Sommaire
1. Avertissement .................................................................................................................5
2. Introduction ...................................................................................................................6
2.1. Pourquoi des standards de communication............................................................................ 6
2.2. Interconnexion et interopérabilité ........................................................................................... 9
2.3. Pourquoi HL7............................................................................................................................. 9
2.4. Que signifie « utiliser HL7 » ................................................................................................... 10
3. Historique ....................................................................................................................11
4. HL7 et ses structures....................................................................................................12
5. HL7 version 2.x : .........................................................................................................14
5.1. Prérequis :................................................................................................................................. 14
5.2. HL7 est-il Plug and Play ? ...................................................................................................... 14
5.3. Principes de base d’HL7 :....................................................................................................... 14
5.4. Messages à finalités multiples : .............................................................................................. 18
5.5. Structure d’HL7....................................................................................................................... 18
5.5.1. Les messages ................................................................................................................................... 18
5.5.2. Les segments.................................................................................................................................... 19
5.5.3. Les champs ...................................................................................................................................... 20
5.5.4. Syntaxe des messages résumés (Abstract Message Syntax).......................................................... 21
5.5.5. Les règles d’encodage ..................................................................................................................... 22
5.5.6. Les tables de description des segments .......................................................................................... 22
5.5.7. Exemple de création d’un message HL7 :...................................................................................... 24
5.6. Les messages HL7 version 2.3.1 ............................................................................................. 29
6. Conclusion ...................................................................................................................31
7. Annexe .........................................................................................................................33
___________________________________________________________________
26/09/01 3/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Page Blanche
___________________________________________________________________
26/09/01 4/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
1. Avertissement
La série de documents concernant les standards pour les systèmes
d’information de santé comporte deux catégories de documents :
- les documents dits d’information dont le but est de permettre au lecteur
d’appréhender le domaine d’application du standard et son intérêt sans
entrer dans les détails techniques,
- les documents dits d’initiation qui entrent un peu plus dans les aspects
techniques permettant ainsi de mieux comprendre le standard, sans pour
autant avoir la prétention de permettre d’atteindre le niveau d’expert du
standard.
HL7 est connu avant tout comme un standard de message pour les systèmes
d’information de santé. Depuis le lancement des travaux sur la version 3, ceci
n’est plus tout à fait vrai. En effet, en plus des messages de la version 3 qui
s’inscrivent maintenant dans le cadre d’un modèle d’information (RIM =
Reference Information Model), HL7 propose une architecture de documents
cliniques (CDA = Clinical Document Architecture) et un système de
synchronisation du contexte patient entre applications tournant sur un même
poste de travail (CCOW = Clinical Context Object Working Group). Pour ces
raisons la description d’HL7 a été répartie entre deux documents :
- le premier (2.1) présentant HL7 et décrivant les versions 2.x sur la base de
la version actuellement déployée (2.3.1),
- le second (2.2) présentant la version 3 avec son RIM, la CDA et CCOW.
___________________________________________________________________
26/09/01 5/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
2. Introduction
2.1. Pourquoi des standards de communication
Progressivement depuis la fin des années 70, les systèmes informatisés

ont été de plus en plus utilisés pour réduire les coûts et améliorer la
qualité des soins. Cependant malgré quelques tentatives, aucun système
capable de répondre, à lui seul, à tous les besoins n’a pu être développé.
Dans les années 80, période de l’informatique départementale, de
nombreux systèmes autonomes répondant aux besoins spécifiques des
différents services ont été développés. Ceci a aboutit à une mosaïque de
systèmes d’informations provenant de fournisseurs différents. Pendant ce
temps, les contraintes de gestion nécessitaient une centralisation de
certaines informations. Il est donc apparu nécessaire de faire
communiquer ces systèmes départementaux.
Le niveau le plus basique d’échange d’informations correspond à

l’échange de fichier ASCII par support physique (bande magnétique,
disquette). Un peu plus élaboré est l’échange direct de données par les
applications en utilisant ce que l’on appelle des API (Application
Programmer Interface ou interface de programmation). L’inconvénient de
ces solutions est d’obliger à faire des développements spécifiques à
chaque cas de figure : c’est le monde des interfaces propriétaires.
Un autre moyen, non spécifique celui-là, est d’utiliser des courriers

électroniques. L’inconvénient de cette méthode est qu’il aboutit à une
transmission des informations sans aucune structure formelle ce qui
oblige à prévoir une opération manuelle pour réintégrer les informations
aux bons endroits.
Ce besoin de transmettre les données sous une forme structurée

permettant les traitements automatiques a abouti au développement de
standards de messages. Dans le monde de la santé, deux standards se
sont fait concurrence : les messages EDIFACT et les messages HL7. Plus
récemment on a vu l’émergence de XML, issu directement du monde de
l’Internet. En théorie, lorsqu’une application est conforme à un de ces
standards de messages, elle est capable d’échanger des données avec
n’importe quelle autre application qui se dit conforme à ce même
standard. Ces standards de message se situent au niveau 7
« application » du modèle OSI de l’ISO (Figure 1). C’est pour cette raison
que le standard américain de messages dédiés à la santé s’est appelé
Health Level Seven ou HL7.
___________________________________________________________________
26/09/01 6/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Niveau 7
Application
Niveau 6
Présentation
Fonctions du système applicatif

Niveau 5
Session
Niveau 4
Transport
Niveau 3
Réseau
Niveau 2
Data Link Fonctions réseau
Niveau 1
Physique
Figure 1 : Le modèle OSI à sept couches.

HL7 se situe au niveau supérieur, « Application », du modèle.
En pratique, lorsque seuls deux ou trois systèmes cohabitent dans une

structure des interfaces spécifiques sont encore viables, tandis que la
situation devient vite intenable lorsque le nombre de systèmes croît. Le
nombre d’interfaces à maintenir répond à la formule « ni = ns*(ns-1) » où ni
est le nombre d’interfaces et ns le nombre de systèmes (figure 2).
Aujourd’hui construire un SIH complet dans un établissement de santé
nécessite de 30 à 40 applications différentes. On conçoit la difficulté
d’intégration des systèmes qui en découle en dehors de tout standard
d’échange structuré des données.
___________________________________________________________________
26/09/01 7/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Système de Système
Données radiologie Données d’acquisition
d’images
Cas simple à deux systèmes, éventuellement gérable en interface

spécifique, mais toute modification impose de réviser les interfaces.
d’images
Données laboratoire Données administratif
Données soins Données d’information
infirmiers clinique
Cas plus complexe à 6 systèmes, dans ce cas la communication par

interfaces spécifiques nécessiterait n.(n-1) soit 6 X 5 = 30 interfaces
spécifiques différentes pour assurer la totalité des échanges
envisageables. (Toutes les possibilités ne sont pas montrées).
Figure 2 : Illustration de la complexité croissante de la

problématique de l’interconnexion avec la croissance du nombre de
systèmes.
Dans un hôpital, on peut avoir jusqu’à 30 ou 40 systèmes différents. Si
les interfaces ont été développées, il faut les maintenir et en cas de
changement d’un système, il faut les développer de nouveau avec un
coût élevé.
La comparaison de ces deux exemples permet de comprendre pourquoi
la solution des interfaces spécifiques n’est pas viable, d’où le besoin de
standards de messages permettant de garantir l’interopérabilité des
systèmes sans développement spécifique supplémentaire.
___________________________________________________________________
26/09/01 8/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
2.2. Interconnexion et interopérabilité
S’il est relativement facile d’interconnecter des systèmes, les rendre inter-
opérables nécessite de se mettre d’accord sur la structure des données
échangées. Un certain nombre de points doivent être spécifiés :
- l’ordre dans lequel les données élémentaires sont transmises
(orienté séquence) ou bien comment chacune doit être marquée
par une étiquette codée (tag),
- quel caractère doit séparer les items pour qu’ils puissent être
identifiés,
- quel est le format de chaque item, e.g., comment une date doit être
représentée (syntaxe),
- quelle est la signification de chaque item, e.g., le premier item est le
prénom (sémantique).
2.3. Pourquoi HL7
Il existe de nombreux organismes développant des standards pour

l’informatique de santé à travers le monde. Pourquoi un groupe
supplémentaire ? HL7 a ceci de particulier qu’il se consacre uniquement à
satisfaire les besoins concernant les interfaces entre systèmes dans le
cadre de l’organisation globale de santé. Le seul autre organisme pouvant
revendiquer ce champ d’action était le CEN/TC 251 jusqu’à la création en
1998 de l’ISO/TC 215. En fait, HL7 a œuvré avec force pour la création de
cette dernière structure, seule l’ISO pouvant donner une reconnaissance
mondiale à un standard. Plus récemment un accord a été signé entre le
CEN/TC251 et HL7 dans le but de faire converger et fusionner leurs
travaux respectifs. Finalement il s’avère que cette union va probablement
permettre de définir un seul standard de messages ayant la vocation de
satisfaire tous les besoins des systèmes d’information de santé.
Les principaux buts et apports de HL7 sont :

- rendre disponibles des formats et protocoles pour l’échange de
données entre systèmes informatisé de santé,
- unification des interfaces par la standardisation des formats,
- améliorer l’efficacité des communications,
- un guide pour faciliter le dialogue entre parties lors de la
négociation des dispositions d’interfaçage,
- minimiser le nombre d’interfaces,
- minimiser de 60 à 80 % les dépenses lors du développement des
interfaces,
- proposer un standard international (actuellement accrédité par
l’ANSI et membre de l’ISO/TC 215).
___________________________________________________________________
26/09/01 9/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
HL7
HL7 d’images
HL7
Données laboratoire Données administratif
HL7
HL7
Données soins Données d’information
infirmiers HL7 clinique
Cas plus complexe à 6 systèmes : dans ce cas l’utilisation d’un

standard de messages simplifie considérablement la situation.
Figure 3 : Le deuxième cas de la figure 2 se simplifie avec

l’utilisation d’HL7
Avec l’utilisation d’un protocole de communication comme HL7, une
structure de communication uniforme est réalisée, facilitant l’insertion
d’un nouveau système ou le remplacement d’un système par un autre.
2.4. Que signifie « utiliser HL7 »
Avec l’utilisation d’HL7, il n’est plus nécessaire de commencer au tout

début des développements. Au lieu de cela, la conception des interfaces
peut ce faire à un niveau nettement plus haut. HL7 représente une aide
non négligeable pour intégrer des systèmes d’information hétérogènes.
Cela ne signifie pas pour autant qu’HL7 résout tous les problèmes de
communication. Des négociations extensives doivent avoir lieu entre les
individus et/ou les organisations concernés dans la phase qui précède le
véritable développement des interfaces. En effet, du fait de sa souplesse,
la version actuelle d’HL7 autorise des variations dans l’implémentation des
messages aboutissant à des difficultés de communication si les
partenaires ne s’entendent pas sur la variation qu’ils retiennent.
___________________________________________________________________
26/09/01 10/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
3. Historique
HL7 a été fondé en 1987 pour développer un standard pour les échanges
électroniques d’informations cliniques, financières et administratives entre
systèmes informatiques indépendants dédiés à des applications de santé.
En juin 1994, HL7 a été désigné comme une organisation de développement de
standards accréditée ANSI.
La version 1.0 était un prototype qui a été peu implanté. HL7 a commencé à
s’imposer avec les versions 2.x. La version actuellement implantée est la
version 2.3.2. La version 2.4 est la version officielle la plus récente, mais trop
récente pour exister dans des produits. Devant les insuffisances des versions
2.x, le développement de la version 3.0 a été lancé en 1997 mais sa finalisation
n’est pas attendue avant 2002-2003.
Numéro de version Date de publication Remarque

Version 1.0 1987 Standard prototype
2.0 1988
2.1 1990 Adéquat,
2.2 1994 conditionnement
Version 2.x* arbitraire des
2.3.1 1997 données.
2.4 12/2000 Pas de modèle.
2.5 Annoncée pour 02/2002
1997 (Lancement du Méthodes formelles,
Version 3.0
développement) basé sur un modèle
* Les différences entre les sous-versions relèvent de la maintenance du standard et de son
adaptation permanente aux besoins. Cela se traduit par l’ajout de messages ou champs
manquant ou le retrait de messages ou champs obsolètes ou non utilisés.
___________________________________________________________________
26/09/01 11/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
4. HL7 et ses structures
HL7 est un consortium, à l’origine américain, mais qui s’est internationalisé
progressivement.
L’organisation est gérée par un Conseil des Directeurs (Board of Directors)
composé de de quatre « officiers » (Président, Président-élu ou le précédent
Président, Secrétaire et Trésorier)1, trois membres de droit (Président
technique, Vice-Président technique et le représentant – élu – des Affiliés
Internationaux) et quatre directeurs élus. En dessous siège un Comité de
Direction Technique (Technical Steering Commmittee) qui comprend le
Président d’HL7 et les co-présidents des différents comités techniques et
groupes d’intérêt particuliers. HL7 est ensuite organisé en Groupes de Travail
(Working Group), qui comprennent des Comités Techniques (TC) et des
Groupes d’Intérêt Particulier (SIG) ayant la responsabilité de définir les
protocoles standards d’HL7. Chaque TC ou SIG est présidé par au moins deux
co-présidents. Les co-présidents constituent collectivement le Comité de
Direction Technique qui vote sur les questions concernant le standard. Les
votes du Comité de Direction Technique sont transmis comme
recommandations au Conseil des Directeurs qui prend la décision finale. Les
membres d’HL7 sont encouragés à participer activement à tous ces comités.
Board of Directors
Direction des affaires
Élus
Technical Steering Committee

Affaires techniques
Responsables désignés plus présidents
Des comités & SIGs
The Working Group

Le "vrai" HL7
N’importe quel membre peut s’inscrire
À n’importe quel comité ou SIG
Technical Committees Special Interest Groups

Créent les spécifications normatives Collabore dans un domaine d’intérêt pour
Ou chapitres du standard contribuer aux travaux des TCs
Figure 4 : Organigramme d’HL7

HL7 repose sur des collaborateurs volontaires des organisations
membres. Le nombre de salariés est limité aux besoins du secrétariat.
Les principaux moyens financiers proviennent des cotisations des
membres.
HL7 comporte plus de 500 organisations membres avec un total d’environ 1500
membres inscrits. Plus de 500 participent aux réunions des groupes de travail.
1
Cette structure « Chair, Chair-Elect, Past-Chair » est fréquente dans les associations anglo-
saxonnes. Le Président en exercice est le « Chair », son successeur est le « Chair-Elect »
tandis que son prédécesseur est le « Past-Chair » Les attributions de chacun doivent être
clairement définies dans les statuts de l’association. Cette structure est censée garantir une
certaine continuité dans le gouvernement de l’Association.
___________________________________________________________________
26/09/01 12/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Il ya maintenant 15 Affiliés Internationaux : Afrique du Sud, Australie, Argentine,
Canada, Chine, Finlande, Allemagne, Inde, Japon, Corée, Pays-Bas, Nouvelle-
Zélande, Royaume-Uni, Suisse, Taïwan.
___________________________________________________________________
26/09/01 13/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
5. HL7 version 2.x :
Cette description est basée sur la version 2.3.1, la seule implantée dans des
produits commercialisés au moment de la rédaction de ce document. Bien que
la 2.4 vienne d’être publiée, elle n’est pas encore implantée par les industriels.
5.1. Prérequis :
HL7 ne demande aucun pré-requis en terme d’architecture système :

- Le système de communication peut-être centralisé ou distribué,
- Il n’est pas nécessaire d’implémenter la totalité d’HL7, en général
on commence par la transmission des données administratives des
patients,
- L’échange de données entre systèmes peut être implanté en
utilisant différents systèmes d’exploitation ou langage de
programmation,
- En règle générale, la communication à travers un réseau est sous-
entendue, mais n’est pas requise.
La plus grande variété de support de communication est concevable,
depuis les interconnexions en réseau (TCP/IP, IPX, Apple Talk, …), aussi
bien que par les liaisons séries (RS 232 ou autre) ou les entrées en batch
en utilisant des disquette ou tout autre support physique. Les transactions
isolées ou multiples sont supportées.
5.2. HL7 est-il Plug and Play ?
La variabilité des procédures dans le domaine de la santé complique le

développement d’un modèle de données universel. À l’origine, HL7 n’a
pas fait d’hypothèse a priori sur l’architecture des systèmes : à l’heure
actuelle, HL7 ne peut donc toujours pas être utilisé comme une interface
« plug and play ».
Pourtant HL7 est une étape importante vers l’interopérabilité dans la

communication. Même si HL7 n’est pas encore « plug and play », il
économise beaucoup de temps et d’argent aussi bien pour les utilisateurs
que pour les éditeurs de logiciels. Dans les futures versions, HL7 poursuit
l’ambition de définir un modèle d’information pour la santé.
5.3. Principes de base d’HL7 :
Normalement un événement du monde réel initie l’échange de données

entre deux systèmes. Par exemple, un patient est admis à l’hôpital. Ses
renseignements administratifs (nom, date de naissance, information sur
les proches, assurances sociales, etc.) sont enregistrés dans le serveur
d’identité. Un événement « admission de patient » amène à un échange
de données, e.g., entre le serveur d’identité et un système d’information
___________________________________________________________________
26/09/01 14/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
de laboratoire. Dans HL7 un tel événement est appelé un « trigger event »
ou événement déclencheur.
D’une manière générale, on distingue deux catégories de messages :

- une mise à jour non sollicitée comme dans l’exemple ci-dessus,
- une requête, e.g., la question spécifique du sous-système de
laboratoire pour savoir si les renseignement administratifs du
patient sont disponibles.
Événement déclenchant
ou Trigger
Envoie un Reçoit un
message HL7 message HL7
Reçoit un Envoie un
Réseau
accusé de accusé de
réception HL7 réception HL7
Système A Système B
Figure 5 : Principe de base d’HL7

Un événement déclenchant du monde réel (élément déclenchant ou
trigger) déclenche l’échange de données entre deux systèmes ou plus.
Une telle « mise à jour non sollicitée » (voir Figure 6) est produite par un
évènement (e.g., admission d’un patient). Cet évènement conduit à une
transaction interne dans le système expéditeur comme une insertion dans
une base de donnée. Ensuite les données sont expédiées en utilisant
HL7. Le receveur reçoit un message et peut réagir par une transaction.
___________________________________________________________________
26/09/01 15/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Admission
d’un patient
Système
Système A01 Données de service
des clinique
Données
admissions
A01
A01
Système Système de
Données de Données service de
laboratoire soins intensifs
Figure 6 : Admission d’un patient

Dans HL7 l’événement « admission d’un patient » déclenche un échange de données
au moyen d’un message A01. Le système expéditeur (ici le système de service
clinique) doit adresser le message A01 aux autres sous-systèmes. Typiquement des
moteurs d’interface sont utilisés pour la distribution des données. Le système
expéditeur transmet les données vers le moteur d’interface qui enverra le message à
tous les systèmes concernés par les informations d’admission.
Sous -système
Admission Données de banque du
sang
d’un patient
ADT
ACK
Sous -système
ADT Données de chirurgie
Sous-système
des admissions
ACK
Données ADT
Sous-système
Données d’ORL
ACK
Figure 7 : Accusé de réception (ACK)

Après réception d’un message d’admission (ADT) émis par le
sous-système des admissions, les autres sous-systèmes peuvent
confirmer à l’expéditeur que le message a bien été reçu
___________________________________________________________________
26/09/01 16/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Transfert du
patient vers les
soins intensifs
Système
Système A02 Données de service
Données des clinique
admissions
A02
A02
Système Système de
Données de Données service de
laboratoire soins intensifs
Figure 8 : Transfert d’un patient

En utilisant des messages A02, l’événement « transfert de patient » peut être
communiqué aux différents sous-systèmes
Pendant une transaction dans un système, une requête (query) est

générée si des données sont manquantes. Le receveur de la requête peut
répondre ; à part cela, aucune autre transaction n’est faite. La réponse
permet de compléter la transaction sur le système demandeur.
Sous-système Message de requête

des admissions
« Patient inconnu »
Données
Réponse à la requête Données Sous-système
de laboratoire
Figure 9 : Requête
Si un patient est inconnu, e.g., dans le sous-système de laboratoire, une
question utilisant une requête HL7 peut être générée et adressée au système
administratif (ADT dans HL7). La réponse contient les informations patient
manquantes.
___________________________________________________________________
26/09/01 17/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
5.4. Messages à finalités multiples :
HL7 ne définit pas uniquement des messages pour les données

administratives. Par exemple, HL7 propose des messages pour :
- ADT (Admission, Discharge and Transfer : admission, facturation et
transfert) concernant la gestion administrative des patients
- requêtes d’informations
- prescriptions (prescriptions ordinaires, pharmaceutiques,
diététiques, gestion des vaccinations, commande de fournitures)
- résumés d’observations (prescriptions ordinaires, essais cliniques)
- résultats d’expérience
- résultats d’enregistrement de signaux physiologiques, e.g., EEG,
ECG
- réferencences au patient
- gestion financière
- fichiers maîtres
- soins aux patients
- programmation
- information sur les interactions médicamenteuses
- dossier médicaux/gestion des informations.
5.5. Structure d’HL7
Dans HL7, le contenu des messages peut être défini :

- dans des tables de valeurs définies dans le standard HL7 lui-même,
- dans des tables définies par les utilisateurs,
- par des références à des tables de codes ou à d’autres standards
- simplement comme des données (nom du patient, identifiant du
patient…).
Un message HL7 respecte la structure hiérarchique : message, segment,

champ. Les messages sont écrits selon des règles de syntaxe spécifiques
à HL7 et en respectant des règles d’encodage.
Tout ce qui suit est décrit de manière détaillée dans le chapitre 2 du
standard HL7 2.3.1.
5.5.1. Les messages
Un message est le plus petit élément communicable. Il est composé

de segments, eux-mêmes subdivisés en champs.
Segment Segment
Message Champ Champ Champ Champ Champ Champ
Figure 10 : Structure de base d’un message HL7

Par exemple le message qui va transmettre les données concernant l’admission d’un
patient est identifié par le type de message « ADT » avec pour trigger A01 : ADTÂ01
___________________________________________________________________
26/09/01 18/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Le message est identifié par son type (par exemple ADT) et par
l’événement déclenchant ou « trigger event » (par exemple
admission du patient). Il commence toujours par le segment en-tête
de message ou MSH (Message Header Segment) suivi par un
segment qui définit le « trigger event » ou EVN (EVeNt).
5.5.2. Les segments
Les segments sont constitués d’une séquence ordonnée de champs.

Ils peuvent être déclarés comme étant obligatoires, optionnels ou
répétables.
Les segments sont clairement identifiés par trois lettres situées à leur
début et constituant ce qu’HL7 appelle le « segment identifier ». Les
différents segments sont séparés par les séparateurs de segment.
Ainsi en reprenant le type de représentation de la figure 10, le
message ADT, est constitué des segments suivants : MSH, EVN,
PID, PV1, … comme représenté figure 11.
Message ADT MSH EVN PID PV1 …
Figure 11 : Représentation schématique d’un message ADT

Le message comporte les segments suivants : MSH (Message Segment Header),
EVN qui contient la description de l’évènement déclenchant, PID l’identification du
patient, PV1 les informations sur la visite actuelle du patient …
Il faut savoir que tous les messages commençant par un Z sont

réservé pour des messages spécifiques à usage local.
Le standard HL7 ne définit aucun segment Z. Habituellement ils sont

déterminés et coordonnés par des groupes d’utilisateurs nationaux.
___________________________________________________________________
26/09/01 19/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
5.5.3. Les champs
Le contenu sémantique des messages est contenu par les champs

des segments.
Segment
Champ Champ Champ Champ Champ Champ Champ Champ
Figure 12 : Structure des segments

Un segment d’un message contient plusieurs champs. Ce sont ces champs qui
sont porteurs de toute la sémantique du message.
Les champs peuvent être de longueur variable et ils sont séparés par
des séparateurs de champ. Un type de donnée est défini pour
chaque champ, e. g. chaîne de caractère, valeur numérique… Le
tableau suivant montre un certain nombre de types de données
permis extraits de la cinquantaine qu’HL7 décrit dans sa partie 2.8 :
ST Chaîne de caractère XPN Nom de personne

TX Texte XAD Adresse
FT Texte formaté XTN Numéro de téléphone
NM Numérique ID Valeur codée (table HL7)
D Date IS Valeur codée (table utilisateur)
T Heure CM Composite (*)
TS Horodatage CN Identifiant et nom
PL Lieu où se trouve la personne CQ Quantité et unité
(*) Les champs composites sont définis comme la combinaison de plusieurs champs de
données. Chaque partie d’un champ composite est appelé un « composant ».
Le contenu des champs peut être obligatoire ou optionnel. Des

champs particuliers peuvent être répétés. Les définitions des champs
sont administrées par des dictionnaires de données. Pour les
éléments codés, les codes pertinents sont stockés dans des tables.
Le tableau suivant montre l’exemple d’une table de codes « Table
0001, définie par l’utilisateur – Sexe » avec ajout de la traduction
française.
___________________________________________________________________
26/09/01 20/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Type Table Nom Valeur Description Traduction en français

User 0001 Sex Sexe
0001 F Female Femme
0001 M Male Homme
0001 O Other Autre
0001 U Unknown Inconnu
Des champs multi-valués sont utilisés pour subdiviser le contenu

d’un champ et faciliter la transmission de contenus sémantiques
reliés logiquement en utilisant un type de donnée CE (Coded
Element ou élément codé) :
CN Numéro d’identification + nom

CE Élément codé :
Valeur du code + désignation du code + système de codage
CQ Quantité + unité
MO Prix + type de monnaie
Exemple :
CN 00967^Henri^Dupont^^Dr. Med.
CE 620.2^Kyste de l’ovaireÎ9
CQ 17,2^g/dl
MO 75,55^FF
5.5.4. Syntaxe des messages résumés (Abstract Message Syntax)
Par la suite nous utiliserons l’acronyme AMS pour désigner cette

syntaxe. Dans HL7, le niveau de définition le plus basique est celui
qui associe un message résumé avec un événement déclencheur
particulier. La définition du message résumé inclut les champs de
données qui seront envoyés avec le message, les messages de
réponse valides et le traitement des erreurs du niveau application ou
l’échec des couches plus basses du système de communication. Un
message résumé HL7 est une suite de caractères de contrôle et de
segments de données dont la fréquence d’occurrence (cardinalité) et
certaines caractéristiques (obligatoire, optionnel, répétable) peuvent
être décrites avec la syntaxe de message résumé.
Les segments obligatoires sont simplement définis par leurs

identificateurs, les segments optionnels sont entre crochets [ ] et les
segments répétables entre accolades { }. Des champs peuvent être
simultanément optionnels et répétables, ce qui s’exprime sous deux
formes équivalentes : {[ ]} ou [{ }].
Chaque message commence par les informations concernant le

message lui-même (en-tête de message MSH, description
d’événement EVN, etc). Les segments suivant concernent en
___________________________________________________________________
26/09/01 21/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
général le patient lui-même (identifiant patient PID, Informations
concernant la visite du patient PV1 et PV2, mention des allergies
éventuelles AL1 …). Les informations complémentaires sont ensuite
transmises (demande, résultat, données d’examen, facturation …).
Ainsi le message ADT02 dont il était question dans l’exemple de la
figure 8 et son accusé de réception sont spécifiés de la manière
suivante dans HL7 :
Identifiant du message
Identifiant du segment ADT ADT Message Chapter
MSH Message Header 2

EVN Event Type 3
PID Patient Identification 3
[PD1] Additional Demographics 3
Optionnel PV1 Patient Visit 3
[ PV2 ] Patient Visit - Additional Info. 3
[ { DB1 } ] Disability Information 3
[ { OBX } ] Observation/Result 7
Optionnel et répétable
ACK General Acknowledgment Chapter
MSH Message Header 2

MSA Message Acknowledgment 2
[ ERR ] Error 2
La colonne « Chapter » fait référence au chapitre d’HL7 où le

segment est décrit.
5.5.5. Les règles d’encodage
HL7 défini des règles de construction de messages appelées « HL7

encoding rules ». HL7 décrit deux groupes de règles : un groupe qui
peut être considéré comme les règles de bases et un groupe appelé
« extended encodage rules » permettant de gérer les segments
valides pour plusieurs messages. Par ailleurs lorsque la situation
locale l’exige, HL7 accepte l’utilisation de règles d’encodages
spécifiques au site. HL7 ne fixant pas de longueurs fixes aux
champs, les règles d’encodage définissent en particulier des
caractères de séparation :
| Séparateur de champ
^ Séparateur d’élément ou composant
~ Séparateur de répétition
\ Caractère d’échappement
& Séparateur de sous-composant
5.5.6. Les tables de description des segments
Les descriptions précises des segments et de leurs attributs se

trouvent dans la table des segments. Nous donnerons en exemple la
table du segment PID qui contient l’identification du patient.
___________________________________________________________________
26/09/01 22/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Le tableau ci-dessous donne la signification des en-têtes des
colonnes des tables de segments :
SEQ Position (numéro séquentiel dans le segment)

LEN Longueur maximale
DT Type des données
R/O Obligatoire ou optionnel
RP/# Repétitivité
TBL# Numéro de la table (pour les éléments définis par
référence)
ITEM# Numéro de l’item
… Nom de l’élément
Table du segment PID (P = patient ; ID = identifiant):
SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME Nom de l’élément en français
1 4 SI O 00104 Set ID - PID ID de la transaction
2 20 CX B 00105 Patient ID ID patient
3 20 CX R Y 00106 Patient Identifier List Liste d’identificateur patient
4 20 CX B Y 00107 Alternate Patient ID - PID ID patient alternatif
5 48 XPN R Y 00108 Patient Name Nom du patient
6 48 XPN O Y 00109 Mother’s Maiden Name Nom de jeune fille de la mère
7 26 TS O 00110 Date/Time of Birth (DOB) Date et heure de naissance
8 1 IS O 0001 00111 Sex Sexe
9 48 XPN O Y 00112 Patient Alias Alias pour le patient
10 80 CE O Y 0005 00113 Race Race
11 106 XAD O Y 00114 Patient Address Adresse du patient
12 4 IS B 0289 00115 County Code Code du canton
13 40 XTN O Y 00116 Phone Number - Home Numéro de téléphone -
Domicile
14 40 XTN O Y 00117 Phone Number - Business Numéro de téléphone -
Bureau
15 60 CE O 0296 00118 Primary Language Langue maternelle
16 80 CE O 0002 00119 Marital Status Etat-civil
17 80 CE O 0006 00120 Religion Religion
18 20 CX O 00121 Patient Account Number Numéro de compte du patient
19 16 ST B 00122 SSN Number - Patient Numéro de SS du patient
20 25 DLN O 00123 Driver's License Number - Patient Numéro de permis de
conduire du patient
21 20 CX O Y 00124 Mother's Identifier Identificateur de la mère
22 80 CE O Y 0189 00125 Ethnic Group Groupe ethique
23 60 ST O 00126 Birth Place Lieu de naissance
24 1 ID O 0136 00127 Multiple Birth Indicator Indicateur de naissances
multiples
25 2 NM O 00128 Birth Order Ordre de naissance
26 80 CE O Y 0171 00129 Citizenship Citoyenneté
27 60 CE O 0172 00130 Veterans Military Status Statut militaire
28 80 CE O 0212 00739 Nationality Nationalité
29 26 TS O 00740 Patient Death Date and Time Date et heure de décès du
patient
30 1 ID O 0136 00741 Patient Death Indicator Indicateur de décès du
patient.
___________________________________________________________________
26/09/01 23/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Il est à noter que l’utilisation des valeurs de certains champs de cette

table est interdite par la réglementation française :
SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME Nom de l’élément
10 80 CE O Y 0005 00113 Race Race
22 80 CE O Y 0189 00125 Ethnic Group Groupe ethnique
D’autres éléments n’ont pas de sens dans la pratique française, par

exemple le numéro de permis de conduire : aux États-Unis, le permis
de conduire fait également office de carte d’identité.
L’utilisation éventuelle d’HL7 en France ne pose cependant pas de

problème car ces champs dont l’usage est interdit ou qui n’ont pas
de sens chez nous sont des champs optionnels. Il suffirait de
spécifier des règles d’implantation d’HL7 dans des logiciels destinés
à une utilisation en France en y précisant les champs à ne pas
utiliser.
5.5.7. Exemple de création d’un message HL7 :
Nous allons prendre l’exemple du patient décrit ci-dessous pour voir

comment se construit un message HL7. Nous prendrons l’exemple
de l’admission d’un patient dont les éléments d’identification sont :
Durand, Jean
Homme
Né le : 24/08/1940
Marié
10, Impasse de la Fontaine

76740 Fontaine le Dun
Tél. : 02 48 34 45 78
L’événement déclencheur (trigger) A01 est utilisé pour l’évènement

« Le patient a été admis ». Le message qui va être généré est donc
le message ADT01. En suivant les règles de l’AMS, le message 01
est construit avec les segments suivants :
Message ADT MSH EVN PID PV1 …
En-tête de message Description de l’évènement Identification du patient Information sur la visite du patient
___________________________________________________________________
26/09/01 24/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Dans l’exemple nous allons nous concentrer sur le segment PID. Les
différents champs vont être remplis en suivant les instructions
contenues dans la table de description dusegment PID.
SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME Nom de l’élément en français
1 4 SI O 00104 Set ID - PID ID de la transaction
2 20 CX B 00105 Patient ID ID patient
3 20 CX R Y 00106 Patient Identifier List Liste d’identificateur patient
4 20 CX B Y 00107 Alternate Patient ID - PID ID patient alternatif
5 48 XPN R Y 00108 Patient Name Nom du patient
6 48 XPN O Y 00109 Mother’s Maiden Name Nom de jeune fille de la mère
7 26 TS O 00110 Date/Time of Birth (DOB) Date et heure de naissance
8 1 IS O 0001 00111 Sex Sexe
…
11 106 XAD O Y 00114 Patient Address Adresse du patient
…
16 80 CE O 0002 00119 Marital Status Etat-civil
18 20 CX O 00121 Patient Account Number Numéro de compte du patient
…
« 1 » ID de la transaction : le type de données est SI (pour

sequence ID). Ce doit être un entier non négatif selon les
règles décrites pour le type de données NM (numérique). Pour
la première occurrence du segment sa valeur pourra être 1,
pour le seconde occurrence elle pourra être 2, etc. Ce numéro
de transaction est attribué par le système expéditeur et
permettra de se référer ultérieurement à cette transaction en
cas de besoin. Pour notre exemple,disons que le numéro de
transaction sera :
|856621|
« 2 » ID patient : le type de donnée est CX (ID composite étendu

avec chiffre de contrôle ; ce chiffre de contrôle est donné par
l’application en utilisant un algorithme modulo 11 décrit dans
la section 2.8.5.3 du standard). Ce champ est composé de la
manière suivante :
<ID (ST)> ^ <chiffre de contrôle (ST)> ^ <code

identifiant le schéma employé pour créer le
chiffre de contrôle (ID)> ^ <instance allouant
l’identifiant (HD)> ^ <code de type
d’identifiant (IS)> ^ <guichet allouant
l’identifiant (HD)
Les composants inutilisés à la fin du champ comme « instance

allouant l’identifiant » peuvent également être laissés en
blanc. Dans notre exemple si l’ID du patient est 1234567-4 (4
est le chiffre de contrôle en utilisant l’algorithme Modulo 11)
sera codé ainsi :
___________________________________________________________________
26/09/01 25/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
|1234567^4^M11|
note : ce champ est conservé pour compatibilité descendante

mais en principe il n’est plus utilisé dans les nouveaux
développement. Lorsqu’il est utilisé, il correspond à un
identifiant attribué par une autre institution.
« 3 » Patient identifier list : ce champ contient une liste

d’identificateurs (un ou plus) du patient uniquement utilisés par
les institutions pour identifier les patients (e. g., numéro de
dossier médical, numéro de dossier administratif, registre de
naissance, identificateur national unique, etc.). Son type de
données est également CX. Dans notre exemple :
|123^1^M11|
« 4 » Alternate Patient ID : ce champ est conservé pour

compatibilité descendante mais en principe il n’est plus utilisé
dans les nouveaux développement. HL7 recommande de
n’utiliser que le champ n°3 et sa possibilité de liste.
« 5 » Patient Name : le type de donnée est XPN ou « eXtended

Person Name » (nom de personne étendue). Ce champ doit
contenir le nom figurant officiellement à l’état-civil. Tous les
autres noms que le patient peut être amené à utiliser ne
doivent figurer que dans le champ PID 9 « Patient alias ». La
répétition est autorisée pour pouvoir enregistrer le nom avec
différent jeux de caractères (caractères latins accentués ou
non, caractères cyrilliques, etc.).
<nom de famille (ST)> & <préfixe de nom de

famille (ST)> ^ <prénom (ST)> ^ <initiale ou
nom médian (usage américain) (ST)> ^ <suffixe
(e. g., Jr. Ou III – usage américain) (ST)> ^
<préfixe (e. g., Dr.) (ST)> ^ <diplôme (e. g.,
MD, PhD, …) (ST)> ^ <code du type de nom (ID)>
Dans notre exemple nous obtiendrons :
|Durand^Jean|
note 1 : le préfixe de nom de famille a été rajouté récemment

à la demande des allemands pour gérer les préfixes de type
« van » comme dans Ludwig van Beethoven sans
retentissement sur le classement alphabétique. Avec ce
système que l’on se base sur Beethoven ou sur van
Beethoven le résultat de la recherche alphabétique sera le
même. On peut envisager, en France, de reprendre le principe
___________________________________________________________________
26/09/01 26/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
pour gérer les particules. L’initiale ou nom médian ainsi que le
suffixe ne sont pas d’usage chez nous.
note 2 : la notion de diplôme fait appel à une table définie par

l’utilisateur mais HL7 suggère un certain nombre de valeurs
d’usage courant dans la table User-defined table 0360 –
Degree.
note 3 : ce code permet d’identifier le type de nom dont il

s’agit. HL7 attire l’attention sur le fait que le contenu du
« Legal Name » (ou nom d’état-civil chez nous) est très
variable d’un pays à l’autre. Les types de noms sont
récapitulés dans la Table 0200 – Name type.
Valeur Description originale Signification française

A Alias Name Nom alias
L Legal Name Nom d’état-civil, nom légal
D Display Name Nom affiché
M Maiden Name Nom de jeune fille
C Adopted Name Nom adopté
B Name of Birth Nom de naissance
P Name of Partner/Husband Nom du partenaire / de l’époux
« 6 » Mother’s maiden name : c’est également un champ dont le

type de données est XPN mais dont seul le premier
composant est utilisé. HL7 utilise ce champ contenant le nom
de jeune fille de la mère pour faciliter la résolution des
homonymies. Dans notre exemple ce sera :
|Martin|
« 7 » Date of birth : c’est un champ de type TS (horodatage)

utilisant le format de date d’HL7 (aaaammjj) correspondant au
format international standardisé. Dans notre message nous
aurons :
|19400824|
« 8 » Sex : c’est un champ de type IS se référant à la table 0001
Valeur Description Signification française

F Female Femme
M Male Homme
O Other Autre
U Unknown Inconnu
Dans notre exemple :
|M|
« Les champs 9 et 10 » sont laissés vides.
___________________________________________________________________
26/09/01 27/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
« 11 » Patient address : le type de données est XAD (ou eXtended

Address). Les composants de ce champ sont :
<numéro et nom de rue (ST)> ^ <complément

d’adresse (ST)> ^ <ville (ST)> ^ <état ou
province (ST)> ^ <code postal(ST)> ^ <pays
(ID)> ^ <type d’adresse (ID)> ^ <autre élément
géographique (ST)> ^ <comté/code de paroisse
(IS)> ^ <région de recensement (IS)> ^ <code
de représentation de l’adresse (ID)>
Dans notre exemple l’adresse sera codée :`
|10, Impasse de la Fontaine^^Fontaine le Dun

^^76740|
note : si le patient a plusieurs adresses valides, elles peuvent

être enregistrées séquentiellement. Cependant l’adresse
principale devra toujours figurer en premier.
« Le champ 12 » est laissé vide
« 13 » Phone number – Domicile : le type de donnée est XTN

(eXtended Telecommunication Number) et on peut le répéter
autant de fois que nécessaire, le numéro principal doit
toujours figurer en premier. Le format correspond aux usages
locaux. Dans notre exemple il sera :
|0230184585|
« Les champs 14 et 15 » sont laissés vides
« 16 » Marital status : contient un code provenant d’une table définie

par l’utilisateur (IS) dont un certain nombre de valeurs sont
suggérées dans la User-defined table 0002 – Marital status.
Valeur Description Signification française

A Separated Séparé
D Divorced Divorcé
M Married Marié
S Single Célibataire
W Widowed Veuf
Dans notre exemple nous aurons :
|M|
___________________________________________________________________
26/09/01 28/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Les champs restant seront rempli selon le même principe. Les autres
segments devant se trouver dans le message ADT - A01 (MSH, EVN
et PV1) seront remplis de la même manière, dans notre exemple
nous reprendrons des valeurs données dans les exemples d’HL7
pour fournir un aspect global réaliste du message ADT.
Une fois assemblé le message aura cet aspect, nous retrouvons en

caractères gras les éléments de l’exemple expliqués plus haut :
MSH|^~\&|REGADT|MCM|RSP1P8|MCM|199806051530|SEC
|ADTÂ01|00000006|P|2.3<CR>
EVN|A01|199806051529<CR>
PID|856621|1234567^4^M11|123^1^M11|Durand^Jean|
Martin|19400824|M|||10, Impasse de la
Fontaine^^Fontaine le Dun^^76740|
|0230184585|||M|CAT|ACCT1<CR>
PV1|1|I|ENT^12^01||||249^BOHBOH^^Û^^DR.MED.|||
SUR||||ADM|A0|<CR>
5.6. Les messages HL7 version 2.3.1
Les différents messages sont regroupés par grands thèmes faisant

chacun l’objet d’une partie du standard qui comporte douze parties et cinq
annexes :
- Partie 1 : Introduction. Elle décrit le contexte de développement
du standard, les besoins que le standard est destiné à satisfaire,
son champ d’application et pour finir cite un certain nombre de
documents de référence.
- Partie 2 : Control/Query. Cette partie décrit les concept de bases
et les règles génériques applicables aux messages. Elle
comporte, entre autre, la liste des types de messages et celle des
types d’évènements.
- Partie 3 : Patient Administration. Elle regroupe les messages
permettant de transmettre les informations d’identification des
patients (nouvelles ou mises à jour) ainsi que celles concernant
les séjours (au sens large).
- Partie 4 : Order Entry. Cette partie décrit tous les messages
permettant de commander quelque chose au sens large. Il existe
ainsi des messages concernant le linge, l’alimentation, les
diverses fournitures aussi bien que des prescriptions de
traitements à la pharmacie, des demandes d’examens, etc.
- Partie 5 : Query. En fait cette partie est maintenant incluse dans
la partie 2 et elle n’est référencée que pour des raisons de
compatibilité avec les versions antérieures du standard.
___________________________________________________________________
26/09/01 29/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
- Partie 6 : Financial Management. Elle regroupe toutes les
transactions concernant la facturation. Les messages de cette
partie sont calqués sur la pratique, complexe, américaine de la
facturation. Elle a fait considérer qu’HL7 n’était pas applicable
hors des Etats Unis. En fait il est facile de lui ajouter des pays et
c’est un des rôles des affiliés HL7 nationaux que d’adapter les
messages de cette partie aux différentes pratiques nationales.
- Partie 7 : Observation Reporting. Cette partie décrit les
messages permettant de transmettre tous types de données
cliniques. L’usage le plus courant qui en est fait est la transmission
des observations et des résultats d’examens.
- Partie 8 : Master Files. Les messages regroupés dans cette
partie concernent la transmission de ce qui est appelé les fichiers
maîtres. Ce sont les fichiers de référence communs qui sont
souvent retrouvés dans un environnement à architecture ouverte.
Ce sont les fichiers concernant les identifications des personnels,
leurs noms d’utilisateurs et mots de passe, la gestion des
matériels informatiques sur le réseau, les tables de définition des
différents examens (radiologiques par exemple).
- Partie 9 : Medical Records/Information Management. Cette
partie concerne la gestion des documents médicaux et est
destinée à gérer tous types de données concernant le patient.
- Partie 10 : Scheduling. Cette partie décrit les messages
concernant la programmation des rendez-vous.
- Partie 11 : Patient Referral. Dans cette partie HL7 propose des
messages permettant de communiquer des informations entre
structures de santé (et/ou organismes d’assurance sociale)
différentes.
- Partie 12 : Patient Care. Cette partie décrit des messages
« orientés problèmes ».
- Annexe A : Data Definition Table. Cette annexe regroupe les
tables définissant les données.
- Annexe B : Lower layer Protocols. Les informations de cette
annexe ont migré vers le guide d’implémentation d’HL7. Elle n’est
conservée que pour des raisons de compatibilité.
- Annexe C : Network Management. Cette annexe décrit des
segments et champs permettant de faciliter la circulation des
données sur le réseau.
- Annexe D : Version 2.3.1 BNF Message Descriptions. Cette
annexe donne des exemples de représentations BNF de
définitions de messages.
- Annexe E : Glossary. Cette annexe est un glossaire de quelques
termes utilisés par HL7.
___________________________________________________________________
26/09/01 30/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
6. Conclusion
Le standard HL7 v2.x est complexe, il ne comporte pas de réelle modélisation.
C’est en fait un catalogue de messages visant à répondre à un maximum de
besoins dans le cadre des échanges dans un système d’information de santé
informatisé.
Bien que développé au départ pour satisfaire les besoins américains, son
utilisation est de plus en plus répandue à travers le monde. Si bien que dans sa
version actuelle, HL7 est très largement utilisé et se trouve implanté dans la
majorité des systèmes d’information de santé à diffusion internationale.
Il n’existe pas, à l’heure actuelle, d’implantation d’HL7 en XML bien que le sujet
soit d’actualité. HL7 se contente de proposer un guide d’implantation en XML
de la version 2.3.1 et de la version 2.4 agrémenté d’un certain nombre de DTD.
Pour HL7, le véritable saut vers XML est pour la version 3 qui sera d’emblée
proposée en XML.
Son adoption éventuelle en France doit se faire sur des bases pragmatiques :
- Dans le monde de l’imagerie, les investissements sont dominés par le
coût des modalités d’acquisition d’images. Ces modalités sont au
standard DICOM et dialoguent avec le reste du système d’information
soit en DICOM soit en HL7. Il est donc clair que pour cette partie du
système d’information hospitalier l’adoption d’HL7 ne se discute pas.
- Dans d’autres cas, nous avons des produits s’appuyant sur d’autres
types de messages (HPRIM, PHAST, EDI, …), il est probable que la
migration vers HL7 2.x doive être envisagée avec pragmatisme :
o Dans les laboratoires, les messages les plus couramment
utilisés sont les messages HPRIM,
o Pour la pharmacie et la prescription médicamenteuse, les
utilisateurs et les industriels se sont regroupés dans
l’association PHAST/SIPH pour définir les messages standards,
o Dans d’autres secteurs, notamment administratif, les messages
Noemie B2 d’échange avec les caisses d’assurance maladie se
sont imposés.
Dans ces conditions, l’évolution en France vers un standard regroupant

l’ensemble des « spécialités » nécessite une volonté des acteurs de se
regrouper. C’est le cas aujourd’hui avec la décision prise en juin 2001 de créer
un groupe HL7 France au sein de la Commission de Normalisation Informations
de Santé (CNIS) à l’AFNOR. Ce groupe a plusieurs objectifs :
- croiser les messages HL7 et les différents standards de messages
utilisés en France de manière à voir comment dans un premier temps
ils peuvent cohabiter,
- étudier de façon standard l’adaptation aux usages français des
messages HL7 pour éviter toute divergence d’implantation,
- coordonner les associations, industriels et particuliers français décidant
d’adhérer au consortium HL7,
- étudier les modalité et l’intérêt de créer un « Affilié HL7 France ».
___________________________________________________________________
26/09/01 31/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
Enfin, dans l’attente d’HL7 version 3 se pose la question de la version à choisir.

Actuellement la version implantée dans les produits est la version 2.3.1. La
version courante officielle est la 2.4, cependant aux dires d’un certains nombre
de développeurs l’ayant étudiée, cette version pose un certain nombre de
problèmes si bien que la tendance de l’industrie est de ne pas investir dessus
ce d’autant plus que la version 2.5 résolvant les problèmes identifiés dans la 2.4
est déjà annoncée pour février 2002. Les quelques contacts que nous avons pu
avoir laissent à penser que la plupart des industriels internationaux utilisant HL7
décideront de passer directement de la version 2.3.1 à la version 2.5.
___________________________________________________________________
26/09/01 32/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
7. Annexe
Nous reproduisons ci-après la table 0076 regroupant les différents types de
messages. La colonne avec la signification en français est là pour faciliter la
compréhension de ce que font les messages, cependant son contenu ne peut
en aucun cas être considérée comme une traduction officielle des libellés des
messages.
Message Description Signification en Français Chapitre

ACK General acknowledgment message Message d’accusé de réception général 2
ADR ADT response Réponse ADT 3
ADT ADT message Message ADT 3
BAR Add/change billing account Ajout/modification à un compte de 6
facturation
CRM Clinical study registration message Message d’enregistrement d’étude clinique 7
CSU Unsolicited study data message Message de données d’étude non sollicitée 7
DFT Detail financial transactions Transaction de détail financier 6
DOC Document response Document de réponse 9
DSR Display response Affichage de réponse 2
EDR Enhanced display response Affichage enrichi de réponse 2
EQQ Embedded query language query Demande avec inclusion de demande de 2
langue
ERP Event replay response Répétition de l’événement réponse 2
MDM Medical document management Gestion de document médical 9
MFD Master files delayed application Accusé de réception par l’application, 8
acknowledgment retardé, des fichiers maîtres
MFK Master files application acknowledgment Accusé de réception par l’application des 8
fichiers maîtres
MFN Master files notification Notification de fichier maître 8
MFQ Master files query Demande de fichier maître 8
MFR Master files response Réponse à la demande de fichier maïtre 8
OMD Dietary order Prescription diététique 4
OMN Nonstock requisition order message Message de demande de fourniture non en 4
stock
OMS Stock requisition order message Message de demande de fourniture en stock 4
ORD Dietary order - General order Accusé de réception à une prescription 4
acknowledgment message diététique
ORF Query for results of observation Demande de résultats d’examen 7
ORM Pharmacy/treatment order message Message de prescription médicamenteuse 4
ORN Nonstock requisition - General order Accusé de réception de demande de 4
acknowledgment message fourniture non en stock
ORR General order response message response to Message de réponse générique pour toute 4
any ORM prescription médicamenteuse
ORS Stock requisition - General order Accusé de réception de demande de 4
acknowledgment message fourniture en stock
___________________________________________________________________
26/09/01 33/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
ORU Unsolicited transmission of an observation Transmission non sollicitée d’un message 7
message d’examen
OSQ Order status query Demande de statut de la commande 4
OSR Query response for order status Réponse à la demande de statut de la 4
commande
PEX Product experience message Message de connaissances sur un produit 7
PGL Patient goal message Message d’objectif à propos d’un patient 12
PIN Patient insurance information Information sur les assurances sociales du 11
patient
PPG Patient pathway message (goal-oriented) Message sur le plan de soin du patient 12
(orienté objectif)
PPP Patient pathway message (problem-oriented) Message sur le plan de soin du patient 12
(orienté problème)
PPR Patient problem message Message sur le problème du patient 12
PPT Patient pathway goal-oriented response Réponse sur le plan de soin du patient 12
(orienté objectif)
PPV Patient goal response Réponse sur l’objectif pour le patient 12
PRR Patient problem response Réponse sur le problème du patient 12
PTR Patient pathway problem-oriented response Réponse sur le plan de soin du patient 12
(orienté problème)
QCK Deferred query Demande différée 2
QRY Query, original mode Demande, mode original 3
R0R Pharmacy/treatment order response Réponse aux prescriptions médicamenteuses 4
RAR Pharmacy/treatment administration Information sur les administrations 4
information médicamenteuses
RAS Pharmacy/treatment administration message Message sur les administrations 4
médicamenteuses
RCI Return clinical information Retour d’information clinique 11
RCL Return clinical list Retour d’une liste de données cliniques 11
RDE Pharmacy/treatment encoded order message Message de commande pharmaceutique codé 4
RDO Pharmacy/treatment order message Message de commande pharmaceutique 4
RDR Pharmacy/treatment dispense information Information de distribution pharmaceutique 4
RDS Pharmacy/treatment dispense message Message de distribution pharmaceutique 4
REF Patient referral Informations se référant au patient 11
RER Pharmacy/treatment encoded order Information sur les commandes 4
information pharmaceutiques codées
RGR Pharmacy/treatment dose information Information sur les doses prescritesdes 4
traitements
RGV Pharmacy/treatment give message Message de traitement administré 4
RPA Return patient authorization Renvoi du consentement du patient 11
RPI Return patient information Renvoi d’information sur les assurances du 11
patient
RPL Return patient display list Retour de liste de patient 11
RPR Return patient list Retour de liste de patient 11
___________________________________________________________________
26/09/01 34/35 Vi21HL7-1ini 1.doc
____________________________________________________________________
RQA Request patient authorization Demande de consentement du patient 11
RQC Request clinical information Demande d’informations cliniques 11
RQI Request patient information Demande d’information sur un patient 11
RQP Request patient demographics Demande d’informations administratives sur 11
un patient
RQQ Event replay query Demande de répétition d’un évènement 2
RRA Pharmacy/treatment administration Message d’accusé de réception d’un message 4
acknowledgement message d’administration d’un traitement
RRD Pharmacy/treatment dispense Message d’accusé de réception d’un message 4
acknowledgment message d’administration d’un traitement
RRE Pharmacy/treatment encoded order Message d’accusé de réception d’un message 4
acknowledgment message de commande pharmaceutique codé
RRG Pharmacy/treatment give acknowledgment Message d’accusé de réception d’un message 4
message de traitement administré
RRI Return referral information Renvoi d’informations 11
RRO ORR message for pharmacy/treatment Message ORR pour les produits 4
pharmaceutiques
SIU Schedule information unsolicited Information non sollicitée de rendez-vous 10
SPQ Stored procedure request Demande de procédure d’archivage 2
SQM Schedule query message Message de demande de rendez-vous 10
SQR Schedule query response Réponse au message de demande de rendez- 10
vous
SRM Schedule request message Message de demande de rendez-vous 10
SRR Scheduled request response Réponse au message de demande de rendez- 10
vous
SUR Summary product experience report Résumé des informations cliniques sur un 7
produit
TBR Tabular data response Réponse sous forme d’un tableau de données 2
UDM Unsolicited display update message Message non-sollicité de mise à jour des 2
affichages
VQQ Virtual table query Demande de table virtuelle 2
VXQ Query for vaccination record Demande pour une donnée de vaccination 4
VXR Vaccination record response Réponse pour une demande de donnée de 4
caccination
VXU Unsolicited vaccination record update Mise à jour des données de vaccination non 4
sillicité
VXX Response for vaccination query with multiple Réponse à une demande d’information de 4
PID matches données de vaccination avec plusieurs PID
répondant aux critères
En analysant rapidement cette table, on constate qu’il existe de nombreux

messages semblant faire la même chose. En fait, ces messages proches
correspondent à des situations différentes et le contexte d’utilisation est précisé
dans le texte du standard.
___________________________________________________________________
26/09/01 35/35 Vi21HL7-1ini 1.doc

HL7 1ini1 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

HL7 1ini1 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Les standards pour les systèmes

2.1 – HL7 : Health Level 7

GMSIH – 374, rue de Vaugirard – 75015 Paris. Tel : 01 48 56 72 70. Fax : 01 48 56 07 70

Auteur du document : Responsable Qualité

Date Version Commentaires Statut

31/01/2001 0.1 Création du document Non validé

2.1. Pourquoi des standards de communication

Progressivement depuis la fin des années 70, les systèmes informatisés

Le niveau le plus basique d’échange d’informations correspond à

Un autre moyen, non spécifique celui-là, est d’utiliser des courriers

Ce besoin de transmettre les données sous une forme structurée

Fonctions du système applicatif

Figure 1 : Le modèle OSI à sept couches.

En pratique, lorsque seuls deux ou trois systèmes cohabitent dans une

Cas simple à deux systèmes, éventuellement gérable en interface

Cas plus complexe à 6 systèmes, dans ce cas la communication par

Figure 2 : Illustration de la complexité croissante de la

2.3. Pourquoi HL7

Il existe de nombreux organismes développant des standards pour

Les principaux buts et apports de HL7 sont :

Cas plus complexe à 6 systèmes : dans ce cas l’utilisation d’un

Figure 3 : Le deuxième cas de la figure 2 se simplifie avec

2.4. Que signifie « utiliser HL7 »

Avec l’utilisation d’HL7, il n’est plus nécessaire de commencer au tout

Numéro de version Date de publication Remarque

Technical Steering Committee

The Working Group

Technical Committees Special Interest Groups

Figure 4 : Organigramme d’HL7

HL7 ne demande aucun pré-requis en terme d’architecture système :

5.2. HL7 est-il Plug and Play ?

La variabilité des procédures dans le domaine de la santé complique le

Pourtant HL7 est une étape importante vers l’interopérabilité dans la

5.3. Principes de base d’HL7 :

Normalement un événement du monde réel initie l’échange de données

D’une manière générale, on distingue deux catégories de messages :

Figure 5 : Principe de base d’HL7

Figure 6 : Admission d’un patient

Figure 7 : Accusé de réception (ACK)

Figure 8 : Transfert d’un patient

Pendant une transaction dans un système, une requête (query) est

Sous-système Message de requête

HL7 ne définit pas uniquement des messages pour les données

5.5. Structure d’HL7

Dans HL7, le contenu des messages peut être défini :

Un message HL7 respecte la structure hiérarchique : message, segment,

5.5.1. Les messages

Un message est le plus petit élément communicable. Il est composé

Figure 10 : Structure de base d’un message HL7

5.5.2. Les segments

Les segments sont constitués d’une séquence ordonnée de champs.

Message ADT MSH EVN PID PV1 …

Figure 11 : Représentation schématique d’un message ADT

Il faut savoir que tous les messages commençant par un Z sont

Le standard HL7 ne définit aucun segment Z. Habituellement ils sont

Le contenu sémantique des messages est contenu par les champs

Figure 12 : Structure des segments

ST Chaîne de caractère XPN Nom de personne

Le contenu des champs peut être obligatoire ou optionnel. Des

Type Table Nom Valeur Description Traduction en français

Des champs multi-valués sont utilisés pour subdiviser le contenu

CN Numéro d’identification + nom

5.5.4. Syntaxe des messages résumés (Abstract Message Syntax)