Codificaciones de mensaje

No es suficiente definir la semántica del mensaje para que HL7 sea útil. Una vez determinado el contenido del mensaje, el estándar debe explicar cómo representar ese contenido en una interfaz real. Es decir, debe haber una "codificación de mensajes" especificada. La versión 2 de HL7 admite dos formas de codificación de mensajes, una codificación basada en delimitadores personalizada y una codificación XML.

HL7 eligió la codificación basada en delimitador original para reducir el tamaño de los mensajes tanto como sea posible. Por ejemplo, si compara una estructura de datos en la que los delimitadores separan elementos de una estructura que coloca cada elemento en un conjunto fijo de posiciones, la estructura basada en delimitador es mucho más económica si a) los mensajes no contienen algunos elementos y b) algunos elementos no rellenan todo el espacio permitido. La única sobrecarga en las estructuras basadas en delimitadores es los propios delimitadores.

La codificación HL7 original define cinco delimitadores, que cada mensaje declara dentro del segmento MSH. Estos indican lo siguiente:

• Segmentos

• Campos

• Componentes

• Subcomponentes

• Repetición (de un campo, componente o subcomponente)

  Tenga en cuenta que, dado que los delimitadores son un aspecto fundamental de la codificación, primero debe definirlos. Un resultado de esto es que no puede haber ningún delimitador secundario. En ocasiones, esta limitación tiene efectos lamentables sobre el diseño de nuevos tipos de datos.

  En junio de 2003, HL7 publicó HL7 versión 2, sintaxis de codificación XML, versión 1. Este estándar define reglas de codificación alternativas para los mensajes HL7 versión 2.3.1 y 2.4, y proporciona un mecanismo para determinar reglas de codificación alternativas para versiones posteriores de HL7 2.X. En esencia, este nuevo estándar define etiquetas de elemento XML para los mensajes abstractos versión 2.3.1 y V2.4, segmentos, campos y tipos de datos, y crea reglas para definir las etiquetas necesarias para las nuevas estructuras creadas para las versiones posteriores del estándar versión 2. El proceso de definición de este estándar llevó a una serie de mejoras en las versiones 2.4 y 2.5. Esto ocurrió porque la creación de etiquetas XML llevó a la necesidad de abordar algunas ambigüedades de larga duración en el estándar subyacente. Como resultado, se crearon códigos de estructura de mensajes bien definidos para indicar variaciones en los mensajes abstractos asociados a eventos de desencadenador, b) grupos repetidos de segmentos con un mensaje abstracto se identificaron y denominaron formalmente, y c) el tipo de datos definido localmente, CM se reemplazó por tipos más específicos.

  Por ejemplo, lo siguiente es un mensaje de confirmación simple mediante el formato delimitado por canalización tradicional:

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  

Por el contrario, el siguiente es el mismo mensaje representado como un documento 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>  

Las siguientes funciones del Acelerador de Microsoft BizTalk para HL7 (BTAHL7) admiten estos requisitos:

• Compatibilidad con la codificación delimitada por canalización y XML.

• Compatibilidad con la traducción entre codificaciones delimitadas por XML y canalización.

Consulte también

Procesamiento de mensajes de HL7
Procesamiento de mensajes
Uso de esquemas HL7 2.X