Unsichtbare Fehler aufspüren: So entwickelte ich einen Duplikaterkennungsagenten für Kenias HIV-Programm

Ich habe mit Elastic Agent Builder und Claude Sonnet 3.7 als Reasoning-Modell ein Multi-Agent-System auf Elasticsearch 8.11 (Serverless) aufgebaut. Anstatt eines monolithischen Agenten, der versucht, alles zu erledigen, habe ich die Arbeit in drei Agenten aufgeteilt – den Erkennungsagenten, den Risikobewerter und den Handlungsempfehler. Jede hat einen engen Umfang, spezifische Eingänge und ein definiertes Ausgangsformat.

Der Erkennungsagent führt ES|QL-Abfragen im Patientenindex durch und sucht dabei mithilfe dreier Kriterien nach Duplikaten: standortübergreifender Mustervergleich (derselbe Patient erscheint in mehreren Einrichtungen), demografische Analyse (z. B. Namensvarianten, inkonsistente Geschlechtsangaben und teilweise übereinstimmende Patienten-IDs) und Erkennung zeitlicher Anomalien (Tests am selben Tag in weit voneinander entfernten Einrichtungen). Dies ist die Suchebene: Sie liefert Kandidaten, trifft aber keine Werturteile.

Der Risikobewerter nimmt diese Kandidaten und bewertet sie anhand gewichteter Signale auf einer Skala von 0 bis 100:

• Besuche in verschiedenen Einrichtungen: Bis zu 40 Punkte
• Demografische Inkonsistenzen: Bis zu 30 Punkte
• Geografische Unmöglichkeiten: Bis zu 20 Punkte
• Zeitliche Anomalien: Bis zu 10 Punkte

Tickets landen in einer von vier Stufen: KRITISCH, HOCH, MITTEL oder NIEDRIG. Ich werde gleich erklären, warum ich keine binäre Klassifizierung verwendet habe.

Der Handlungsempfehler übersetzt die Scores in spezifische nächste Schritte, die auf das kenianische Gesundheitswesen abgestimmt sind: sofortige Überprüfung durch den M&E-Beauftragten in Fällen der Stufe KRITISCH, Kennzeichnung für den nächsten Besuch in der Einrichtung bei MITTEL und Empfehlungen für die Schulung des Personals in Einrichtungen, die systemische Muster aufweisen. Diesen Agenten gibt es, weil ein Risiko-Score allein für das Gesundheitspersonal nicht hilfreich ist: Sie müssen wissen, was sie damit anfangen sollen.

Zu Beginn des Build-Prozesses habe ich einen einfacheren Ansatz versucht: Duplikat oder Nicht-Duplikat. Er hat den Kontakt mit echten Daten nicht überlebt.

Das Problem ist, dass legitime Nachuntersuchungen einer Doppeluntersuchung ähneln. Ein Patient, der ART nimmt, sollte alle paar Monate in derselben Einrichtung vorstellig werden. Ein Säugling sollte wiederholt getestet werden. Die binäre Klassifizierung zeigt entweder zu viele legitime Besuche an (und das Gesundheitspersonal lernt, alle Markierungen zu ignorieren) oder übersieht die subtilen Fälle, in denen jemand am selben Tag in zwei verschiedenen Einrichtungen unter leicht unterschiedlichen Namen getestet wird.

Der gestaffelte Ansatz ermöglicht es den Mitarbeitern im Gesundheitswesen, Prioritäten zu setzen. Ein Fall der Stufe KRITISCH mit einem Risikowert von 87 (Tests am gleichen Tag, verschiedene Einrichtungen und inkonsistente Geschlechtsidentifikatoren) erhält sofortige Aufmerksamkeit. Ein Fall der Stufe NIEDRIG mit einem Score von 22 (gleiche Einrichtung und erwartetes Follow-up-Intervall) wird eingereicht. Der M&E-Beauftragte trifft die endgültige Entscheidung, aber er arbeitet auf der Grundlage von Beweisen anstatt von Bauchgefühl.

Die Kalibrierung der Gewichte erforderte viele Iterationen mit echten Daten. Ich bin immer noch nicht ganz sicher, ob sie optimal sind. Aber die Struktur stimmt und die Gewichte können angepasst werden, wenn wir mehr Felddaten sammeln.

Ich habe mehr Zeit im Voraus in das Indexdesign investiert als in irgendeinen anderen Teil des Systems, und es war die beste Investition, die ich gemacht habe.

Die Index-Mappings enthalten abgeleitete Felder, die zum Zeitpunkt der Indexerstellung berechnet werden: cross_facility_flag, total_tests und facility_count pro Patient. Demografische Schlüsselfeld haben sowohl ein Feld für keyword (exakte Übereinstimmung) als auch eines für text (analysiert, Fuzzy-Suche), sodass der Erkennung-Agent je nach dem Signal, dem er nachgeht, zwischen striktem und unscharfem Abgleich wechseln kann – strikter Abgleich für Proben-IDs und unscharfer Abgleich für Patientennamen, bei denen „Wanjiku“ und „Wanjiku Mary“ dieselbe Person sein könnten.

Ich habe mich außerdem stark auf Elasticsearch-Aggregationen für die Vorfilterung von Kandidaten gestützt. Das System ordnet Einträge nach Einrichtung, Testtyp und Datumsbereich, bevor paarweise Vergleiche durchgeführt werden. Dies sorgt dafür, dass die Erkennung bei größeren Datensätzen handhabbar bleibt. Sie müssen nicht jeden Datensatz mit jedem anderen vergleichen, wenn Sie den Kandidatenraum zuerst eingrenzen können.

ES|QL war neu für mich. Ich habe es während des Hackathons gelernt, und es ist beeindruckend für Echtzeit-Analysen im großen Maßstab. Die Architektur, die für mich am besten funktionierte, war das Pairing von ES|QL für Mustererkennung und Aggregationen, wobei Python die Anwendungslogik übernimmt. Da ich damit noch nicht vertraut war, erleichterte mir diese Aufteilung das Verständnis meines gesamten Systems.

Ich habe das System an 1.010 echten anonymisierten Patientenakten aus 59 kenianischen Gesundheitseinrichtungen getestet. Der Scan war in weniger als 10 Sekunden abgeschlossen.

Dabei wurden 131 doppelt erfasste Patienten und Patientinnen identifiziert, darunter fünf Fälle von Tests am selben Tag in mehreren Einrichtungen sowie vier Patienten bzw. Patientinnen mit absichtlich inkonsistenten Geschlechtskennzeichen über mehrere Einrichtungen hinweg.

Die Fälle, die noch am selben Tag bearbeitet wurden, haben mich überrascht. Bei einer manuellen Überprüfung würden Namensduplikate irgendwann auffallen, wenn jemand geduldig genug wäre. Aber die Feststellung, dass ein Patient am selben Tag in zwei Einrichtungen getestet wurde, die geografisch weit voneinander entfernt sind und leicht unterschiedliche demografische Merkmale aufweisen, ist die Art von Muster, die in den Daten unsichtbar bleibt, bis man gezielt danach sucht. Die M&E-Beauftragten sagten mir, dass es Wochen gedauert hätte, bis diese Fälle manuell aufgedeckt worden wäre, wenn überhaupt.

Frühe Prototypen lieferten eine Risikobewertung und eine Empfehlung. Ich habe sie den M&E-Beauftragten gezeigt, aber sie trauten dem Ergebnis nicht.

Dies war kein technisches Versagen, die Ergebnisse waren korrekt. Aber ein Mitarbeiter des Gesundheitswesens, der sich einen gekennzeichneten Patienten ansieht, muss verstehen, warum er gekennzeichnet wurde, bevor er handeln kann. Ist es der nicht übereinstimmende Name? Die geografische Unmöglichkeit? Der Zeitpunkt? Ohne diesen Kontext ist das System eine Blackbox, und Blackboxen werden im klinischen Umfeld ignoriert, wenn es um die Behandlung eines Patienten geht.

Den Handlungsempfehler so aufzubauen, dass er spezifische, auf Fakten beruhende Erklärungen entwickelte, machte aus dem Prototyp etwas, das die Leute tatsächlich verwenden würden. Der M&E-Beauftragte, dem ich es in Nairobi vorgeführt habe, sagte: „Das hätte mir im letzten Monat drei Tage erspart.“

Diese Lektion bezieht sich nicht speziell auf das Gesundheitswesen. Wenn die Empfehlungen Ihres KI-Systems einen Menschen zum Handeln auffordern, ist die Erklärung ebenso das Produkt wie die Empfehlung.

Jeder Agent wurde im Elastic Agent Builder mit benutzerdefinierten Anweisungen erstellt, die seine Domänenexpertise, seine Reasoning-Schritte und sein Ausgabeformat definieren. Ich habe unterschätzt, wie wichtig die Qualität dieser Anweisungen sein würde.

Frühe Versionen mit vagen Anweisungen produzierten inkonsistente Ausgaben. Der Erkennungsagent erklärte manchmal seine Vorgehensweise, manchmal jedoch nicht. Der Risikobewerter würde gelegentlich einen Bewertungsfaktor auslassen. Um zuverlässige, evidenzbasierte Ausgänge zu erhalten, war es erforderlich, die erforderlichen Nachweisfelder genau zu beschreiben und die Argumentationskette, der der Agent folgen sollte, explizit anzugeben. Behandeln Sie benutzerdefinierte Anweisungen wie Code: Seien Sie präzise, testen Sie Grenzfälle und iterieren Sie.

Dies ist keine Hackathon-Demo, die archiviert wird. Der Plan wird in den nächsten 2 bis 3 Monaten in fünf Einrichtungen im Bezirk Nairobi erprobt. Dabei werden M&E-Beauftragte geschult und reale Leistungsdaten gesammelt, um die Risikogewichte zu verfeinern.

Danach beinhaltet die Roadmap die Integration des biometrischen Abgleichs und das Fuzzy-Matching von phonetischen Namen auf Suaheli, was eine echte Lücke in den aktuellen Ansätzen darstellt („Wanjiku“ versus „Wanjiku“ ist einfach, aber „Njeri“ versus „Njery“ erfordert phonetisches Bewusstsein, das Standard-Fuzzy-Matching nicht gut bewältigt). Schließlich möchte ich, dass das System während der Patientenregistrierung in HMIS in Echtzeit läuft und Duplikate aufdeckt,bevor sie in das System gelangen, und nicht danach.

Langfristig möchte ich eine Verbindung zum Health Information Exchange in Kenia herstellen und ihn auf alle 47 Landkreise skalieren. Die horizontale Skalierung von Elasticsearch und das modulare Agentendesign bedeuten, dass das Kernsystem nicht neu aufgebaut werden muss, sondern lediglich Erweiterungen benötigt. Die prognostizierten Auswirkungen auf nationaler Ebene: jährliche Einsparungen von 195.000 $ und eine Reduzierung von Doppeluntersuchungen um 70 %. Noch wichtiger ist, dass Ärzte den Einträgen vertrauen können, die sie sich bei Behandlungsentscheidungen ansehen.

Wenn Sie in einem Bereich arbeiten, in dem Datenqualität ein stilles, teures, menschliches Arbeitsproblem ist, ermöglicht Ihnen Elastic Agent Builder, etwas zu erstellen, das das Problem erklärt, anstatt es nur mit Tools wie ES|QL zur Mustererkennung, Multiagenten-Orchestrierung für schichtweise Analyse und benutzerdefinierten Anweisungen für domänenspezifisches Denken abzufragen. Es kam schneller zusammen, als ich erwartet hatte.

Der befriedigendste Teil dieses Builds war nicht die Platzierung. Es war zu beobachten, wie jemand, der diese Arbeit jeden Tag erledigt, in etwa zehn Sekunden erkannte, dass das Tool sein Problem verstanden hat.