Detectar errores ocultos: Cómo cree un agente de detección de duplicados para el programa de VIH de Kenia

Desarrollé un sistema multiagente en Elasticsearch 8.11 (Serverless) usando Elastic Agent Builder con Claude Sonnet 3.7 como modelo de razonamiento. En lugar de un agente monolítico tratando de hacer todo, dividí el trabajo en tres agentes: el agente de detección, el evaluador de riesgos y el recomendador de acciones. Cada uno tiene un ámbito de aplicación limitado, datos de entrada específicos y un formato de salida definido.

El agente de detección ejecuta búsquedas ES|QL en el índice de pacientes y busca duplicados a través de tres lentes: coincidencia de patrones entre centros (mismo paciente que aparece en múltiples centros), análisis demográfico (p. ej., variaciones de nombre, identificadores de sexo inconsistentes y coincidencias parciales de ID) y detección de anomalías temporales (pruebas el mismo día en centros distantes). Esta es la capa de búsqueda: presenta candidatos; no hace juicios.

El evaluador de riesgos toma esos candidatos y los califica de 0 a 100 utilizando señales ponderadas:

• Visitas entre centros: Hasta 40 puntos
• Inconsistencias demográficas: Hasta 30 puntos
• Imposibilidades geográficas: Hasta 20 puntos
• Anomalías de tiempo: Hasta 10 puntos

Los casos se sitúan en uno de cuatro niveles: CRÍTICO, ALTO, MEDIO o BAJO. En un momento explicaré por qué no usé la clasificación binaria.

El recomendador de acciones traduce los puntajes en próximos pasos específicos calibrados para el contexto de atención médica de Kenia: revisión inmediata del oficial M&E para casos CRÍTICOS, marcado para la próxima visita al centro para MEDIO y recomendaciones de capacitación del personal para centros que muestran patrones sistémicos. Este agente existe porque una puntuación de riesgo por sí sola no es útil para un trabajador de salud. Necesitan saber qué hacer con él.

Al principio del desarrollo, intenté un enfoque más simple: duplicado o no duplicado. Pero no funcionó con datos reales.

El problema es que las pruebas de seguimiento válidas se parecen mucho a los duplicados. Se supone que un paciente con tratamiento antirretroviral debe presentarse en el mismo centro cada pocos meses. Un bebé debe hacerse la prueba repetidamente. La clasificación binaria marcará demasiadas visitas válidas (y los trabajadores de la salud aprenden a ignorar todas las marcas) o pasa por alto los casos sutiles en los que alguien realiza pruebas en dos centros diferentes el mismo día con nombres ligeramente diferentes.

El enfoque por niveles permite que el personal de salud priorice. Un caso CRÍTICO con un puntaje de riesgo de 87 (pruebas el mismo día, diferentes centros e identificadores de género inconsistentes) recibe atención inmediata. Un caso de riesgo BAJO con una puntuación de 22 (mismo centro e intervalo de seguimiento esperado) se archiva. El oficial de M&E toma la decisión final, pero se basa en la evidencia y no en la intuición.

Calibrar las ponderaciones requirió muchas iteraciones con datos reales. Todavía no estoy del todo seguro de que sean óptimas. Pero la estructura es la correcta, y las ponderaciones se pueden ajustar a medida que recopilemos más datos de campo.

Dediqué más tiempo inicial al diseño del índice que a cualquier otra parte del sistema, y fue la mejor inversión que hice.

Los mappings del índice incluyen campos derivados que se calculan en el momento de la indexación: cross_facility_flag, total_tests y facility_count por paciente. Los campos demográficos clave tienen subcampos tanto de palabra clave (coincidencia exacta) como de texto (analizado, búsqueda aproximada), así que el agente de detección puede cambiar entre la coincidencia estricta y la aproximada según la señal que esté rastreando: coincidencia estricta para los ID de muestra y coincidencia aproximada para los nombres de pacientes, donde "Wanjiku" y "Wanjiku Mary" podrían ser la misma persona.

También recurrí mucho a las agregaciones de Elasticsearch para el prefiltrado de candidatos. El sistema agrupa registros por centro, tipo de prueba y rango de fechas antes de ejecutar comparaciones por pares. Esto es lo que hace que la detección sea manejable en sets de datos más grandes. No es necesario comparar cada registro con todos los demás si puedes reducir primero el espacio de candidatos.

ES|QL era algo nuevo para mí. Lo aprendí durante el hackathon, y es excelente para análisis en tiempo real a gran escala. La arquitectura que mejor funcionó fue combinar ES|QL para la detección de patrones y las agregaciones con Python para manejar la lógica de la aplicación. Teniendo en cuenta que era nuevo en esto, esta separación me facilitó mucho entender cómo funcionaba todo el sistema.

Probé el sistema en 1010 registros de pacientes reales anonimizados de 59 centros de salud kenianos. El escaneo se completó en menos de 10 segundos.

Identificó 131 pacientes duplicados, incluyendo cinco casos de pruebas en múltiples instalaciones el mismo día y cuatro pacientes con identificadores de sexo intencionalmente inconsistentes entre instalaciones.

Los casos del mismo día son los que más me sorprendieron. Con una revisión manual, al final se acabarían detectando los nombres duplicados si alguien tuviera la paciencia suficiente. Pero darse cuenta de que un paciente se hizo la prueba en dos centros el mismo día, geográficamente distantes y con datos demográficos ligeramente diferentes, es el tipo de patrón que permanece oculto en los datos hasta que lo buscas específicamente. Los responsables de M&E me dijeron que esos casos habrían tardado semanas en salir a la luz de forma manual, si es que se detectaban.

Los primeros prototipos arrojaron un puntaje de riesgo y una recomendación. Se los mostré a los responsables de seguimiento y evaluación, pero no confiaron en los datos de salida.

Esto no fue un fallo técnico; los puntajes eran precisos. Pero un trabajador de la salud que mira a un paciente marcado necesita entender por qué fue marcado antes de que actúe en consecuencia: ¿es la falta de coincidencia de nombres? ¿la imposibilidad geográfica? ¿el momento? Sin ese contexto, el sistema es una caja negra, y las cajas negras son ignoradas en entornos clínicos donde lo que está en juego es el tratamiento de un paciente.

Desarrollar el recomendador de acciones para producir explicaciones específicas, citadas por evidencia, fue lo que convirtió al prototipo en algo que realmente se usaría. El oficial de M&E al que le hice una demostración en Nairobi dijo: «Esto me habría ahorrado tres días el mes pasado».

Esa lección no es exclusiva del sector sanitario. Si las recomendaciones de tu sistema de IA requieren que un humano actúe, la explicación es tanto el producto como la recomendación.

Cada agente se construyó en Elastic Agent Builder con instrucciones personalizadas que definían su experiencia en el dominio, pasos de razonamiento y formato de salida. Subestimé la importancia que tendría la calidad de esas instrucciones.

Las primeras versiones con instrucciones vagas producían datos de salida inconsistentes. El agente de detección a veces explicaba su razonamiento y a veces no. El evaluador de riesgos ocasionalmente omitía un factor de puntaje. Para obtener datos de salida confiables y basados en pruebas, era necesario definir con precisión los campos de información necesarios y explicar claramente la cadena de razonamiento que debía seguir el agente. Trata las instrucciones personalizadas como código: Sé preciso, prueba los casos límite e itera.

Esto no es una demostración de hackathon que se archiva. El plan se pondrá a prueba en cinco centros del condado de Nairobi durante los próximos 2–3 meses, se capacitará a los responsables de M&E y se recopilarán datos de rendimiento en condiciones reales para ajustar las ponderaciones de riesgo.

Después de eso, el roadmap incluye la integración de coincidencia biométrica y la coincidencia aproximada de nombres fonéticos swahili, que es una brecha real en los enfoques actuales (" Wanjiku " versus " Wanjiku " es fácil. "#Njeri" versus "Njery" requiere conciencia fonética de que la coincidencia aproximada estándar no se maneja bien). Eventualmente, quiero que el sistema funcione en tiempo real durante el registro de pacientes en HMIS, y que detecte duplicados antes de que ingresen al sistema y no después.

A más largo plazo, quiero conectarme al Intercambio de Información de Salud de Kenia y escalarlo a los 47 condados. Gracias al escalado horizontal de Elasticsearch y al diseño modular de los agentes, no hace falta volver a desarrollar el sistema núcleo; solo se necesitan extensiones. El impacto proyectado a nivel nacional: $195 000 de ahorro anual y una reducción del 70 % en las pruebas duplicadas. Más importante aún, los médicos pueden confiar en los registros que están viendo al tomar decisiones de tratamiento.

Si trabajas en un dominio donde la calidad de los datos es un problema silencioso, costoso y de trabajo humano, Elastic Agent Builder te permite crear algo que explica el problema, en lugar de simplemente realizar búsquedas, con herramientas como ES|QL para la detección de patrones, la orquestación multiagente para el análisis en niveles y las instrucciones personalizadas para el razonamiento específico del dominio. Esto se concretó más rápido de lo que esperaba.

La parte más satisfactoria de este desarrollo no fue la ubicación. Fue ver a alguien que hace este trabajo todos los días reconocer en solo diez segundos que la herramienta entendió su problema.