Introducción: Por Qué los Acuses de Recibo Son la Base de la Fiabilidad HL7
En cualquier sistema de información sanitaria que intercambia mensajes HL7 v2.x, el acuse de recibo — universalmente llamado ACK — es el mecanismo que hace que todo el modelo de comunicación sea fiable. Cuando un sistema de admisión hospitalaria envía un mensaje ADT^A01 al HCE, o un sistema de información de laboratorio envía un resultado ORU^R01 al sistema del proveedor prescriptor, ninguno de los dos sistemas puede tener la certeza de que la transacción completó correctamente a menos que reciba un acuse de recibo a cambio.
Sin ACKs, un sistema emisor tiene tres malas opciones: asumir que el mensaje fue recibido (arriesgado), seguir retransmitiendo indefinidamente (saturación), o construir un mecanismo de confirmación personalizado fuera del estándar HL7 (costoso). El protocolo de acuse de recibo HL7 v2.x elimina los tres problemas definiendo un mensaje de respuesta estandarizado y liviano que se espera que toda aplicación HL7 produzca y procese.
Este artículo cubre la estructura completa del mensaje ACK HL7: los tres códigos de acuse (AA, AE y AR), las reglas de intercambio MSH que enrutan el ACK de vuelta al emisor, el segmento MSA que transporta el estado de acuse, y las implicaciones prácticas de cada código para los flujos de trabajo de integración sanitaria.
Nota: Este artículo tiene fines educativos y de referencia técnica. No constituye asesoramiento médico ni legal.
El Modelo de Acuse de Recibo HL7 v2.x
El protocolo de acuse de recibo HL7 v2.x está definido en el Capítulo 2 de la especificación bajo "Control de Mensajes". Su fundamento es sencillo: por cada mensaje enviado, la aplicación receptora devuelve un mensaje ACK confirmando qué ocurrió. El ACK indica al emisor una de tres cosas: el mensaje fue aceptado y procesado, el mensaje fue procesado pero con errores, o el mensaje fue rechazado por completo.
Este protocolo se aplica a los acuses de recibo a nivel de aplicación — respuestas de la aplicación que realmente procesó los datos, no solo de la capa de transporte que recibió los bytes. La distinción importa porque un mensaje puede entregarse correctamente a través de la red (conexión TCP establecida, bytes recibidos) pero fallar a nivel de aplicación (el HCE no pudo encontrar el registro del paciente, el código de laboratorio no fue reconocido, la versión del mensaje no está soportada).
Modo Original vs. Modo Mejorado
HL7 v2.x define dos modos de acuse negociados a través de MSH-15 (Tipo de Acuse de Aceptación) y MSH-16 (Tipo de Acuse de Aplicación):
- Modo Original: Un único mensaje ACK sirve como confirmación de transporte y de aplicación al mismo tiempo. Es el modo utilizado por la gran mayoría de las interfaces HL7 en producción. Cuando MSH-15 y MSH-16 están vacíos o establecidos en AL (Always), se aplica el Modo Original.
- Modo Mejorado: Se requieren dos acuses separados. La capa de transporte envía primero un ACK de confirmación (usando códigos CA, CE o CR) para confirmar que el mensaje fue recibido y almacenado de forma segura. Luego la aplicación envía un ACK de aplicación separado (AA, AE o AR) tras el procesamiento. El Modo Mejorado rara vez se usa en la práctica, pero se observa ocasionalmente en entornos con colas de mensajes de almacenamiento y reenvío.
Este artículo se centra en los ACKs de aplicación en Modo Original — el tipo generado por esta herramienta y utilizado en la gran mayoría de las interfaces HL7 v2.x.
Los Tres Códigos de Acuse de Aplicación
El código de acuse en MSA-1 es el campo más importante de cualquier mensaje ACK. Indica al sistema emisor exactamente qué ocurrió con su transacción y determina qué debe hacer a continuación.
AA — Aceptación de Aplicación
Un acuse AA (Application Accept) significa que la aplicación receptora recibió, analizó y procesó correctamente el mensaje. Los datos se han almacenado: el paciente fue ingresado, el pedido se realizó, el resultado se guardó. Desde la perspectiva del emisor, un ACK AA es la luz verde: la transacción está completa, no se requiere retransmisión y el mensaje puede marcarse como entregado correctamente en la cola saliente del emisor.
AA es la respuesta esperada para el camino feliz. En una interfaz HL7 que funciona correctamente, la gran mayoría de los mensajes deberían recibir ACKs AA. Una alta tasa de respuestas AE o AR indica problemas de configuración, problemas de calidad de datos o especificaciones de interfaz desalineadas entre sistemas.
AE — Error de Aplicación
Un acuse AE (Application Error) significa que la aplicación receptora encontró un error durante el procesamiento. El mensaje fue comprendido (analizado correctamente), pero algo impidió un procesamiento limpio. Las causas habituales incluyen:
- Un campo obligatorio está ausente (por ejemplo, el identificador de paciente PID.3 está vacío)
- Un valor codificado en un campo CE o CWE no se encuentra en la tabla de referencia del receptor (por ejemplo, un código LOINC desconocido en OBX.3)
- Una violación de regla de negocio (por ejemplo, el paciente ya existe con datos demográficos en conflicto)
- Una violación de restricción de base de datos (por ejemplo, número de pedido duplicado)
La característica clave de AE es la ambigüedad sobre si el mensaje fue procesado parcialmente. La especificación no requiere que los sistemas receptores reviertan el procesamiento parcial antes de enviar AE — algunos sistemas pueden haber procesado partes del mensaje antes de que ocurriera el error. Esta ambigüedad es una razón por la que los ACKs AE requieren una gestión cuidadosa: el sistema emisor no puede simplemente retransmitir sin entender primero qué, si acaso algo, fue procesado.
Los ACKs AE normalmente incluyen una descripción legible en MSA-3 y pueden incluir un segmento ERR con códigos de error estructurados, ubicación del error a nivel de campo (nombre de segmento, secuencia, posición de campo) e indicadores de severidad.
AR — Rechazo de Aplicación
Un acuse AR (Application Reject) significa que la aplicación receptora rechazó el mensaje por completo sin intentar procesarlo. A diferencia de AE, AR indica que no hubo procesamiento parcial — el mensaje fue examinado a nivel estructural o de enrutamiento y se encontró inadecuado para el procesamiento antes de que se intentara ninguna operación de datos. Las causas habituales incluyen:
- Tipo de mensaje no soportado (MSH-9 contiene un código de mensaje que el receptor no gestiona)
- Versión HL7 no soportada (MSH-12 contiene una versión para la que el receptor no ha sido configurado)
- Fallo de autorización (la aplicación o instalación emisora en MSH-3/MSH-4 no está autorizada a enviar mensajes a este receptor)
- Malformación estructural tan grave que el analizador no puede determinar el tipo de mensaje
AR es la señal más clara para el sistema emisor: algo está fundamentalmente mal en cómo está configurada la interfaz o cómo está estructurado el mensaje. Retransmitir el mismo mensaje producirá el mismo AR. El emisor debe investigar y corregir la causa raíz — actualizando el tipo de mensaje, negociando la alineación de versiones con el sistema receptor, o resolviendo la configuración de autorización — antes de retransmitir.
Intercambio de Campos MSH: Enrutando el ACK de Vuelta
El mensaje ACK es en sí mismo un mensaje HL7 completo, comenzando con su propio segmento MSH. La información de enrutamiento en este MSH debe establecerse correctamente para que el ACK llegue al emisor original, no a un sistema no relacionado. La especificación HL7 v2.x define un conjunto preciso de reglas para cómo se derivan los campos MSH del ACK a partir de los campos MSH del mensaje original:
Las Cuatro Reglas de Intercambio Fundamentales
- ACK MSH-3 = MSH-5 Original (Aplicación Emisora ← Aplicación Receptora): La entidad que recibe el mensaje original se convierte en el emisor del ACK. Por lo tanto, la "Aplicación Emisora" del ACK es la "Aplicación Receptora" del mensaje original.
- ACK MSH-4 = MSH-6 Original (Instalación Emisora ← Instalación Receptora): El mismo intercambio para los identificadores de instalación. La instalación que recibió el mensaje ahora envía el ACK.
- ACK MSH-5 = MSH-3 Original (Aplicación Receptora ← Aplicación Emisora): El ACK debe entregarse a la aplicación del emisor original.
- ACK MSH-6 = MSH-4 Original (Instalación Receptora ← Instalación Emisora): El ACK debe entregarse a la instalación del emisor original.
En resumen: los identificadores de envío y recepción en el MSH del ACK son el inverso del MSH del mensaje original. Esta es la regla de intercambio que enruta el ACK de vuelta a su origen.
Nuevo ID de Control (MSH-10)
El MSH-10 del ACK recibe un nuevo ID de control único — nunca el ID de control del mensaje original. El ID de control original se lleva en MSA-2 (ver a continuación) como la referencia cruzada. El propio MSH-10 del ACK es necesario porque el ACK es en sí mismo un mensaje que puede necesitar ser rastreado, registrado y deduplicado por la infraestructura de la interfaz. Si una interfaz recibe ACKs duplicados para la misma transacción, la unicidad de MSH-10 permite identificar y descartar los duplicados.
El Segmento MSA en Detalle
El segmento MSA (Message Acknowledgment) es el segundo — y típicamente el último requerido — segmento en un mensaje ACK. Sus tres campos más importantes son:
MSA-1: Código de Acuse
El estado legible por máquina: AA, AE o AR. Los motores de interfaz y los receptores de aplicaciones analizan este campo primero para determinar el resultado de la transacción. El valor se compara con la cola de mensajes salientes del sistema emisor para determinar si marcar el mensaje como completado, ponerlo en cola para reintento, o escalarlo para revisión manual.
MSA-2: ID de Control del Mensaje
El valor de MSH-10 del mensaje original, no el MSH-10 del propio ACK. Este es el campo de referencia cruzada crítico. Cuando un sistema emisor recibe un ACK, busca MSA-2 en su cola de mensajes salientes para encontrar la transacción original. Sin un MSA-2 correcto, el sistema emisor no puede identificar a qué mensaje se refiere el ACK y lo trata como un ACK huérfano — lo que normalmente significa que el mensaje original permanece en estado "pendiente de acuse" y eventualmente activa la retransmisión.
MSA-3: Texto del Mensaje
Un campo de texto libre opcional que proporciona una descripción legible del estado de acuse. Para respuestas AA, normalmente está vacío o contiene un mensaje genérico de éxito. Para respuestas AE y AR, debería contener suficiente detalle para que un analista comprenda el error sin necesitar inspeccionar el segmento ERR completo. MSA-3 no está pensado para ser analizado por máquinas — existe como complemento legible para los datos de error estructurados en ERR.
Implicaciones Prácticas para Equipos de Integración
Comprender los códigos ACK y el intercambio MSH tiene valor práctico directo para cualquier persona que construya, pruebe o mantenga interfaces HL7.
Pruebas de Nuevas Interfaces
Al poner en servicio una nueva interfaz HL7 sin un sistema receptor activo, los equipos frecuentemente necesitan generar respuestas ACK sintéticas para validar que el sistema emisor las gestiona correctamente. Un ACK AA generado confirma que el sistema emisor marca correctamente los mensajes como procesados. Un ACK AR generado verifica que el sistema emisor escala adecuadamente los tipos de mensaje no reconocidos. Estas pruebas pueden realizarse antes de que el sistema receptor esté disponible usando ACKs generados manualmente o con herramientas especializadas.
Diagnóstico de Problemas de Retransmisión
Cuando una interfaz está retransmitiendo mensajes a pesar de un aparente intercambio de ACK, la causa más común es una discrepancia en MSA-2 o un enrutamiento MSH incorrecto en el ACK. Comparar un ACK capturado con los campos MSH del mensaje original — campo por campo — revela rápidamente si el sistema receptor está generando ACKs conformes. El panel de espejo del Generador de ACK HL7 proporciona exactamente esta comparación en un formato estructurado y visual.
Redacción de Especificaciones de Interfaces
Incluir mensajes ACK de muestra en las especificaciones de interfaces — uno para cada escenario de AA, AE y AR — ayuda a los equipos emisor y receptor a acordar el comportamiento esperado antes de que comience la implementación. Una especificación que solo documenta el mensaje disparador pero omite el acuse deja ambigüedad sobre cómo deben comunicarse los errores y cómo debe activarse la retransmisión.