Qué comunica realmente un código ACK de HL7
En la mensajería HL7 v2.x, casi todo mensaje que un sistema envía recibe un acuse de recibo (ACK) a cambio. El campo más importante de ese ACK es MSA-1, el código de acuse. Es un código de dos letras que le dice al emisor, sin ambigüedad, qué pasó con el mensaje: ¿se aceptó, contenía un error o se rechazó por completo? Acertar con estos códigos es la diferencia entre una interfaz fiable y una que pierde datos de pacientes en silencio. Esta guía explica los tres códigos a nivel de aplicación — AA, AE y AR — qué significa cada uno, cuándo debe enviarlos un receptor y cómo se relacionan con los conjuntos de códigos antiguo y nuevo. Para el panorama de cómo fluyen los acuses, consulta Mensajes ACK de HL7 explicados.
AA — Application Accept (aceptación)
AA significa "Application Accept". La aplicación receptora recibió el mensaje, lo entendió y lo procesó con éxito. Es el camino feliz: se registró un ingreso ADT^A01, se encoló una orden ORM, se archivó un resultado ORU. Cuando un emisor recibe AA, puede considerar la transacción completa y seguir adelante. En un motor de integración de tipo store-and-forward, AA es la señal para marcar el mensaje como entregado y sacarlo de la cola de reintentos.
Un matiz crítico: AA afirma el éxito a nivel de aplicación, no solo que los bytes llegaron. Un sistema que simplemente recibió un mensaje pero aún no lo ha validado ni almacenado no debe enviar AA. Enviar AA de forma prematura es una causa común de pérdida fantasma de datos — el emisor cree que el mensaje se procesó y deja de reintentar, mientras el receptor luego no consigue confirmarlo.
AE — Application Error (error)
AE significa "Application Error". El receptor entendió que llegó un mensaje y pudo analizar su estructura, pero algo de su contenido impidió procesarlo con éxito. Ejemplos clásicos: faltaba un campo obligatorio como el identificador del paciente (PID-3), un valor codificado no coincidía con ninguna entrada de la tabla del receptor, o un número de orden referenciado no existía. AE dice, en efecto: "recibí tu mensaje, veo lo que intentabas hacer, pero no puedo completarlo tal como llegó — corrige el contenido e inténtalo de nuevo".
Cuando un receptor envía AE, debe rellenar un segmento ERR (o MSA-3 en versiones antiguas) describiendo qué falló, para que el emisor o un analista de integración pueda diagnosticarlo. Un AE sin una descripción útil del error es de lo más frustrante de depurar; el artículo Depuración de fallos ACK de HL7 cubre cómo leerlos. La respuesta correcta del emisor ante un AE normalmente no es reintentar a ciegas — el mismo contenido volverá a fallar. Debe marcarse para revisión humana.
AR — Application Reject (rechazo)
AR significa "Application Reject". El receptor rechaza el mensaje a un nivel más fundamental que AE. AR es apropiado cuando el problema no es un error de contenido corregible sino uno estructural o contextual: un tipo de mensaje no soportado, una incompatibilidad de versión, un mensaje enviado al sistema equivocado, o un error de secuencia/procesamiento que invalida el mensaje en su conjunto. Donde AE dice "este contenido concreto es incorrecto", AR dice "no debería estar procesando este mensaje en absoluto".
La distinción práctica importa para la lógica de reintentos. Un AE suele indicar un problema de captura de datos aguas arriba que un humano puede corregir y reenviar. Un AR suele indicar un problema de configuración o enrutamiento que ningún reenvío arreglará hasta que alguien cambie la configuración de la interfaz. Tratar todo acuse negativo igual — reintentar AE y AR indefinidamente — es una causa frecuente de tormentas de mensajes que inundan un motor de integración.
AA vs AE vs AR de un vistazo
- AA (Aceptar): recibido, entendido y procesado con éxito. Transacción completa.
- AE (Error): recibido y entendido, pero el contenido no se pudo procesar. Corrige el contenido y reenvía tras revisión.
- AR (Rechazo): recibido pero rechazado — tipo erróneo, versión errónea, destino erróneo o error estructural. Corrige la configuración, no el contenido.
Puedes ver exactamente dónde está MSA-1 en un mensaje real pegándolo en el visor HL7, y puedes producir ACK bien formados con el código correcto usando el generador de ACK de HL7.
El otro conjunto de códigos: CA, CE y CR
Si has visto CA, CE y CR en MSA-1, te has topado con el "modo de acuse mejorado" de HL7. Son las contrapartes a nivel de commit (también llamado nivel de aceptación) de los códigos de aplicación:
- CA — Commit Accept: el mensaje se recibió de forma segura y se confirmó en almacenamiento, pero la aplicación aún no lo ha procesado necesariamente.
- CE — Commit Error: ocurrió un error al intentar aceptar el mensaje para su procesamiento posterior.
- CR — Commit Reject: el mensaje fue rechazado en la fase de aceptación.
La idea clave es que el modo mejorado separa "he recibido y almacenado tu mensaje de forma segura" (los códigos C) de "mi aplicación ha terminado de procesarlo" (los códigos A). En el modo de acuse original, un único ACK con AA/AE/AR cubre ambos significados a la vez. Qué modo está en juego lo gobiernan los campos MSH-15 y MSH-16, un tema que conviene entender antes de diseñar una interfaz nueva porque cambia cuántos acuses deberías esperar por mensaje.
Cómo decide un receptor qué código enviar
Un receptor bien diseñado sigue un orden de decisión claro. Primero, ¿puede aceptar el mensaje en absoluto — tipo correcto, versión soportada, destinado a este sistema? Si no, AR (o CR). Después, ¿puede analizar y validar el contenido — campos obligatorios presentes, códigos reconocidos, referencias resolubles? Si no, AE (o CE), acompañado de un segmento ERR descriptivo. Solo cuando ambas comprobaciones pasan y la aplicación ha hecho de verdad su trabajo devuelve AA (o CA). Codificar esta lógica correctamente, y emparejar cada código negativo con un mensaje de error accionable, es lo que convierte una interfaz frágil en una fiable. Cuando no sepas por qué un sistema socio devolvió un código concreto, empieza inspeccionando la estructura del mensaje en bruto en el visor HL7 y confirma que los segmentos MSH y MSA cuadran con lo que cada lado espera.
Resumen
Los códigos ACK de HL7 son compactos pero trascendentes. AA confirma el procesamiento exitoso en la aplicación, AE reporta un error de contenido que necesita corrección, y AR rechaza un mensaje que el receptor no debería estar procesando. Los códigos del modo mejorado CA, CE y CR los reflejan a nivel de commit, separando la recepción segura del procesamiento completo. Asocia cada código al comportamiento de reintento correcto — completar en AA, revisar en AE, reconfigurar en AR — y empareja siempre los acuses negativos con una descripción de error clara. Hazlo y tus interfaces fallarán de forma ruidosa y recuperable en vez de perder datos en silencio.