Encodages des messages

Il ne suffit pas de définir la sémantique du message pour que HL7 soit utile. Une fois le contenu du message déterminé, la norme doit expliquer comment représenter ce contenu dans une interface réelle. Autrement dit, il doit y avoir un « encodage de message » spécifié. HL7 Version 2 prend en charge deux formes d’encodage de message, un encodage basé sur un délimiteur personnalisé et un encodage XML.

HL7 a choisi l’encodage basé sur le délimiteur d’origine pour réduire autant que possible la taille des messages. Par exemple, si vous comparez une structure de données dans laquelle les délimiteurs séparent des éléments à une structure qui positionne chaque élément dans un ensemble fixe de positions, la structure basée sur le délimiteur est beaucoup plus économique si a) les messages ne contiennent pas certains éléments et b) certains éléments ne remplissent pas tout l’espace autorisé. La seule surcharge dans les structures basées sur un délimiteur est les délimiteurs eux-mêmes.

L’encodage HL7 d’origine définit cinq délimiteurs, que chaque message déclare dans le segment MSH. Celles-ci indiquent :

• Segments

• Champs

• Components

• Sous-composants

• Répétition (d’un champ, d’un composant ou d’un sous-composant)

  Notez que, étant donné que les délimiteurs sont un aspect fondamental de l’encodage, vous devez d’abord les définir. L’un des résultats est qu’il ne peut pas y avoir de sous-sous-délimiteur. Parfois, cette limitation a des effets malheureux sur la conception de nouveaux types de données.

  En juin 2003, HL7 a publié HL7 version 2, Syntaxe d’encodage XML, version 1. Cette norme définit d’autres règles d’encodage pour les messages HL7 version 2.3.1 et 2.4, et fournit un mécanisme pour déterminer les règles d’encodage alternatives pour les versions HL7 2.X suivantes. En substance, cette nouvelle norme définit les balises d’éléments XML pour les messages abstraits, segments, champs et types de données version 2.3.1 et V2.4, et crée des règles pour définir les balises nécessaires pour toutes les nouvelles structures créées pour les versions ultérieures de la norme version 2. Le processus de définition de cette norme a conduit à une série d’améliorations dans les versions 2.4 et 2.5. Cela s’est produit parce que la création de balises XML a entraîné la nécessité de résoudre certaines ambiguïtés de longue date dans la norme sous-jacente. Par conséquent, a) des codes de structure de message bien définis ont été créés pour indiquer des variations dans les messages abstraits associés aux événements déclencheurs, b) les groupes répétés de segments avec un message abstrait ont été officiellement identifiés et nommés, et c) le type de données défini localement, CM a été remplacé par des types plus spécifiques.

  Par exemple, ce qui suit est un simple message d’accusé de réception utilisant le format traditionnel délimité par le canal :

MSH|^~\&|LAB|767543|ADT|767543|199003141304-0500||ACK^^ACK|XX3657|P|2.4  
MSA|AR|ZZ9380  
ERR|PID^1^16^103&Table value not found&HL70357  

En revanche, le message suivant est le même qu’un document XML :

<ACK  
xmlns="urn:hl7-org:v2xml"  
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
xsi:schemaLocation="urn:hl7-org:v2xml ACK.xsd">  
   <MSH>  
      <MSH.1>|</MSH.1>  
      <MSH.2>^~\&</MSH.2>  
      <MSH.3>  
         <HD.1>LAB</HD.1>  
      </MSH.3>  
      <MSH.4>  
         <HD.1>767543</HD.1>  
      </MSH.4>  
      <MSH.5>  
         <HD.1>ADT</HD.1>  
      </MSH.5>  
      <MSH.6>  
         <HD.1>767543</HD.1>  
      </MSH.6>  
      <MSH.7>  
         <TS.1>199003141304-0500</TS.1>  
      </MSH.7>  
      <MSH.9>  
         <MSG.1>ACK</MSG.1>  
         <MSG.3>ACK</MSG.3>  
      </MSH.9>  
      <MSH.10>XX3657</MSH.10>  
      <MSH.11>  
         <PT.1>P</PT.1>  
      </MSH.11>  
      <MSH.12>  
         <VID.1>2.4</VID.1>  
      </MSH.12>  
   </MSH>  
   <MSA>  
      <MSA.1>AR</MSA.1>  
      <MSA.2>ZZ9380</MSA.2>  
   </MSA>  
   <ERR>  
      <ERR.1>  
         <ELD.1>PID</ELD.1>  
         <ELD.2>1</ELD.2>  
         <ELD.3>16</ELD.3>  
         <ELD.4>  
            <CE.1>103</CE.1>  
            <CE.2>Table value not found</CE.2>  
            <CE.3>HL70357</CE.3>  
         </ELD.4>  
      </ERR.1>  
   </ERR>  
</ACK>  

Les fonctions suivantes de Microsoft BizTalk Accelerator pour HL7 (BTAHL7) prennent en charge ces exigences :

• Prise en charge de l’encodage XML et délimité par le canal.

• Prise en charge de la traduction entre les encodages XML et délimités par le canal.

Voir aussi

Traitement des messages HL7
Traitement des messages
Utilisation des schémas HL7 2.X