Detectando erros invisíveis: como construí um agente de detecção de duplicados para o programa de HIV do Quênia

Construí um sistema multiagente no Elasticsearch 8.11 (Serverless) usando o Elastic Agent Builder com Claude Sonnet 3.7 como modelo de raciocínio. Em vez de um agente monolítico tentando fazer tudo, divido o trabalho em três agentes — o agente de detecção, o avaliador de risco e o recomendador de ações. Cada um tem um escopo restrito, entradas específicas e um formato de saída definido.

O agente de detecção executa consultas ES|QL no índice de pacientes, procurando duplicatas por três perspectivas: correspondência de padrões entre unidades (o mesmo paciente aparecendo em várias unidades), análise demográfica (p. ex, variações de nome, identificadores de sexo inconsistentes e correspondências parciais de ID) e detecção de anomalias temporais (testes no mesmo dia em unidades distantes). Esta é a camada de busca. Ela mostra candidatos; não faz julgamentos.

O avaliador de risco seleciona esses candidatos e os classifica de 0–100 usando sinais ponderados:

• Visitas entre unidades: até 40 pontos
• Inconsistências demográficas: até 30 pontos
• Impossibilidades geográficas: Até 20 pontos
• Anomalias de tempo: até 10 pontos

Os casos ficam em um dos quatro níveis: CRÍTICO, ALTO, MÉDIO ou BAIXO. Vou explicar por que não usei classificação binária em breve.

O agente de recomendação de ações traduz as pontuações em etapas específicas, calibradas para o contexto do sistema de saúde queniano: revisão imediata pelo responsável pelo M&A para casos CRÍTICOS, sinalização para a próxima visita à unidade de saúde em casos MÉDIOS e recomendações de treinamento para a equipe em unidades que apresentem padrões sistêmicos. Esse agente existe porque uma pontuação de risco isoladamente não é útil para um profissional de saúde. Ele precisa saber o que fazer com ela.

No início da implementação, tentei uma abordagem mais simples: duplicar ou não duplicar. Não sobreviveu ao contato com dados reais.

O problema é que os testes de acompanhamento legítimos se assemelham muito à duplicação. Um paciente em TARV deve comparecer ao mesmo local de atendimento a cada poucos meses. Um bebê deve ser testado repetidamente. A classificação binária ou sinaliza muitas visitas legítimas (e os profissionais de saúde aprendem a ignorar todos os alertas) ou deixa passar os casos sutis em que alguém faz o teste em dois locais diferentes no mesmo dia, usando nomes ligeiramente diferentes.

A abordagem em níveis permite que os profissionais de saúde priorizem. Um caso CRÍTICO com pontuação de risco 87 (teste no mesmo dia, unidades de saúde diferentes e identificadores sexuais inconsistentes) recebe atenção imediata. Um caso BAIXO com pontuação de 22 (mesma clínica e intervalo esperado de acompanhamento) é registrado. O oficial de M&E toma a decisão final, mas trabalha com base em evidências em vez de instinto.

Calibrar os pesos levou muitas iterações em relação a dados reais. Ainda não tenho total certeza de que são ideais. Mas a estrutura está correta, e os pesos podem ser ajustados conforme coletamos mais dados de campo.

Dediquei mais tempo inicial ao design do índice do que a qualquer outra parte do sistema, e foi o melhor investimento que fiz.

Os mapeamentos do índice incluem campos derivados calculados no momento da indexação: cross_facility_flag, total_tests e facility_count por paciente. Os principais campos demográficos têm palavra-chave (correspondência exata) e texto (analisado, busca difusa), então o agente de detecção pode alternar entre correspondência estrita e difusa, dependendo do sinal que está buscando — correspondência estrita para IDs de amostras e correspondência difusa para nomes de pacientes, onde "Wanjiku" e "Wanjiku Mary" podem ser a mesma pessoa.

Também me apoiei bastante nas agregações do Elasticsearch para pré-filtragem de candidatos. O sistema agrupa registros por unidade de saúde, tipo de teste e intervalo de datas antes de executar comparações par a par. É isso que torna a detecção viável em conjuntos de dados maiores. Você não precisa comparar cada registro com todos os outros se puder restringir o espaço de candidatos primeiro.

A ES|QL era nova para mim. Aprendi durante o hackathon, e é impressionante para análises em tempo real em larga escala. A arquitetura que funcionou melhor para mim foi combinar o ES|QL para detecção e agregações de padrões, com Python cuidando da lógica da aplicação. Considerando que eu era novo nisso, essa separação tornou mais fácil raciocinar sobre todo o meu sistema.

Testei o sistema em 1.010 registros reais de pacientes anônimos de 59 unidades de saúde do Quênia. A varredura foi concluída em menos de 10 segundos.

Ele identificou 131 pacientes duplicados, incluindo cinco casos de testes em múltiplas unidades de saúde no mesmo dia e quatro pacientes com identificadores de sexo intencionalmente inconsistentes entre elas.

Os casos detectados no mesmo dia foram os que mais me surpreenderam. Uma revisão manual acabaria por identificar nomes duplicados, se alguém tivesse paciência suficiente. Mas detectar que um paciente fez o teste em dois locais diferentes no mesmo dia, geograficamente distantes e com perfis demográficos ligeiramente distintos, é o tipo de padrão que permanece invisível nos dados até que se procure especificamente por ele. Os responsáveis pelo monitoramento e avaliação me disseram que esses casos levariam semanas para serem identificados manualmente, se é que seriam identificados.

Os primeiros protótipos retornaram uma pontuação de risco e uma recomendação. Eu os mostrei aos oficiais de M&E, mas eles não confiaram na saída.

Não se tratava de uma falha técnica; as pontuações estavam corretas. Mas um profissional de saúde que analisa um paciente sinalizado precisa entender o motivo da sinalização antes de tomar qualquer providência. Seria uma divergência no nome? A impossibilidade geográfica? O momento da consulta? Sem esse contexto, o sistema se torna uma caixa-preta, e caixas-pretas são ignoradas em ambientes clínicos onde o tratamento do paciente está em jogo.

O que transformou o protótipo em algo que as pessoas realmente usariam foi a criação de um sistema de recomendação de ações que gerasse explicações específicas e baseadas em evidências. O responsável pelo monitoramento e avaliação a quem mostrei a demonstração em Nairóbi disse: "Isso teria me poupado três dias no mês passado."

Essa lição não é específica para a área da saúde. Se as recomendações do seu sistema de IA exigirem que um humano aja, a explicação é tanto o produto quanto a recomendação.

Cada agente foi construído no Elastic Agent Builder com instruções personalizadas definindo sua expertise no domínio, etapas de raciocínio e formato de saída. Subestimei o quanto a qualidade dessas instruções importaria.

Versões iniciais com instruções vagas produziam saídas inconsistentes. O agente de detecção às vezes explicava seu raciocínio e às vezes não. O avaliador de risco ocasionalmente pulava um fator de pontuação. Obter saídas confiáveis e baseadas em evidências exigia ser específico sobre os campos de evidência obrigatórios e explícito sobre a cadeia de raciocínio que o agente deveria seguir. Trate instruções personalizadas como código: seja preciso, teste casos extremos e itere.

Esta não é uma demonstração de hackathon que será arquivada. O plano está sendo testado em cinco unidades de saúde do Condado de Nairóbi nos próximos 2–3 meses, treinando oficiais de Monitoramento e Avaliação e coletando dados de desempenho do mundo real para refinar os pesos de risco.

Depois disso, o roadmap inclui a integração da correspondência biométrica e a correspondência difusa do nome fonético suaíli, que é uma lacuna real nas abordagens atuais ("Wanjiku" versus "Wanjiku" é fácil. "Njeri" versus "Njery" requer consciência fonética que a correspondência fuzzy padrão não consegue lidar bem). Por fim, quero que o sistema seja executado em tempo real durante o registro de pacientes no HMIS, capturando duplicatas antes que elas entrem no sistema, e não depois.

A longo prazo, quero me conectar com a Rede de Intercâmbio de Informações de Saúde do Quênia e expandi-la para todos os 47 condados. O redimensionamento horizontal do Elasticsearch e o design modular do agente significam que o sistema central não precisa de uma reconstrução; só precisa de extensões. O impacto projetado em escala nacional: US$ 195.000 em economia anual e uma redução de 70% nos testes duplicados. Mais importante ainda, os profissionais podem confiar nos registros que analisam ao tomar decisões de tratamento.

Se você trabalha em uma área onde a qualidade dos dados é um problema silencioso, caro e que exige muita mão de obra, o Elastic Agent Builder permite que você crie algo que explique o problema em vez de apenas consultá-lo, com ferramentas como ES|QL para detecção de padrões, orquestração multiagente para análise em camadas e instruções personalizadas para raciocínio específico do domínio. A implementação foi mais rápida do que eu esperava.

A parte mais satisfatória desta implementação não foi a colocação. Foi ver alguém que faz este trabalho todos os dias reconhecer em cerca de dez segundos que a ferramenta entendeu o problema deles.