HL7 (Health Level 7) es un conjunto de especificaciones técnicas para el intercambio informatizado de datos clínicos, financieros y administrativos entre Sistemas de Información Hospitalaria (HIS). Estas especificaciones se integran de diversas formas en el conjunto de Normas oficiales americanas (ANSI) e Internacionales (ISO).
La L7 de HL7 indica que es una norma que opera en la capa 7, es decir, en la capa de aplicación, del modelo OSI. Esto significa que HL7 no tiene que tener en cuenta las consideraciones de seguridad en el intercambio, ni las de transporte de mensajes (de eso se encargan capas de nivel inferior como SSL/TLS para la seguridad o TCP para el transporte de datos, por ejemplo). Para ser más precisos, la capa 7 soporta las comunicaciones para los procesos y aplicaciones de usuario final y la presentación de datos para las aplicaciones de software orientadas al usuario. Al ser la capa más alta del modelo OSI, y la más cercana al usuario final, la capa 7 proporciona funciones específicas de la aplicación, como identificar la comunicación de los partners y la calidad del servicio entre ellos, determinar la disponibilidad de recursos, considerar la privacidad y la autenticación del usuario, y sincronizar la comunicación, así como conectar la aplicación con los niveles inferiores del modelo OSI.
Volviendo a la norma HL7, la versión 2 de HL7 (también conocida como Pipehat) se creó originalmente en 1989, pero se sigue utilizando y actualizando con frecuencia, lo que ha dado lugar a las versiones 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, 2.6, 2.7, 2.7.1, 2.8, 2.8.1, 2.8.2 y 2.9. Las normas v2.x son compatibles con versiones anteriores (por ejemplo, un mensaje basado en la versión 2.3 será entendido por una aplicación que admita la versión 2.6) y, en versiones superiores, se puede ver que se reservan algunos campos para ello.
A pesar de tener más de 30 años, HL7v2 sigue siendo la norma de interfaz sanitaria más utilizada con diferencia, según el portal HL7.org que indica:
- El 95% de las organizaciones estadounidenses de salud utilizan las normas de la interfaz HL7v2
- Más de 35 países tienen implementaciones del interfaz HL7
Con el tiempo, las normas de la interfaz HL7 han logrado ayudar en gran medida a los proveedores sanitarios y a las organizaciones tecnológicas:
- Garantizan datos de HCE uniformes, para una visión coherente y completa del paciente
- Automatizan los flujos de trabajo, al reducir y eliminar la introducción manual de datos
- Ayudan a intercambiar electrónicamente informes sanitarios con los reguladores
- Historias clínicas digitales abiertas y acceso de los pacientes a los datos
- Reducen las inversiones en nuevas actualizaciones tecnológicas al basarse en una norma común
Mensajes
La norma se redactó a partir del supuesto de que un acontecimiento en el mundo real de la atención sanitaria crea la necesidad de que los datos fluyan entre los sistemas. El evento del mundo real se denomina el evento desencadenante.
Un evento desencadenante es un mensaje, o un bloque de datos intercambiado, que describe un evento que ya sucedió. La norma HL7v2 define los mensajes (y su contenido) enviados entre las entidades participantes en el ciclo de vida de la atención sanitaria. Hay varios tipos de mensajes HL7v2. Algunos de ellos se presentan en la siguiente tabla:
| Tipo | Contenidos |
|---|
| ADT | Admisión, descarga y transferencia |
| ORM | Entrada de pedidos |
| ORU | Resultado de observación |
| ORL | Resultado de la orden de laboratorio |
| MDM | Gestión de documentos médicos |
| DFT | Transacciones financieras detalladas |
| BAR | Registro de la cuenta de facturación |
| SIU | Información de horarios no solicitada |
| RDS | Dispensación de farmacia/tratamiento |
| RDE | Pedido codificado de farmacia/tratamiento |
| ACK | Mensaje de agradecimiento |
| CRM | Información sobre ensayos clínicos |
Según se actualizaba la norma y se incrementaban las versiones, aparecieron nuevos tipos de mensajes y algunos de ellos dejaron de utilizarse. Así, distintas versiones de la norma HL7v2 tienen un número diferente de mensajes soportados (que va en aumento). Por ejemplo, hay más de 200 mensajes HL7 diferentes disponibles para su uso en mensajes HL7 en la versión 2.8.
Ahora veamos los segmentos con más detalle.
Segmento
Un segmento es una agrupación lógica de campos de datos. Los segmentos de un mensaje pueden ser obligatorios u opcionales. Pueden aparecer solo una vez en un mensaje o puede permitirse su repetición. A cada segmento se le asigna un nombre[...] Cada segmento se identifica mediante un código único de tres caracteres conocido como el ID del segmento.
En un mensaje HL7, cada segmento del mensaje contiene una categoría específica de información, por ejemplo, información del paciente o datos de la visita del paciente. Los diferentes tipos de mensajes HL7 contienen diferentes segmentos HL7. Para ser precisos, el tipo de mensaje determina los tipos de segmentos que se esperan en el mensaje. Al mismo tiempo, cada mensaje tiene como primer segmento el MSH, el cual incluye un campo que identifica el tipo de mensaje. Los tipos de segmento que se utilizan en un tipo de mensaje concreto se especifican mediante la notación gramatical de segmentos utilizada en las normas HL7. Por ejemplo, hay más de 170 segmentos en los mensajes HL7 de la versión 2.8.
En general, los segmentos tienen campos separados por el delimitador compuesto. Un campo puede tener subcompuestos (componentes) separados por el delimitador subcompuesto, y los subcompuestos pueden tener subsubcompuestos (subcomponentes) separados por el delimitador subsubcompuesto. Los delimitadores predeterminados son: salto de línea para el separador de segmentos, barra vertical (|) para el separador de campos, signo de intercalación (^) para el separador de componentes, ampersand (&) para el separador de subcomponentes y almohadilla (#) para el separador de truncamiento predeterminado. La virgulilla o "tilde de la ñ" (~) es el separador de repeticiones predeterminado. Cada segmento comienza con una cadena de 3 caracteres que identifica el tipo de segmento.
Para ser lo más flexibles posibles y lograr un consenso, los comités de HL7 se vieron obligados a definir muchos campos de segmentos como opcionales. El inconveniente de esta decisión es que no se puede estar seguro de que una información concreta vaya a estar presente en un mensaje determinado. Esta es una de las razones por las que un mismo mensaje puede variar significativamente de un proveedor a otro.
Además, como los mensajes HL7 se utilizan para comunicar todo tipo de información relacionada con la atención sanitaria a una variedad de sistemas distintos, a veces los mensajes HL7 deben contener datos personalizados que no pueden incluirse en ningún segmento definido para su tipo de mensaje. Por ello, la norma HL7 permite a los proveedores de sistemas crear un segmento Z con campos personalizados para transmitir estos datos.
Por costumbre, todos los segmentos personalizados comienzan con la letra Z. Por ejemplo, se podría crear un segmento ZPD para incluir información demográfica personalizada de los pacientes. Los segmentos Z pueden colocarse en cualquier parte de un mensaje HL7, sin embargo, normalmente se sitúan como el último segmento de un mensaje. Las aplicaciones que procesan mensajes HL7 normalmente se configuran para ignorar los segmentos Z de HL7 que no saben cómo manejar.
Tipos de datos
El bloque básico utilizado para crear o restringir el contenido de un campo de datos[...] A cada campo se le asigna un tipo de dato que define el dominio de valores del campo, es decir, los posibles valores que DEBE tomar. El tipo de datos DEBERÁ tener un tipo extraído de la lista de tipos de datos definidos[...] Los tipos de datos pueden ser primitivos o compuestos. Los tipos de datos primitivos consisten en una serie de caracteres como se especifica en el tipo de datos. Los tipos de datos compuestos están formados por un conjunto de componentes que a su vez están asignados a un tipo de datos, que de nuevo pueden ser tipos de datos primitivos o compuestos. En el caso de los tipos de datos compuestos, los componentes de un componente se denominan subcomponentes, y únicamente DEBERÁN tener asignados tipos de datos primitivos.
Cada campo definido en la norma tiene su tipo de dato. Pueden ser, por ejemplo, strings, tiempo, dinero, fecha, dirección, matrices y muchas otras cosas.
Tablas
Además de los valores de los campos, definidos por los usuarios, también existen tablas de valores, definidas por la norma. Enumeran todos los valores válidos para los campos que utilizan esa tabla. Hay 4 tipos diferentes de esas tablas:
- Norma HL7: estos valores no pueden redefinirse de forma local; sin embargo, la propia tabla puede ampliarse para admitir valores definidos de manera local.
- Definidas por el usuario: esos valores se definen de manera local y varían de una institución a otra
- Externas: esos valores son definidos y publicados por otras organizaciones estándar
- Locales: esos valores también se definen de forma local y pueden utilizarse en segmentos Z
En los siguientes artículos, veremos algunos de los mensajes, sus segmentos y campos, y veremos algunos ejemplos.
Esto es todo por el momento. Si tenéis alguna pregunta o duda, podéis escribirla en los comentarios de esta publicación.
