¿Qué es un Acuse de Recibo HL7?
En HL7 v2.x, un mensaje de acuse de recibo (comúnmente llamado ACK) es la respuesta que envía una aplicación receptora a la aplicación emisora tras procesar un mensaje entrante. Los acuses de recibo cumplen dos funciones críticas en la integración sanitaria: confirman que un mensaje fue recibido y procesado correctamente, y proporcionan un mecanismo de retroalimentación para notificar errores cuando algo falla. La especificación HL7 v2.x define el protocolo de acuse de recibo en el Capítulo 2 como parte fundamental del modelo de fiabilidad del estándar.
Sin acuses de recibo, el sistema emisor no tiene forma de saber si un pedido de laboratorio llegó al sistema de información de laboratorio, si el mensaje de ingreso ADT actualizó el sistema de programación, o si el pedido de radiología fue aceptado por el RIS. Los mensajes ACK cierran este bucle proporcionando una confirmación estructurada y legible por máquina para cada transacción.
Los Tres Códigos ACK: AA, AE y AR
HL7 v2.x define tres códigos de acuse de aplicación en MSA-1:
- AA — Aceptación de Aplicación: La aplicación receptora procesó correctamente el mensaje. Los datos se almacenaron, el pedido se realizó o el evento se registró. Un ACK AA indica al emisor que la transacción está completa y no es necesaria la retransmisión.
- AE — Error de Aplicación: La aplicación receptora recibió el mensaje pero encontró un error no fatal durante el procesamiento — por ejemplo, un campo obligatorio faltante, un valor de código no encontrado en la tabla de referencia del receptor, o una regla de negocio violada. El mensaje puede haberse procesado parcialmente o no. Los ACK AE normalmente incluyen MSA-3 con una descripción del error y opcionalmente un segmento ERR con códigos de error estructurados.
- AR — Rechazo de Aplicación: La aplicación receptora rechazó el mensaje sin procesarlo. Las causas habituales incluyen un tipo de mensaje desconocido, una versión no soportada o un fallo de seguridad o autorización. Un ACK AR indica que la aplicación emisora debe resolver el problema subyacente antes de retransmitir.
Intercambio de MSH: Enrutando el ACK de Vuelta al Emisor
La fuente de la mayoría de los errores en el análisis de ACKs es el intercambio incorrecto de campos MSH. La especificación HL7 v2.x requiere que al generar un ACK, el sistema receptor intercambie los identificadores de envío y recepción del mensaje original para que el ACK se enrute de vuelta al emisor original:
- MSH-3 ↔ MSH-5: La Aplicación Emisora se convierte en Aplicación Receptora y viceversa.
- MSH-4 ↔ MSH-6: La Instalación Emisora se convierte en Instalación Receptora y viceversa.
- MSH-10 (nuevo): Se asigna un nuevo ID de control único al propio ACK, sin reutilizar el del mensaje original.
Los errores en este intercambio son una de las causas más comunes del escenario "ACK recibido pero mensaje considerado perdido": el motor de interfaz recibe el ACK pero no puede vincularlo con la transacción original porque el ID de control o los identificadores de enrutamiento no coinciden.
El Segmento MSA
Todo mensaje ACK contiene un segmento MSA (Message Acknowledgment) como segundo segmento. MSA contiene tres campos clave:
- MSA-1 — Código de Acuse: AA, AE o AR. Es el código de estado legible por máquina que el sistema emisor utiliza para determinar qué hacer a continuación.
- MSA-2 — ID de Control del Mensaje: El valor de MSH-10 del mensaje original, no el ID de control del propio ACK. Esto vincula el ACK a la transacción específica que está acusando, permitiendo la deduplicación y la lógica de reintentos en el sistema emisor.
- MSA-3 — Texto del Mensaje: Descripción opcional en texto libre. Se usa habitualmente en respuestas AE y AR para describir el error de forma legible. No es interpretable por máquinas; para códigos de error estructurados se usa el segmento ERR.
Modos de Acuse: Original y Mejorado
HL7 v2.x soporta dos modos de acuse, negociados en MSH-15 (Tipo de Acuse de Aceptación) y MSH-16 (Tipo de Acuse de Aplicación). En el Modo Original, un único ACK sirve tanto como acuse de transporte como de aplicación. En el Modo Mejorado, pueden requerirse dos ACKs separados: uno de commit (CA/CE/CR) de la capa de transporte y uno de aplicación (AA/AE/AR). La mayoría de las interfaces de producción usan el Modo Original con ACKs de aplicación. Esta herramienta genera ACKs en Modo Original según la especificación HL7 v2.x Capítulo 2.
Aplicaciones Prácticas para Equipos de Integración
Los analistas de interfaces, ingenieros de integración y equipos de QA utilizan la generación de ACKs en varios escenarios habituales. Al probar una nueva interfaz sin un sistema receptor activo, generar una respuesta ACK sintética permite al sistema emisor ejercitar su lógica de manejo de acuses. Al redactar documentos de mapeo o especificaciones de interfaces, incluir un ACK de muestra junto al mensaje disparador ofrece a los revisores una imagen completa del intercambio de mensajes esperado. Al formar a nuevos analistas, repasar un ACK generado junto al mensaje original es una de las formas más rápidas de explicar el patrón de handshake HL7. Y al investigar problemas de producción donde los mensajes se retransmiten repetidamente, generar manualmente un ACK a partir del mensaje original y compararlo con el ACK recibido puede localizar rápidamente la discrepancia de intercambio o de ID de control que está causando el problema.