HL7 es un estándar para el intercambio de información entre sistemas de salud basado en mensajería. Es el estándar de interoperabilidad en sanidad más utilizado. A lo largo de los años y versiones, ha ido evolucionando y ampliando la información y eventos que recoge, hasta lograr un gran número de mensajes. Sin embargo, en algunas integraciones, un evento o algún dato, que es necesario integrar entre dos o mas sistemas, no está contemplado en el estándar. Para esto, HL7 se hizo flexible y dio la posibilidad de añadir segmentos ad hoc a los mensajes, o crear mensajes con nuevos eventos. Estos segmentos y mensajes se denominan Z en HL7.
Nota: en adelante hablaremos siempre de la versión HL7 v2 ya que en HL7 v3 es diferente, y bastante menos utilizado que la versión 2.
Contenidos
¿Qué es un segmento o mensaje Z?
Aunque pueda recordarnos a la película de zombies de Brad Pitt, los mensajes Z no son mensajes enviados por zombies.
La Z en estos mensajes se trata de un nemotécnico en HL7 para identificar que un segmento, o mensaje, está fuera del estándar. La nomenclatura que tendrá un segmento Z es libre, con la restricción de que empieza por Z, y la convención de que lo que siga sea representativo. Siempre recomendado que el identificador del segmento sea de tres caracteres, para seguir el estándar. Por ejemplo, un segmento definido para ampliar la información de administración de medicamentos en una integración de elementos de enfermería. Podría definirse un segmento ZAI (Z-Administration Information) donde cualquier nuevo integrador que revise el documento de conformidad sabrá que se trata de un segmento ad hoc tipo Z.
Definición
Es un tramo de información pactada localmente entre los sistemas involucrados en la integración, definida por usuario. Es decir, no forma parte del estándar. Por tanto, y por mantener la coherencia en la interoperabilidad, no se debe utilizar los segmentos Z para reemplazar al estándar. Es fácil dejarse llevar por la libertad de los mensajes Z y abusar de ello, y definir toda la integración con Z. Pero hay que tener en cuenta lo siguiente:
Al ser un acuerdo en el ámbito local de una integración entre dos partes, no es reutilizable ni extrapolable, por lo que se pierde el beneficio de utilizar estándares. Es una excepción, una forma de incluir información que permita ajustar la integración a necesidades excepcionales.
Pero no es posible definir de cualquier forma un segmento Z, para mantener una coherencia, se deben seguir unas recomendaciones de uso. Estas recomendaciones se materializan en Guías de implementación en HL7.
Lo más importante es tener claro por qué y cuando se deberá recurrir a esta excepción del estándar, y hacerlo únicamente en esa situación.
¿Cuando recurrir a un segmento Z en HL7?
Únicamente se debe crear un segmento Z en un mensaje HL7 cuando en una integración se necesite enviar información no definida en el propio estándar. Nunca se debe sustituir el estándar, ni duplicar definiciones con información que ya está definida en HL7. Antes de definir un segmento Z hay que estar seguro que la información no viene ya definida en algún otro segmento o mensaje de HL7.
Por ejemplo, si necesitamos integrar el segundo apellido de paciente, que ya está incluido en el segmento PID_5.3 no deberíamos incluirlo en un segmento Z. Ya tenemos el segmento PID para ello en los mensajes ADT. Sin embargo ¿Y si el mensaje que utilizamos, y que necesita enviar datos de paciente, no está definido en el estándar con un segmento PID en su estructura?
Restricciones
Como ya he ido comentando, hay que tener muy presente que el uso de segmentos Z no está recomendado, ya que está fuera del estándar, y por tanto su mantenimiento es costoso, y su re-utilización difícil. Solo debe considerarse por necesidades concretas de la integración. De la misma manera, si se define un mensaje Z hay que tener en cuenta que sólo será útil para esta integración. Difícilmente se podrá reutilizar para otra integración distinta, y deberá tener bien definido y especificado cada elemento del mensaje.
Si vamos a definir un mensaje Z, con unas especificaciones propias para incluir información no prevista en el estándar, debemos seguir ciertas directrices:
No modificar segmentos ya definidos en el estándar
El estándar HL7 ya está definido, podemos utilizar la herramienta Z para contemplar información no prevista, pero no re-definir el propio estándar.
Si estamos creando un mensaje Z en HL7, y necesitamos añadir información no prevista, debemos añadir un segmento Z, pero no modificar segmentos ya definidos para incluir la información que necesitamos. Aunque sea un solo campo, no podríamos, por ejemplo, modificar el segmento PID para incluir el segundo idioma del paciente. El idioma nativo viaja en el PID_15, según el estandar HL7 2.5. Si quisiéramos añadir segundo idioma en el evento A28 para la creación de ficha, deberíamos crear un mensaje Z28 con un segmento nuevo ZPD que incluya esta información.
No añadir segmentos del estándar a mensajes que no los incluyen
De igual manera, no podemos incluir un segmento HL7 en un mensaje que no lo tiene incluido en su definición. Por ejemplo, no podemos incluir en un mensaje ORU^R01 un segmento AL1 si no lo tiene incluido en su definición en el estándar. Si quisieramos incluir información de alergias del paciente (Segmento AL1) en un mensaje de resultados ORU^R01, tendríamos que incluir un segmento ZA1 (por ejemplo) con esta información.
No crear nuevos tipos de datos
Por mantener la compatibilidad y la coherencia, es necesario no inventarse tipos de datos. El estándar HL7 define suficientes tipos de datos para poder utilizarlos. Al final, se suele utilizar mucho los tipos que ya vienen definidos, aunque el valor que se transmita no sea adecuado. Por ejemplo, utilizar el tipo ST (Texto alfanumérico) para un formato de fecha distinto de los tipos DT, TS o DTM.
Guía para creación de Segmento Z en HL7
A la hora de incluir segmentos Z en nuestras especificaciones de conformidad debemos garantizar que se mantiene el estándar HL7. Aunque tengamos la capacidad de definir mensajes y segmentos nuevos, acorde a las necesidades de la integración, para garantizar la interoperabilidad, tendremos que tener en cuenta una serie de guías:
Identificador del segmento Z con 3 caracteres
Todo segmento Z debe tener un identificador que lo defina semánticamente, y que empiece por «Z». Así mismo, debe tener 3 caracteres, para seguir la norma HL7. Por ejemplo,
Reutilizar otros segmentos Z en lugar de crear nuevos
Reutilizar otros segmentos Z ya definidos en nuestra conformidad, o fuera de ella, siempre que sea posible . Esto es, evidentemente, con el fin de crear los menos segmentos Z posibles. La existencia de segmentos y mensajes Z altera la funcionalidad del estándar.
Información cohesionada
En HL7 los segmentos tienen una coherencia semántica. Es decir, cada segmento agrupa en sus campos una información que mantiene cohesión y sentido. Por ejemplo, un segmento PID contiene los campos de información de identificación del paciente: Nombre, apellidos, tarjeta sanitaria, domicilio, teléfono, sexo, etc. No contiene información sobre alergias (Segmento AL1) o resultado de una prueba clínica (Segmento OBX), ni datos de un episodio (Segmento PV1).
En nuestros segmentos Z debe mantenerse esta directriz. No debemos crear un segmento que contenga mezcla de datos con un contenido semántico dispar. Por ejemplo, un segmento ZAI donde incluimos información de administración de medicamentos, y algún campo del mensaje contiene, por ejemplo, el segundo idioma del paciente, que no es un dato de medicamentos ni de administración.
Ejemplo de uso de segmento Z en HL7
Veamos un caso práctico hipotético donde podríamos necesitar información no prevista en el estándar que nos lleve a utilizar segmentos Z en HL7.
En el Hospital X se incorpora un nuevo circuito funcional que requiere una integración a medida.
El servicio de Obstetricia ha incluido en su software departamental una integración con el PACS del centro, para adquirir imágenes de ecógrafos en las citas de seguimiento de las gestantes. Este software realiza cálculos de progreso y probabilidades, y permite el tratamiento de imágenes DICOM de los ecógrafos, y elaboración de informes. Estos informes se incorporan al gestor documental del centro.
Desde el HIS se enviará mensajería de citas SIU^S12 hacia el software de Obstetrícia para el registro del caso. Previamente habrá enviado la inclusión de la ecografía en la Worklist del PACS.
El Software de Obstetricia necesitará el Accession Number en el mensaje de cita, para asociar la prueba con la visita. De esta manera, el día de la cita podrá obtener la prueba correspondiente, vinculada en el HIS al episodio y visita. Además, otros datos de la paciente como el Grupo Sanguíneo y RH, TPAL, IMC, Anti-D, etc.
Una vez el día de la cita, el software incluirá en el Gestor Documental el informe de la visita, de la ecografía, e informará al HIS del identificador del informe en dicho repositorio.
Mensaje SIU^S12 Notification of new appointment booking Trigger
El mensaje SIU con trigger S12 se envía para la notificación de reserva de cita, normalmente de Consultas Externas. En este caso, la inclusión de una cita de gestante en la agenda de Obstetrícia.
La estructura definida del mensaje es como sigue:
Los valores de la paciente se pueden incluir en segmentos OBX. La definición del estandar para el mensaje SIU^S12 admite un segmento OBX opcional para observaciones del paciente.
Este mensaje incorpora un segmento AIS relacionado con el recurso, pero no admite posibilidad de enviar un dato como el Accession Number de una prueba.
Por ello, vamos a definir un segmento Z específico para esta integración, donde viajan los datos del recurso asignado para la prueba, incluyendo el Accession Number.
Segmento ZAR – Z -Recurso Asignado
El primer punto a tratar es dónde ubicar el segmento en la estructura del mensaje. Un segmento Z no se puede ubicar en cualquier parte, debe seguir la coherencia del estándar, y mantener cohesión semántica.
En este caso, es evidente que tendría que formar parte del grupo asociado a los recursos, que sigue al RGS – Resource Group Segment.
El contenido es una ampliación del contenido del segmento AIS, por tanto debe ponerse a continuación.
Respecto a los campos del segmento, teniendo en cuenta que el identificador del Accession Number es un número de orden, que en el ORM de petición y en la devolución del PACS, vendrá en el ORC-3 – Filler Order Number, el tipo de datos debe ser similar. Esto es, es el tipo de datos que tendrá en la inclusión en la Worklist.
El resto de valores que incluimos en el segmento ZAR, siguiendo la misma política y utilizando tipos de datos definidos en HL7 en relación a la información que incluyen.
