RabbitMQ en la capa de integración de una plataforma clínica: colas, consumidores, dead-letter y los resultados que no llegan a la historia clínica

Qué vas a conseguir

Entender lo bastante la capa de mensajería de una plataforma clínica para vigilarla y para actuar cuando algo se atasca. Entre el sistema de laboratorio, el de admisiones y la historia clínica electrónica viajan mensajes (normalmente HL7) que pasan por un motor de integración y por RabbitMQ. Si una cola deja de vaciarse, en planta no se ven resultados. La guía cubre cómo se monta, qué se mira, qué alarmas poner y cómo recuperar un consumidor parado sin perder ni duplicar un solo mensaje.

Antes de empezar

• Un usuario de la interfaz de gestión (puerto 15672) con la etiqueta monitoring para el equipo de operaciones; administrator solo para quien cambia la configuración.
• Acceso al servidor de RabbitMQ para rabbitmqctl y rabbitmq-diagnostics (necesitan los permisos del usuario del servicio).
• El mapa de interfaces: qué sistema publica en qué exchange, qué cola lee cada consumidor y quién es el responsable de cada uno (equipo de integración, proveedor, operaciones).
• El procedimiento de contingencia clínico: qué hace el laboratorio o la planta cuando los resultados no llegan por la vía normal. No lo decide IT, pero IT tiene que saber cuándo activarlo.

1. Cómo viaja un resultado

Un resultado validado en el laboratorio sale como mensaje, pasa por el motor de integración y llega a la historia clínica:

1. El motor de integración recibe el mensaje del sistema de laboratorio y lo publica en un exchange (clinico.resultados) con una clave de enrutado (lab.resultado).
2. El exchange, según sus bindings, lo deja en una o varias colas: lab.resultados.hce para la historia clínica, y quizá otra para un sistema de archivo.
3. Un consumidor (el servicio de integración de la historia clínica) lee de la cola, entrega el mensaje y, cuando la historia clínica lo ha aceptado, envía el ack. Solo entonces RabbitMQ lo borra.

2. Mirar el estado: interfaz de gestión y rabbitmqctl

En la interfaz de gestión, la pestaña de colas muestra por cada una: Ready (esperando consumidor), Unacked (entregados y sin confirmar), Total, las tasas de entrada, entrega y ack, y el número de consumidores. Desde la línea de comandos:

›rabbitmqctl list_queues -p clinico name type messages_ready messages_unacknowledged consumersTimeout: 60.0 seconds ...Listing queues for vhost clinico ...name                 type     messages_ready  messages_unacknowledged  consumerslab.resultados.hce   quorum   0               3                        1adt.eventos.hce      quorum   0               0                        1lab.resultados.dlq   quorum   0               0                        0›rabbitmqctl list_consumers -p clinico›rabbitmq-diagnostics alarmsNode rabbit@rabbit01 reported no alarms, local or clustered

• Ready bajo, Unacked bajo y un consumidor: la cola se vacía al ritmo al que llega. Es lo normal.
• Ready creciendo y 0 consumidores: nadie está leyendo. Es el caso del apartado 5.
• Ready creciendo, Unacked igual al prefetch y la tasa de ack a cero: el consumidor está conectado pero atascado, esperando a la historia clínica o colgado.
• rabbitmq-diagnostics alarms muestra las alarmas de memoria y disco. Con una activa, RabbitMQ bloquea a los publicadores: el problema ya no es una cola, es todo el nodo.

3. Qué monitorizar

• Profundidad de cola (messages_ready) por encima de un umbral durante unos minutos. El umbral depende de la cola: una de resultados que suele estar a cero no es igual que una de carga nocturna.
• Consumidores = 0 en las colas que siempre deben tener uno: alarma inmediata, sin esperar a que crezca.
• Unacked atascado al nivel del prefetch sin acks durante varios minutos.
• Mensajes en la dead-letter mayor que cero: cada uno es un resultado o un evento que no ha llegado.

El plugin de Prometheus (puerto 15692) expone métricas como rabbitmq_queue_messages_ready y rabbitmq_queue_consumers; para tenerlas por cola, el endpoint /metrics/per-object o /metrics/detailed. Desde ahí, Grafana o la herramienta de monitorización de la plataforma, con la alarma enviada a la guardia.

4. Dead-letter: los mensajes que no se pueden entregar

Un mensaje va a la dead-letter cuando el consumidor lo rechaza sin reencolar, cuando caduca por TTL, cuando la cola supera su longitud máxima o, en colas quorum, cuando supera su límite de entregas (un mensaje que hace fallar al consumidor una y otra vez). Se configura con una política:

›rabbitmqctl set_policy -p clinico DLX-lab "^lab\.resultados\.hce$" '{"dead-letter-exchange":"clinico.dlx"}' --apply-to queues›rabbitmqctl list_policies -p clinico

Con el exchange clinico.dlx enlazado a lab.resultados.dlq. Cada mensaje en la dead-letter lleva la cabecera x-death con el motivo y la cola de origen.

• La dead-letter se revisa, no se purga. Cada mensaje es un dato clínico que no ha llegado a su destino.
• Corregida la causa (un código de prueba que la historia clínica no conocía, un paciente sin dar de alta), el equipo de integración decide reprocesarlo. La interfaz de gestión puede mover los mensajes de vuelta a la cola original si están activos los plugins de shovel.

A una cola solo se le aplica una política (la de mayor prioridad). Una política nueva que coincida con una cola puede sustituir a la que ya tenía, con su TTL o su límite de longitud. Revisa list_policies antes de crear otra, y nunca pongas un TTL o una longitud máxima en una cola clínica sin dead-letter: los mensajes se descartarían en silencio.

5. El ticket: "los resultados de laboratorio no llegan a la historia clínica"

Martes, 10:35. Una supervisora de urgencias llama: hay analíticas validadas en el laboratorio que no aparecen en la historia clínica.

›rabbitmqctl list_queues -p clinico name messages_ready messages_unacknowledged consumersname                 messages_ready  messages_unacknowledged  consumerslab.resultados.hce   1842            0                        0adt.eventos.hce      0               0                        1lab.resultados.dlq   0               0                        0

1.842 resultados esperando y ningún consumidor. Los mensajes están a salvo en la cola: nada se ha perdido todavía.

1. Avisa a los equipos clínicos primero (apartado 6). Ahora mismo hay pacientes cuyos resultados no se ven.
2. Por qué se paró el consumidor: el servidor del servicio de integración se reinició a las 10:02 en la ventana de parches y el servicio no arrancó. La interfaz de gestión lo confirma: la cola empezó a crecer a las 10:02.
3. Antes de arrancarlo: comprueba que la historia clínica acepta mensajes (su servicio de entrada responde) y avisa a su equipo de que va a llegar un volumen alto. El prefetch bajo hace que el consumidor procese a un ritmo que la historia clínica aguanta.
4. Arranca el consumidor y mira cómo baja la cola: Ready disminuye, Unacked se mantiene en torno al prefetch y la tasa de ack es constante.
5. Comprueba duplicados. Si el consumidor se cortó con mensajes sin confirmar, RabbitMQ los devuelve a la cola marcados como redelivered y se entregan otra vez. El consumidor debe ser idempotente: descartar un mensaje cuyo identificador de control HL7 (MSH-10) ya procesó.
6. Concilia: número de resultados que el laboratorio envió entre las 10:02 y el final de la recuperación frente a los recibidos en la historia clínica, y dead-letter vacía o revisada.
7. Cierra con los equipos clínicos y deja anotado: hora de inicio, de detección y de fin, número de mensajes retrasados, causa y acción. La acción obvia: el servicio en arranque automático y la alarma de consumidores = 0, que tenía que haber saltado a las 10:03 y no a las 10:35 por una llamada.

Lo que no se hace para "desatascar":

• Purgar la cola: borra resultados clínicos sin vuelta atrás.
• Borrar y recrear la cola, o reiniciar el nodo de RabbitMQ: no arregla un consumidor parado y arriesga lo que hay dentro.

6. Comunicar con los equipos clínicos

Lo que necesitan saber, en su idioma y no en el de la cola:

• Qué está afectado: "los resultados de laboratorio validados desde las 10:02 no se están volcando en la historia clínica". Qué no lo está: imagen, prescripción, admisiones.
• Que no se han perdido: están guardados y llegarán con su hora original de validación.
• Qué hacer mientras tanto: consultar el visor del laboratorio y seguir el procedimiento de contingencia para los valores críticos, que el laboratorio comunica por teléfono.
• Cuándo es la próxima actualización, aunque no haya novedades. No prometas una hora de solución que no controlas.
• Al cerrar: "todos los resultados están ya en la historia clínica; los validados entre las 10:02 y las 11:10 llegaron con retraso". Si algún servicio debe revisar resultados de esa franja, que lo sepa ahora.

Siguientes pasos

• La guía de Monitorización de este sector cubre cómo desplegar alarmas que lleguen a alguien y cómo responder a ellas.
• La guía de Windows Server: actualizaciones planificadas sin cortar el servicio encaja con la causa del ticket: qué comprobar después de reiniciar un servidor que da servicio a otros.
• Para coordinar un incidente con impacto clínico (roles, cronología, comunicaciones y revisión posterior), el repositorio 36-major-incident-command-kit de mi GitHub sigue esa idea.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.