Les standards pour les systèmes d’Information de Santé ...api/deki/files/374/=HL7-1ini1.pdf · 2.1 – HL7 : Health Level 7 Présention générale et HL7 version 2.x Version 1.0

Les standards pour les systèmesd’Information de Santé :

(Série documents d’initiation)

2.1 – HL7 : Health Level 7Pré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____________________________________________________________________

___________________________________________________________________26/09/01 2/35 Vi21HL7-1ini 1.doc

Auteur du document : Responsable Qualité

Joël ChabriaisDate :24 septembre 2001Statut : Validé

Date Version Commentaires Statut

31/01/200112/03/2001

25/04/200102/07/2001

24/09/2001

0.10.2

0.30.4

1.0

Création du documentDivision du document en 2parties :- 2.1 concernant laprésentation générale et lesversions 2.x- 2.2 décrivant la version 3avec le RIM, la CDA etCCOWExtension du documentModification du documentaprès première relectureValidation du document

Non validéNon validé

Non validéNon validé

Validé


___________________________________________________________________26/09/01 3/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....................................................................................................................... 185.5.1. Les messages ................................................................................................................................... 185.5.2. Les segments.................................................................................................................................... 195.5.3. Les champs ...................................................................................................................................... 205.5.4. Syntaxe des messages résumés (Abstract Message Syntax).......................................................... 215.5.5. Les règles d’encodage ..................................................................................................................... 225.5.6. Les tables de description des segments .......................................................................................... 225.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 4/35 Vi21HL7-1ini 1.doc

Page Blanche


___________________________________________________________________26/09/01 5/35 Vi21HL7-1ini 1.doc

1. Avertissement

La série de documents concernant les standards pour les systèmesd’information de santé comporte deux catégories de documents :

- les documents dits d’information dont le but est de permettre au lecteurd’appréhender le domaine d’application du standard et son intérêt sansentrer dans les détails techniques,

- les documents dits d’initiation qui entrent un peu plus dans les aspectstechniques permettant ainsi de mieux comprendre le standard, sans pourautant avoir la prétention de permettre d’atteindre le niveau d’expert dustandard.

HL7 est connu avant tout comme un standard de message pour les systèmesd’information de santé. Depuis le lancement des travaux sur la version 3, cecin’est plus tout à fait vrai. En effet, en plus des messages de la version 3 quis’inscrivent maintenant dans le cadre d’un modèle d’information (RIM =Reference Information Model), HL7 propose une architecture de documentscliniques (CDA = Clinical Document Architecture) et un système desynchronisation du contexte patient entre applications tournant sur un mêmeposte de travail (CCOW = Clinical Context Object Working Group). Pour cesraisons 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 dela 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 6/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ésont été de plus en plus utilisés pour réduire les coûts et améliorer laqualité des soins. Cependant malgré quelques tentatives, aucun systèmecapable 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, denombreux systèmes autonomes répondant aux besoins spécifiques desdifférents services ont été développés. Ceci a aboutit à une mosaïque desystèmes d’informations provenant de fournisseurs différents. Pendant cetemps, les contraintes de gestion nécessitaient une centralisation decertaines informations. Il est donc apparu nécessaire de fairecommuniquer 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 lesapplications en utilisant ce que l’on appelle des API (ApplicationProgrammer Interface ou interface de programmation). L’inconvénient deces 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 à unetransmission des informations sans aucune structure formelle ce quioblige à prévoir une opération manuelle pour réintégrer les informationsaux bons endroits.

Ce besoin de transmettre les données sous une forme structuréepermettant les traitements automatiques a abouti au développement destandards de messages. Dans le monde de la santé, deux standards sesont fait concurrence : les messages EDIFACT et les messages HL7. Plusrécemment on a vu l’émergence de XML, issu directement du monde del’Internet. En théorie, lorsqu’une application est conforme à un de cesstandards de messages, elle est capable d’échanger des données avecn’importe quelle autre application qui se dit conforme à ce mêmestandard. Ces standards de message se situent au niveau 7« application » du modèle OSI de l’ISO (Figure 1). C’est pour cette raisonque le standard américain de messages dédiés à la santé s’est appeléHealth Level Seven ou HL7.


___________________________________________________________________26/09/01 7/35 Vi21HL7-1ini 1.doc

En pratique, lorsque seuls deux ou trois systèmes cohabitent dans unestructure des interfaces spécifiques sont encore viables, tandis que lasituation devient vite intenable lorsque le nombre de systèmes croît. Lenombre 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 standardd’échange structuré des données.

Application

Présentation

Session

Transport

Réseau

Data Link

Physique

Fonctions du système applicatif

Fonctions réseau

Figure 1 : Le modèle OSI à sept couches.HL7 se situe au niveau supérieur, « Application », du modèle.

Niveau 1

Niveau 2

Niveau 3

Niveau 4

Niveau 5

Niveau 6

Niveau 7


___________________________________________________________________26/09/01 8/35 Vi21HL7-1ini 1.doc

Cas simple à deux systèmes, éventuellement gérable en interfacespécifique, mais toute modification impose de réviser les interfaces.

Système deradiologieDonnées

Systèmed’acquisitiond’images

Données

Cas plus complexe à 6 systèmes, dans ce cas la communication parinterfaces spécifiques nécessiterait n.(n-1) soit 6 X 5 = 30 interfaces

spécifiques différentes pour assurer la totalité des échangesenvisageables. (Toutes les possibilités ne sont pas montrées).



Données

Système delaboratoireDonnées

Système desoinsinfirmiers

Données

SystèmeadministratifDonnées

Systèmed’informationclinique

Données

Figure 2 : Illustration de la complexité croissante de laproblématique de l’interconnexion avec la croissance du nombre desystèmes.Dans un hôpital, on peut avoir jusqu’à 30 ou 40 systèmes différents. Siles interfaces ont été développées, il faut les maintenir et en cas dechangement d’un système, il faut les développer de nouveau avec uncoût élevé.La comparaison de ces deux exemples permet de comprendre pourquoila solution des interfaces spécifiques n’est pas viable, d’où le besoin destandards de messages permettant de garantir l’interopérabilité dessystèmes sans développement spécifique supplémentaire.


___________________________________________________________________26/09/01 9/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éepar une étiquette codée (tag),

- quel caractère doit séparer les items pour qu’ils puissent êtreidentifiés,

- quel est le format de chaque item, e.g., comment une date doit êtrereprésentée (syntaxe),

- quelle est la signification de chaque item, e.g., le premier item est leprénom (sémantique).

2.3. Pourquoi HL7

Il existe de nombreux organismes développant des standards pourl’informatique de santé à travers le monde. Pourquoi un groupesupplémentaire ? HL7 a ceci de particulier qu’il se consacre uniquement àsatisfaire les besoins concernant les interfaces entre systèmes dans lecadre de l’organisation globale de santé. Le seul autre organisme pouvantrevendiquer ce champ d’action était le CEN/TC 251 jusqu’à la création en1998 de l’ISO/TC 215. En fait, HL7 a œuvré avec force pour la création decette dernière structure, seule l’ISO pouvant donner une reconnaissancemondiale à un standard. Plus récemment un accord a été signé entre leCEN/TC251 et HL7 dans le but de faire converger et fusionner leurstravaux respectifs. Finalement il s’avère que cette union va probablementpermettre de définir un seul standard de messages ayant la vocation desatisfaire 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 10/35 Vi21HL7-1ini 1.doc

2.4. Que signifie « utiliser HL7 »

Avec l’utilisation d’HL7, il n’est plus nécessaire de commencer au toutdébut des développements. Au lieu de cela, la conception des interfacespeut ce faire à un niveau nettement plus haut. HL7 représente une aidenon 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 decommunication. Des négociations extensives doivent avoir lieu entre lesindividus et/ou les organisations concernés dans la phase qui précède levéritable développement des interfaces. En effet, du fait de sa souplesse,la version actuelle d’HL7 autorise des variations dans l’implémentation desmessages aboutissant à des difficultés de communication si lespartenaires ne s’entendent pas sur la variation qu’ils retiennent.

Cas plus complexe à 6 systèmes : dans ce cas l’utilisation d’unstandard de messages simplifie considérablement la situation.


Système delaboratoireDonnées

Système desoinsinfirmiers

Données


Données

SystèmeadministratifDonnées

Systèmed’informationclinique

Données

HL7

HL7

HL7

HL7

HL7

HL7

Figure 3 : Le deuxième cas de la figure 2 se simplifie avecl’utilisation d’HL7Avec l’utilisation d’un protocole de communication comme HL7, unestructure de communication uniforme est réalisée, facilitant l’insertiond’un nouveau système ou le remplacement d’un système par un autre.


___________________________________________________________________26/09/01 11/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 entresystè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 destandards 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 laversion 2.3.2. La version 2.4 est la version officielle la plus récente, mais troprécente pour exister dans des produits. Devant les insuffisances des versions2.x, le développement de la version 3.0 a été lancé en 1997 mais sa finalisationn’est pas attendue avant 2002-2003.

Numéro de version Date de publication RemarqueVersion 1.0 1987 Standard prototype

2.0 1988

2.1 1990

2.2 1994

2.3.1 1997

2.4 12/2000

Version 2.x*

2.5 Annoncée pour 02/2002

Adéquat,conditionnement

arbitraire desdonnées.

Pas de modèle.

Version 3.01997 (Lancement du

développement)Méthodes formelles,basé sur un modèle

* Les différences entre les sous-versions relèvent de la maintenance du standard et de sonadaptation permanente aux besoins. Cela se traduit par l’ajout de messages ou champsmanquant ou le retrait de messages ou champs obsolètes ou non utilisés.


___________________________________________________________________26/09/01 12/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édentPrésident, Secrétaire et Trésorier)1, trois membres de droit (Présidenttechnique, Vice-Président technique et le représentant – élu – des AffiliésInternationaux) et quatre directeurs élus. En dessous siège un Comité deDirection Technique (Technical Steering Commmittee) qui comprend lePrésident d’HL7 et les co-présidents des différents comités techniques etgroupes d’intérêt particuliers. HL7 est ensuite organisé en Groupes de Travail(Working Group), qui comprennent des Comités Techniques (TC) et desGroupes d’Intérêt Particulier (SIG) ayant la responsabilité de définir lesprotocoles standards d’HL7. Chaque TC ou SIG est présidé par au moins deuxco-présidents. Les co-présidents constituent collectivement le Comité deDirection Technique qui vote sur les questions concernant le standard. Lesvotes du Comité de Direction Technique sont transmis commerecommandations au Conseil des Directeurs qui prend la décision finale. Lesmembres d’HL7 sont encouragés à participer activement à tous ces comités.

HL7 comporte plus de 500 organisations membres avec un total d’environ 1500membres 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 êtreclairement définies dans les statuts de l’association. Cette structure est censée garantir unecertaine continuité dans le gouvernement de l’Association.

Technical Steering CommitteeAffaires techniques

Responsables désignés plus présidentsDes comités & SIGs

Special Interest GroupsCollabore dans un domaine d’intérêt pour

contribuer aux travaux des TCs

The Working GroupLe "vrai" HL7

N’importe quel membre peut s’inscrireÀ n’importe quel comité ou SIG

Board of DirectorsDirection des affaires

Élus

Figure 4 : Organigramme d’HL7HL7 repose sur des collaborateurs volontaires des organisationsmembres. Le nombre de salariés est limité aux besoins du secrétariat.Les principaux moyens financiers proviennent des cotisations desmembres.

Technical CommitteesCréent les spécifications normatives

Ou chapitres du standard


___________________________________________________________________26/09/01 13/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 14/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 desproduits commercialisés au moment de la rédaction de ce document. Bien quela 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 despatients,

- L’échange de données entre systèmes peut être implanté enutilisant différents systèmes d’exploitation ou langage deprogrammation,

- 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, …), aussibien que par les liaisons séries (RS 232 ou autre) ou les entrées en batchen utilisant des disquette ou tout autre support physique. Les transactionsisolé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 ledéveloppement d’un modèle de données universel. À l’origine, HL7 n’apas fait d’hypothèse a priori sur l’architecture des systèmes : à l’heureactuelle, 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 lacommunication. Même si HL7 n’est pas encore « plug and play », iléconomise beaucoup de temps et d’argent aussi bien pour les utilisateursque pour les éditeurs de logiciels. Dans les futures versions, HL7 poursuitl’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éesentre deux systèmes. Par exemple, un patient est admis à l’hôpital. Sesrenseignements administratifs (nom, date de naissance, information surles proches, assurances sociales, etc.) sont enregistrés dans le serveurd’identité. Un événement « admission de patient » amène à un échangede données, e.g., entre le serveur d’identité et un système d’information


___________________________________________________________________26/09/01 15/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 dupatient sont disponibles.

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 à unetransaction interne dans le système expéditeur comme une insertion dansune base de donnée. Ensuite les données sont expédiées en utilisantHL7. Le receveur reçoit un message et peut réagir par une transaction.

Figure 5 : Principe de base d’HL7Un événement déclenchant du monde réel (élément déclenchant outrigger) déclenche l’échange de données entre deux systèmes ou plus.

Envoie unmessage HL7

Reçoit unaccusé de

réception HL7

Système A

Reçoit unmessage HL7

Envoie unaccusé de

réception HL7

Système B

Événement déclenchantou Trigger

Réseau


___________________________________________________________________26/09/01 16/35 Vi21HL7-1ini 1.doc

Admissiond’un patient

Sous -systèmede banque dusang

Données

Sous-systèmed’ORLDonnées

Sous -systèmede chirurgieDonnées

Figure 7 : Accusé de réception (ACK)Après réception d’un message d’admission (ADT) émis par lesous-système des admissions, les autres sous-systèmes peuventconfirmer à l’expéditeur que le message a bien été reçu

Sous-systèmedes admissions

Données

ADT

ADT

ADT

ACK

ACK

ACK

Admissiond’un patient

Systèmede serviceclinique

Données

Système deservice desoins intensifs

Données

Systèmedesadmissions

Données

Systèmedelaboratoire

Données

Figure 6 : Admission d’un patientDans HL7 l’événement « admission d’un patient » déclenche un échange de donnéesau moyen d’un message A01. Le système expéditeur (ici le système de serviceclinique) doit adresser le message A01 aux autres sous-systèmes. Typiquement desmoteurs d’interface sont utilisés pour la distribution des données. Le systèmeexpé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.

A01A01

A01


___________________________________________________________________26/09/01 17/35 Vi21HL7-1ini 1.doc

Pendant une transaction dans un système, une requête (query) estgénérée si des données sont manquantes. Le receveur de la requête peutrépondre ; à part cela, aucune autre transaction n’est faite. La réponsepermet de compléter la transaction sur le système demandeur.

Systèmede serviceclinique

Données

Système deservice desoins intensifs

Données

Systèmedesadmissions

Données

Systèmedelaboratoire

Données

Figure 8 : Transfert d’un patientEn utilisant des messages A02, l’événement « transfert de patient » peut êtrecommuniqué aux différents sous-systèmes

A02A02

A02

Transfert dupatient vers lessoins intensifs

Sous-systèmedes admissions

Données

Message de requête

Réponse à la requête

« Patient inconnu »

Sous-systèmede laboratoire

Données

Figure 9 : RequêteSi un patient est inconnu, e.g., dans le sous-système de laboratoire, unequestion utilisant une requête HL7 peut être générée et adressée au systèmeadministratif (ADT dans HL7). La réponse contient les informations patientmanquantes.


___________________________________________________________________26/09/01 18/35 Vi21HL7-1ini 1.doc

5.4. Messages à finalités multiples :

HL7 ne définit pas uniquement des messages pour les donnéesadministratives. Par exemple, HL7 propose des messages pour :

- ADT (Admission, Discharge and Transfer : admission, facturation ettransfert) 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 dustandard 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.

Figure 10 : Structure de base d’un message HL7Par exemple le message qui va transmettre les données concernant l’admission d’unpatient est identifié par le type de message « ADT » avec pour trigger A01 : ADTÂ01

MessageSegment

Champ Champ Champ

SegmentChamp Champ Champ


___________________________________________________________________26/09/01 19/35 Vi21HL7-1ini 1.doc

Le message est identifié par son type (par exemple ADT) et parl’événement déclenchant ou « trigger event » (par exempleadmission du patient). Il commence toujours par le segment en-têtede message ou MSH (Message Header Segment) suivi par unsegment 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 ourépétables.

Les segments sont clairement identifiés par trois lettres situées à leurdébut et constituant ce qu’HL7 appelle le « segment identifier ». Lesdifférents segments sont séparés par les séparateurs de segment.Ainsi en reprenant le type de représentation de la figure 10, lemessage ADT, est constitué des segments suivants : MSH, EVN,PID, PV1, … comme représenté figure 11.

Il faut savoir que tous les messages commençant par un Z sontréservé pour des messages spécifiques à usage local.

Le standard HL7 ne définit aucun segment Z. Habituellement ils sontdéterminés et coordonnés par des groupes d’utilisateurs nationaux.

Figure 11 : Représentation schématique d’un message ADTLe message comporte les segments suivants : MSH (Message Segment Header),EVN qui contient la description de l’évènement déclenchant, PID l’identification dupatient, PV1 les informations sur la visite actuelle du patient …

Message ADT MSH EVN PID PV1 …


___________________________________________________________________26/09/01 20/35 Vi21HL7-1ini 1.doc

5.5.3. Les champs

Le contenu sémantique des messages est contenu par les champsdes segments.

Les champs peuvent être de longueur variable et ils sont séparés pardes séparateurs de champ. Un type de donnée est défini pourchaque champ, e. g. chaîne de caractère, valeur numérique… Letableau suivant montre un certain nombre de types de donnéespermis extraits de la cinquantaine qu’HL7 décrit dans sa partie 2.8 :

ST Chaîne de caractère XPN Nom de personneTX Texte XAD AdresseFT Texte formaté XTN Numéro de téléphoneNM 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 nomPL Lieu où se trouve la personne CQ Quantité et unité

(*) Les champs composites sont définis comme la combinaison de plusieurs champs dedonnées. Chaque partie d’un champ composite est appelé un « composant ».

Le contenu des champs peut être obligatoire ou optionnel. Deschamps particuliers peuvent être répétés. Les définitions des champssont 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 « Table0001, définie par l’utilisateur – Sexe » avec ajout de la traductionfrançaise.

Figure 12 : Structure des segmentsUn segment d’un message contient plusieurs champs. Ce sont ces champs quisont porteurs de toute la sémantique du message.

Segment

Champ Champ Champ Champ Champ Champ Champ Champ


___________________________________________________________________26/09/01 21/35 Vi21HL7-1ini 1.doc

Type Table Nom Valeur Description Traduction en françaisUser 0001 Sex Sexe

0001 F Female Femme0001 M Male Homme0001 O Other Autre0001 U Unknown Inconnu

Des champs multi-valués sont utilisés pour subdiviser le contenud’un champ et faciliter la transmission de contenus sémantiquesreliés logiquement en utilisant un type de donnée CE (CodedElement ou élément codé) :

CN Numéro d’identification + nomCE Élément codé :

Valeur du code + désignation du code + système de codageCQ Quantité + unitéMO Prix + type de monnaie

Exemple :

CN 00967^Henri^Dupont^^Dr. Med.CE 620.2^Kyste de l’ovaireÎ9CQ 17,2^g/dlMO 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 cettesyntaxe. Dans HL7, le niveau de définition le plus basique est celuiqui associe un message résumé avec un événement déclencheurparticulier. La définition du message résumé inclut les champs dedonnées qui seront envoyés avec le message, les messages deréponse valides et le traitement des erreurs du niveau application oul’échec des couches plus basses du système de communication. Unmessage résumé HL7 est une suite de caractères de contrôle et desegments de données dont la fréquence d’occurrence (cardinalité) etcertaines 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 leursidentificateurs, les segments optionnels sont entre crochets [ ] et lessegments répétables entre accolades { }. Des champs peuvent êtresimultanément optionnels et répétables, ce qui s’exprime sous deuxformes équivalentes : {[ ]} ou [{ }].

Chaque message commence par les informations concernant lemessage lui-même (en-tête de message MSH, descriptiond’événement EVN, etc). Les segments suivant concernent en


___________________________________________________________________26/09/01 22/35 Vi21HL7-1ini 1.doc

général le patient lui-même (identifiant patient PID, Informationsconcernant la visite du patient PV1 et PV2, mention des allergieséventuelles AL1 …). Les informations complémentaires sont ensuitetransmises (demande, résultat, données d’examen, facturation …).Ainsi le message ADT02 dont il était question dans l’exemple de lafigure 8 et son accusé de réception sont spécifiés de la manièresuivante dans HL7 :

ADT ADT Message Chapter

MSH Message Header 2EVN Event Type 3PID Patient Identification 3[PD1] Additional Demographics 3PV1 Patient Visit 3[ PV2 ] Patient Visit - Additional Info. 3[ { DB1 } ] Disability Information 3[ { OBX } ] Observation/Result 7

ACK General Acknowledgment Chapter

MSH Message Header 2MSA Message Acknowledgment 2[ ERR ] Error 2

La colonne « Chapter » fait référence au chapitre d’HL7 où lesegment est décrit.

5.5.5. Les règles d’encodage

HL7 défini des règles de construction de messages appelées « HL7encoding rules ». HL7 décrit deux groupes de règles : un groupe quipeut être considéré comme les règles de bases et un groupe appelé« extended encodage rules » permettant de gérer les segmentsvalides pour plusieurs messages. Par ailleurs lorsque la situationlocale l’exige, HL7 accepte l’utilisation de règles d’encodagesspécifiques au site. HL7 ne fixant pas de longueurs fixes auxchamps, les règles d’encodage définissent en particulier descaractè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 setrouvent dans la table des segments. Nous donnerons en exemple latable du segment PID qui contient l’identification du patient.

Identifiant du message

Identifiant du segment

Optionnel

Optionnel et répétable


___________________________________________________________________26/09/01 23/35 Vi21HL7-1ini 1.doc

Le tableau ci-dessous donne la signification des en-têtes descolonnes des tables de segments :

SEQ Position (numéro séquentiel dans le segment)LEN Longueur maximaleDT Type des donnéesR/O Obligatoire ou optionnelRP/# 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 deconduire 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 naissancesmultiples

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 dupatient

30 1 ID O 0136 00741 Patient Death Indicator Indicateur de décès dupatient.


___________________________________________________________________26/09/01 24/35 Vi21HL7-1ini 1.doc

Il est à noter que l’utilisation des valeurs de certains champs de cettetable 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, parexemple le numéro de permis de conduire : aux États-Unis, le permisde conduire fait également office de carte d’identité.

L’utilisation éventuelle d’HL7 en France ne pose cependant pas deproblème car ces champs dont l’usage est interdit ou qui n’ont pasde sens chez nous sont des champs optionnels. Il suffirait despécifier des règles d’implantation d’HL7 dans des logiciels destinésà une utilisation en France en y précisant les champs à ne pasutiliser.

5.5.7. Exemple de création d’un message HL7 :

Nous allons prendre l’exemple du patient décrit ci-dessous pour voircomment se construit un message HL7. Nous prendrons l’exemplede l’admission d’un patient dont les éléments d’identification sont :

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 doncle message ADT01. En suivant les règles de l’AMS, le message 01est construit avec les segments suivants :

Durand, JeanHomme

Né le : 24/08/1940

Marié

10, Impasse de la Fontaine76740 Fontaine le Dun

Tél. : 02 48 34 45 78

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 25/35 Vi21HL7-1ini 1.doc

Dans l’exemple nous allons nous concentrer sur le segment PID. Lesdifférents champs vont être remplis en suivant les instructionscontenues 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 (poursequence ID). Ce doit être un entier non négatif selon lesrègles décrites pour le type de données NM (numérique). Pourla première occurrence du segment sa valeur pourra être 1,pour le seconde occurrence elle pourra être 2, etc. Ce numérode transaction est attribué par le système expéditeur etpermettra de se référer ultérieurement à cette transaction encas de besoin. Pour notre exemple,disons que le numéro detransaction sera :

|856621|

« 2 » ID patient : le type de donnée est CX (ID composite étenduavec chiffre de contrôle ; ce chiffre de contrôle est donné parl’application en utilisant un algorithme modulo 11 décrit dansla section 2.8.5.3 du standard). Ce champ est composé de lamanière suivante :

<ID (ST)> ^ <chiffre de contrôle (ST)> ^ <codeidentifiant le schéma employé pour créer lechiffre de contrôle (ID)> ^ <instance allouantl’identifiant (HD)> ^ <code de typed’identifiant (IS)> ^ <guichet allouantl’identifiant (HD)

Les composants inutilisés à la fin du champ comme « instanceallouant l’identifiant » peuvent également être laissés enblanc. Dans notre exemple si l’ID du patient est 1234567-4 (4est le chiffre de contrôle en utilisant l’algorithme Modulo 11)sera codé ainsi :


___________________________________________________________________26/09/01 26/35 Vi21HL7-1ini 1.doc

|1234567^4^M11|

note : ce champ est conservé pour compatibilité descendantemais en principe il n’est plus utilisé dans les nouveauxdéveloppement. Lorsqu’il est utilisé, il correspond à unidentifiant attribué par une autre institution.

« 3 » Patient identifier list : ce champ contient une listed’identificateurs (un ou plus) du patient uniquement utilisés parles institutions pour identifier les patients (e. g., numéro dedossier médical, numéro de dossier administratif, registre denaissance, identificateur national unique, etc.). Son type dedonnées est également CX. Dans notre exemple :

|123^1^M11|

« 4 » Alternate Patient ID : ce champ est conservé pourcompatibilité descendante mais en principe il n’est plus utilisédans les nouveaux développement. HL7 recommande den’utiliser que le champ n°3 et sa possibilité de liste.

« 5 » Patient Name : le type de donnée est XPN ou « eXtendedPerson Name » (nom de personne étendue). Ce champ doitcontenir le nom figurant officiellement à l’état-civil. Tous lesautres noms que le patient peut être amené à utiliser nedoivent figurer que dans le champ PID 9 « Patient alias ». Larépétition est autorisée pour pouvoir enregistrer le nom avecdifférent jeux de caractères (caractères latins accentués ounon, caractères cyrilliques, etc.).

<nom de famille (ST)> & <préfixe de nom defamille (ST)> ^ <prénom (ST)> ^ <initiale ounom 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 sansretentissement sur le classement alphabétique. Avec cesystème que l’on se base sur Beethoven ou sur vanBeethoven le résultat de la recherche alphabétique sera lemême. On peut envisager, en France, de reprendre le principe


___________________________________________________________________26/09/01 27/35 Vi21HL7-1ini 1.doc

pour gérer les particules. L’initiale ou nom médian ainsi que lesuffixe ne sont pas d’usage chez nous.

note 2 : la notion de diplôme fait appel à une table définie parl’utilisateur mais HL7 suggère un certain nombre de valeursd’usage courant dans la table User-defined table 0360 –Degree.

note 3 : ce code permet d’identifier le type de nom dont ils’agit. HL7 attire l’attention sur le fait que le contenu du« Legal Name » (ou nom d’état-civil chez nous) est trèsvariable d’un pays à l’autre. Les types de noms sontré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 letype de données est XPN mais dont seul le premiercomposant est utilisé. HL7 utilise ce champ contenant le nomde jeune fille de la mère pour faciliter la résolution deshomonymies. 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 auformat international standardisé. Dans notre message nousaurons :

|19400824|

« 8 » Sex : c’est un champ de type IS se référant à la table 0001

Valeur Description Signification françaiseF Female FemmeM Male HommeO Other AutreU Unknown Inconnu

Dans notre exemple :

|M|

« Les champs 9 et 10 » sont laissés vides.


___________________________________________________________________26/09/01 28/35 Vi21HL7-1ini 1.doc

« 11 » Patient address : le type de données est XAD (ou eXtendedAddress). Les composants de ce champ sont :

<numéro et nom de rue (ST)> ^ <complémentd’adresse (ST)> ^ <ville (ST)> ^ <état ouprovince (ST)> ^ <code postal(ST)> ^ <pays(ID)> ^ <type d’adresse (ID)> ^ <autre élémentgéographique (ST)> ^ <comté/code de paroisse(IS)> ^ <région de recensement (IS)> ^ <codede 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’adresseprincipale 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éterautant de fois que nécessaire, le numéro principal doittoujours figurer en premier. Le format correspond aux usageslocaux. 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éfiniepar l’utilisateur (IS) dont un certain nombre de valeurs sontsuggé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 29/35 Vi21HL7-1ini 1.doc

Les champs restant seront rempli selon le même principe. Les autressegments devant se trouver dans le message ADT - A01 (MSH, EVNet PV1) seront remplis de la même manière, dans notre exemplenous reprendrons des valeurs données dans les exemples d’HL7pour fournir un aspect global réaliste du message ADT.

Une fois assemblé le message aura cet aspect, nous retrouvons encaractères gras les éléments de l’exemple expliqués plus haut :

5.6. Les messages HL7 version 2.3.1

Les différents messages sont regroupés par grands thèmes faisantchacun l’objet d’une partie du standard qui comporte douze parties et cinqannexes :

- Partie 1 : Introduction. Elle décrit le contexte de développementdu standard, les besoins que le standard est destiné à satisfaire,son champ d’application et pour finir cite un certain nombre dedocuments de référence.

- Partie 2 : Control/Query. Cette partie décrit les concept de baseset les règles génériques applicables aux messages. Ellecomporte, entre autre, la liste des types de messages et celle destypes d’évènements.

- Partie 3 : Patient Administration. Elle regroupe les messagespermettant de transmettre les informations d’identification despatients (nouvelles ou mises à jour) ainsi que celles concernantles séjours (au sens large).

- Partie 4 : Order Entry. Cette partie décrit tous les messagespermettant de commander quelque chose au sens large. Il existeainsi des messages concernant le linge, l’alimentation, lesdiverses fournitures aussi bien que des prescriptions detraitements à la pharmacie, des demandes d’examens, etc.

- Partie 5 : Query. En fait cette partie est maintenant incluse dansla partie 2 et elle n’est référencée que pour des raisons decompatibilité avec les versions antérieures du standard.

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 laFontaine^^Fontaine le Dun^^76740||0230184585|||M|CAT|ACCT1<CR>

PV1|1|I|ENT^12^01||||249^BOHBOH^^Û^^DR.MED.|||SUR||||ADM|A0|<CR>


___________________________________________________________________26/09/01 30/35 Vi21HL7-1ini 1.doc

- Partie 6 : Financial Management. Elle regroupe toutes lestransactions concernant la facturation. Les messages de cettepartie sont calqués sur la pratique, complexe, américaine de lafacturation. Elle a fait considérer qu’HL7 n’était pas applicablehors des Etats Unis. En fait il est facile de lui ajouter des pays etc’est un des rôles des affiliés HL7 nationaux que d’adapter lesmessages de cette partie aux différentes pratiques nationales.

- Partie 7 : Observation Reporting. Cette partie décrit lesmessages permettant de transmettre tous types de donnéescliniques. L’usage le plus courant qui en est fait est la transmissiondes observations et des résultats d’examens.

- Partie 8 : Master Files. Les messages regroupés dans cettepartie concernent la transmission de ce qui est appelé les fichiersmaîtres. Ce sont les fichiers de référence communs qui sontsouvent 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 desmatériels informatiques sur le réseau, les tables de définition desdifférents examens (radiologiques par exemple).

- Partie 9 : Medical Records/Information Management. Cettepartie concerne la gestion des documents médicaux et estdestinée à gérer tous types de données concernant le patient.

- Partie 10 : Scheduling. Cette partie décrit les messagesconcernant la programmation des rendez-vous.

- Partie 11 : Patient Referral. Dans cette partie HL7 propose desmessages permettant de communiquer des informations entrestructures 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 lestables définissant les données.

- Annexe B : Lower layer Protocols. Les informations de cetteannexe ont migré vers le guide d’implémentation d’HL7. Elle n’estconservée que pour des raisons de compatibilité.

- Annexe C : Network Management. Cette annexe décrit dessegments et champs permettant de faciliter la circulation desdonnées sur le réseau.

- Annexe D : Version 2.3.1 BNF Message Descriptions. Cetteannexe donne des exemples de représentations BNF dedéfinitions de messages.

- Annexe E : Glossary. Cette annexe est un glossaire de quelquestermes utilisés par HL7.


___________________________________________________________________26/09/01 31/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 debesoins 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, sonutilisation est de plus en plus répandue à travers le monde. Si bien que dans saversion actuelle, HL7 est très largement utilisé et se trouve implanté dans lamajorité 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 sujetsoit d’actualité. HL7 se contente de proposer un guide d’implantation en XMLde 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éeproposé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 austandard DICOM et dialoguent avec le reste du système d’informationsoit en DICOM soit en HL7. Il est donc clair que pour cette partie dusystème d’information hospitalier l’adoption d’HL7 ne se discute pas.

- Dans d’autres cas, nous avons des produits s’appuyant sur d’autrestypes de messages (HPRIM, PHAST, EDI, …), il est probable que lamigration vers HL7 2.x doive être envisagée avec pragmatisme :

o Dans les laboratoires, les messages les plus courammentutilisés sont les messages HPRIM,

o Pour la pharmacie et la prescription médicamenteuse, lesutilisateurs et les industriels se sont regroupés dansl’association PHAST/SIPH pour définir les messages standards,

o Dans d’autres secteurs, notamment administratif, les messagesNoemie B2 d’échange avec les caisses d’assurance maladie sesont imposés.

Dans ces conditions, l’évolution en France vers un standard regroupantl’ensemble des « spécialités » nécessite une volonté des acteurs de seregrouper. C’est le cas aujourd’hui avec la décision prise en juin 2001 de créerun groupe HL7 France au sein de la Commission de Normalisation Informationsde Santé (CNIS) à l’AFNOR. Ce groupe a plusieurs objectifs :

- croiser les messages HL7 et les différents standards de messagesutilisés en France de manière à voir comment dans un premier tempsils peuvent cohabiter,

- étudier de façon standard l’adaptation aux usages français desmessages HL7 pour éviter toute divergence d’implantation,

- coordonner les associations, industriels et particuliers français décidantd’adhérer au consortium HL7,

- étudier les modalité et l’intérêt de créer un « Affilié HL7 France ».


___________________________________________________________________26/09/01 32/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. Laversion courante officielle est la 2.4, cependant aux dires d’un certains nombrede développeurs l’ayant étudiée, cette version pose un certain nombre deproblèmes si bien que la tendance de l’industrie est de ne pas investir dessusce d’autant plus que la version 2.5 résolvant les problèmes identifiés dans la 2.4est déjà annoncée pour février 2002. Les quelques contacts que nous avons puavoir laissent à penser que la plupart des industriels internationaux utilisant HL7décideront de passer directement de la version 2.3.1 à la version 2.5.


___________________________________________________________________26/09/01 33/35 Vi21HL7-1ini 1.doc

7. Annexe

Nous reproduisons ci-après la table 0076 regroupant les différents types demessages. La colonne avec la signification en français est là pour faciliter lacompréhension de ce que font les messages, cependant son contenu ne peuten aucun cas être considérée comme une traduction officielle des libellés desmessages.

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 defacturation

6

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 delangue

2

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 applicationacknowledgment

Accusé de réception par l’application,retardé, des fichiers maîtres

8

MFK Master files application acknowledgment Accusé de réception par l’application desfichiers maîtres

8

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 enstock

4

OMS Stock requisition order message Message de demande de fourniture en stock 4

ORD Dietary order - General orderacknowledgment message

Accusé de réception à une prescriptiondiététique

4

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 orderacknowledgment message

Accusé de réception de demande defourniture non en stock

4

ORR General order response message response toany ORM

Message de réponse générique pour touteprescription médicamenteuse

4

ORS Stock requisition - General orderacknowledgment message

Accusé de réception de demande defourniture en stock

4


___________________________________________________________________26/09/01 34/35 Vi21HL7-1ini 1.doc


ORU Unsolicited transmission of an observationmessage

Transmission non sollicitée d’un messaged’examen

7

OSQ Order status query Demande de statut de la commande 4

OSR Query response for order status Réponse à la demande de statut de lacommande

4

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 dupatient

11

PPG Patient pathway message (goal-oriented) Message sur le plan de soin du patient(orienté objectif)

12

PPP Patient pathway message (problem-oriented) Message sur le plan de soin du patient(orienté problème)

12

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(orienté objectif)

12

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(orienté problème)

12

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 administrationinformation

Information sur les administrationsmédicamenteuses

4

RAS Pharmacy/treatment administration message Message sur les administrationsmédicamenteuses

4

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 orderinformation

Information sur les commandespharmaceutiques codées

4

RGR Pharmacy/treatment dose information Information sur les doses prescritesdestraitements

4

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 dupatient

11

RPL Return patient display list Retour de liste de patient 11

RPR Return patient list Retour de liste de patient 11


___________________________________________________________________26/09/01 35/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 surun patient

11

RQQ Event replay query Demande de répétition d’un évènement 2

RRA Pharmacy/treatment administrationacknowledgement message

Message d’accusé de réception d’un messaged’administration d’un traitement

4

RRD Pharmacy/treatment dispenseacknowledgment message

Message d’accusé de réception d’un messaged’administration d’un traitement

4

RRE Pharmacy/treatment encoded orderacknowledgment message

Message d’accusé de réception d’un messagede commande pharmaceutique codé

4

RRG Pharmacy/treatment give acknowledgmentmessage

Message d’accusé de réception d’un messagede traitement administré

4

RRI Return referral information Renvoi d’informations 11

RRO ORR message for pharmacy/treatment Message ORR pour les produitspharmaceutiques

4

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-vous

10

SRM Schedule request message Message de demande de rendez-vous 10

SRR Scheduled request response Réponse au message de demande de rendez-vous

10

SUR Summary product experience report Résumé des informations cliniques sur unproduit

7

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 desaffichages

2

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 decaccination

4

VXU Unsolicited vaccination record update Mise à jour des données de vaccination nonsillicité

4

VXX Response for vaccination query with multiplePID matches

Réponse à une demande d’information dedonnées de vaccination avec plusieurs PIDrépondant aux critères

4

En analysant rapidement cette table, on constate qu’il existe de nombreuxmessages semblant faire la même chose. En fait, ces messages prochescorrespondent à des situations différentes et le contexte d’utilisation est précisédans le texte du standard.

Documents

Les standards pour les systèmes d’Information de Santé ...api/deki/files/374/=HL7-1ini1.pdf · 2.1 – HL7 : Health Level 7 Présention générale et HL7 version 2.x Version 1.0