Apache Kafka en sistemas hospitalarios: arquitectura de eventos para interoperabilidad clínica en Venezuela

Un hospital mediano en Venezuela suele tener entre 4 y 8 sistemas que necesitan enterarse, en tiempo real, de lo mismo: que un paciente ingresó, que un resultado de laboratorio está listo, que una factura debe emitirse. Cada vez que esa comunicación se resuelve con integraciones punto a punto, cada sistema nuevo multiplica las conexiones que hay que mantener: interfaces específicas, transformaciones de formato, cron jobs y scripts que alguien escribió "rápido" hace años.

Apache Kafka propone invertir el modelo: en lugar de que los sistemas se hablen entre sí, todos escriben y leen eventos de un mismo flujo central. Es una arquitectura que ya usan varias organizaciones de salud como plano de integración para datos HL7 y FHIR entre historia clínica, laboratorio y facturación, según describe Confluent en su documentación sobre interoperabilidad en salud.

Este artículo asume que ya conoces el problema de fondo — lo desarrollamos en detalle en por qué fracasan los proyectos de interoperabilidad en salud. Aquí vamos a la arquitectura concreta: cómo se diseña, qué decisiones importan más en un contexto clínico venezolano, y cuándo Kafka es la herramienta equivocada.

¿Qué problema resuelve Kafka que la integración punto a punto no resuelve?

Con integraciones punto a punto, conectar 5 sistemas requiere hasta 10 conexiones distintas (n×(n-1)/2), cada una con su propio formato, su propio manejo de errores y su propio punto de fallo. Con Kafka, cada sistema se conecta una sola vez al flujo de eventos — publica lo que le corresponde y consume lo que necesita. Pasar de 5 a 8 sistemas no multiplica las conexiones, las mantiene prácticamente constantes.

En el caso de interoperabilidad que implementamos para una red hospitalaria venezolana, este fue exactamente el punto de partida: cada integración nueva entre HIS, LIS y facturación se construía desde cero, con su propio script de sincronización y sus propios bugs de duplicados. Migrar a un flujo de eventos centralizado eliminó esa multiplicación y permitió que futuros sistemas (BI, SAP, nuevos módulos clínicos) se conectaran al mismo plano de eventos sin reescribir nada de lo existente.

¿Cómo se organizan los datos clínicos en topics y particiones?

Cada dominio clínico debe vivir en su propio topic — no un topic único para "todo el hospital". La separación típica que funciona en un entorno con HIS, LIS y facturación:

El contenido de cada mensaje suele codificarse en HL7 v2.x o FHIR (por ejemplo, recursos FHIR Encounter, Observation, MedicationRequest); Kafka se limita a garantizar transporte fiable, orden por clave y desacoplamiento entre productores y consumidores. Esta separación por dominio simplifica el versionamiento de mensajes y la incorporación de nuevos sistemas — un motor de reglas clínicas, por ejemplo, solo necesita suscribirse a resultados-laboratorio y ordenes-medicas, no al flujo completo del hospital.

Dentro de cada topic, las particiones se asignan por una clave con sentido clínico — normalmente el ID del paciente o el ID del encuentro (episodio de atención). Esto garantiza que todos los eventos de un mismo paciente lleguen en el orden en que ocurrieron a cualquier sistema que los consuma, porque Kafka solo garantiza orden dentro de una partición, no entre particiones distintas. Elegir mal la clave puede producir situaciones peligrosas, como un resultado de laboratorio que llega antes que la orden médica que lo originó. En hospitales que trabajan por episodio de atención, usar el ID de encuentro como clave suele ser la opción más robusta, porque agrupa admisión, órdenes, resultados y facturación de un mismo caso clínico.

¿Por qué el replication factor no es negociable en un hospital?

En la mayoría de sistemas de negocio, un replication factor de 2 es aceptable para tolerar la caída de un servidor. En salud, el estándar mínimo debería ser 3, sin excepción: un resultado de laboratorio o una orden médica que se pierde no es un dato de negocio perdido, es una decisión clínica que no llegó a tiempo.

Con replication.factor=3 y min.insync.replicas=2, el clúster tolera la pérdida completa de un nodo sin dejar de aceptar ni de servir datos, y sin arriesgar la durabilidad del evento ya confirmado. Esto tiene un costo real en infraestructura — tres copias de cada evento, tres nodos mínimos en el clúster — que muchas veces se subestima al presupuestar el proyecto. Vale la pena decirlo así de directo en la fase de diagnóstico, antes de comprometer un presupuesto que luego no alcanza para la redundancia mínima.

¿Qué significa "exactly-once" y por qué importa el doble en resultados de laboratorio?

Exactly-once semantics (EOS) garantiza que un evento se procese una sola vez, incluso ante fallos de red o reintentos del productor. Sin esta garantía, el modo por defecto de Kafka es "at-least-once": un evento puede procesarse más de una vez ante un fallo transitorio.

En facturación, un evento duplicado genera un cargo doble — molesto, pero corregible. En resultados de laboratorio, un evento duplicado puede generar una alerta clínica repetida o una interpretación errónea si el sistema consumidor no deduplica por ID de resultado. Kafka resuelve esto con dos mecanismos, según detalla la guía técnica de Conduktor sobre exactly-once semantics:

• Productores idempotentes (enable.idempotence=true, activado por defecto desde Kafka 3.0): cada mensaje lleva un número de secuencia por partición, y Kafka descarta los reintentos duplicados sin volver a escribirlos.
• Productores transaccionales (transactional.id único por instancia): permiten que el patrón read-process-write — leer de un topic, procesar y escribir en otro — sea una operación atómica, todo o nada.

En el lado del consumidor, isolation.level=read_committed asegura que solo se lean mensajes de transacciones confirmadas, descartando escrituras abortadas o en curso. Y en pipelines de streaming (por ejemplo, un módulo de reglas clínicas sobre resultados de laboratorio), processing.guarantee=exactly_once_v2 en Kafka Streams extiende esta garantía a todo el pipeline sin reimplementar deduplicación en cada consumidor.

Esta garantía no es gratis: la coordinación transaccional añade unos milisegundos de latencia y reduce el throughput respecto a "at-least-once". Es un costo aceptable en resultados de laboratorio o facturación; no siempre lo es en flujos de alto volumen y bajo riesgo, como telemetría de equipos.

¿Cómo evitar que cada sistema downstream reprocese todo el historial?

Un error común es que cada nuevo sistema consumidor (un módulo de Business Intelligence que se añade dos años después, por ejemplo) empiece a leer el topic completo desde el principio, generando carga innecesaria y duplicando trabajo ya hecho por otros consumidores. El patrón correcto es usar consumer groups independientes por sistema downstream: cada grupo mantiene su propio offset y avanza a su propio ritmo, sin interferir con los demás ni reprocesar lo que otro sistema ya consumió.

Esto es lo que permite que facturación, el módulo de BI y una futura integración con SAP en hospitales venezolanos — si el hospital llega a ese nivel de complejidad — consuman el mismo flujo de eventos a velocidades distintas, sin que uno bloquee o duplique el trabajo de otro.

¿Cuándo Kafka es la herramienta equivocada?

No todo hospital necesita Kafka. Si la clínica tiene 2-3 sistemas y un volumen bajo de eventos por día, una integración punto a punto bien construida — o incluso una capa de sincronización más simple — resuelve el problema con menos infraestructura que mantener. Kafka empieza a justificarse cuando hay 4 o más sistemas que necesitan enterarse de los mismos eventos en tiempo real, cuando el hospital ya sabe que va a seguir añadiendo sistemas en los próximos años, o cuando hay requerimientos claros de auditoría y trazabilidad sobre los eventos clínicos.

Meter Kafka en una clínica pequeña por moda tecnológica es el mismo error, en sentido inverso, que seguir con integraciones punto a punto en una red hospitalaria grande.

Preguntas frecuentes

¿Apache Kafka reemplaza al motor de interoperabilidad HL7/FHIR?

No. Kafka es el transporte de eventos; HL7/FHIR sigue siendo el estándar para estructurar el contenido clínico de cada mensaje. En la práctica se complementan: el motor de interoperabilidad valida y transforma, Kafka garantiza transporte, orden y resiliencia.

¿Cuánto tarda implementar Kafka en un hospital que ya tiene HIS y LIS funcionando?

Depende del número de integraciones existentes que haya que migrar, pero un piloto con dos sistemas conectados (por ejemplo HIS y LIS) suele ser viable en 4-6 semanas si esos sistemas ya exponen algún mecanismo de exportación de eventos.

¿Necesito un equipo de datos dedicado para mantener un clúster Kafka?

No para un hospital mediano. Un clúster de 3 nodos bien configurado, con monitoreo básico y procedimientos claros de actualización, puede mantenerse dentro de un equipo de TI existente, siempre que alguien tenga experiencia previa en sistemas distribuidos.

¿Qué pasa con la seguridad y la privacidad de los datos clínicos en Kafka?

Kafka se integra con cifrado en tránsito (TLS), autenticación y autorización por topic, y puede coexistir con estrategias de seudonimización de datos clínicos en los mensajes. El diseño concreto debe alinearse con la política de seguridad de información del hospital.

Si tu hospital o clínica ya opera con 3 o más sistemas que hoy se sincronizan a mano o con integraciones frágiles, este es exactamente el tipo de problema que resolvemos en Code by Meléndez — con experiencia directa en el caso real de interoperabilidad de datos de salud que citamos arriba.