EveryQuery: Zero-Shot Clinical Prediction via Task-Conditioned Pretraining over Electronic Health Records

Die Studie stellt EveryQuery vor, ein auf elektronischen Gesundheitsakten vortrainiertes Modell, das durch task-konditioniertes Pretraining klinische Vorhersagen in Null-Shot-Szenarien effizienter und genauer als autoregressive Baseline-Modelle trifft, indem es Patientenhistorie und strukturierte Abfragen direkt in eine Wahrscheinlichkeitsvorhersage umwandelt.

Das Wesentliche

🏥 EveryQuery: Der medizinische „Wissens-Allrounder"

Stell dir vor, du hast einen riesigen, unendlichen Bibliothekskeller voller Patientengeschichten (das sind die elektronischen Gesundheitsakten, kurz EHR). Früher waren die Computerprogramme, die diese Geschichten lasen, wie schlaue, aber sehr langsame Detektive.

Das alte Problem: Der Detektiv, der alles nachstellen muss

Bisherige KI-Modelle (die sogenannten „autoregressiven Modelle") funktionierten wie ein Detektiv, der versucht, die Zukunft vorherzusagen, indem er tausende von möglichen Zukünften simuliert.

• Die Metapher: Stell dir vor, du willst wissen, ob ein Patient in den nächsten 30 Tagen wieder ins Krankenhaus kommt. Der alte Detektiv nimmt einen Patienten, spielt dann 20 verschiedene Szenarien durch: „Was wäre, wenn er heute ein Medikament nimmt? Was, wenn er morgen Fieber bekommt? Was, wenn er gar nichts tut?"
• Er macht das für jeden Patienten 20 Mal, zählt dann, wie oft in diesen 20 Spielen die Wiederaufnahme passiert ist, und gibt dir eine grobe Schätzung ab.
• Das Problem: Das ist extrem langsam (wie 20 Filme pro Patient anzusehen), sehr ungenau (bei seltenen Krankheiten sieht er in den 20 Spielen vielleicht gar nichts, also sagt er „0 %", obwohl es doch passieren könnte) und man kann ihm nicht einfach eine spezifische Frage stellen, ohne den ganzen Prozess neu zu programmieren.

Die neue Lösung: EveryQuery – Der „Frage-Antwort-Meister"

Die Forscher von Harvard und Columbia haben mit EveryQuery einen neuen Ansatz entwickelt. Statt die Zukunft zu simulieren, lernt dieses Modell, direkt auf eine spezifische Frage zu antworten.

• Die Metapher: Stell dir EveryQuery wie einen super-schnellen Bibliothekar vor, der nicht die Zukunft nachspielt, sondern sofort weiß, wo im Buch die Antwort steht.
• Du gibst ihm zwei Dinge:
  1. Die Patientengeschichte (das Buch).
  2. Eine klare Frage (den Suchbegriff). Zum Beispiel: „Tritt in den nächsten 30 Tagen ein Herzinfarkt auf?"
• Der Bibliothekar schaut sich das Buch an, liest die Frage und gibt dir sofort eine Wahrscheinlichkeit aus. Kein Nachspielen, kein Zählen von Szenarien. Ein einziger Blick reicht.

Warum ist das so genial? (Die drei Vorteile)

1. Sofortige Antworten (Zero-Shot):
   Du musst dem System nicht erst beibringen, wie man Herzinfarkte vorhersagt, und dann wie man Diabetes vorhersagt. Du gibst ihm einfach die Frage für das Herzinfarkt, und er antwortet sofort. Er ist ein „Allrounder", der jede Frage im Vorfeld gelernt hat.

2. Blitzschnell (Effizienz):
   Während der alte Detektiv 20 Filme pro Patient braucht, braucht EveryQuery nur einen einzigen Blick. Das ist 3.000-mal schneller. Stell dir vor, du müsstest 20 Filme schauen, um zu wissen, ob es morgen regnet, oder du würdest einfach nur auf den Himmel schauen. EveryQuery schaut nur auf den Himmel.

3. Perfekt für seltene Ereignisse:
   Das ist der wichtigste Punkt. Bei sehr seltenen Krankheiten (z. B. eine seltene Allergie) passiert es dem alten Detektiv oft, dass er in seinen 20 simulierten Szenarien niemals einen Fall sieht. Er sagt dann: „Keine Chance!" – obwohl es doch eine kleine Chance gibt.
   EveryQuery hingegen schaut sich die Zeichen im Patienten an, die auf diese seltene Krankheit hindeuten, egal wie selten sie ist. Er wird nicht durch die Seltenheit der Krankheit verwirrt.

Wo stößt das Modell an seine Grenzen?

Nichts ist perfekt. EveryQuery ist wie ein sehr präziser Frage-Antwort-Maschine, aber sie versteht nur einfache Fragen.

• Das Problem: Wenn du fragst: „Kommt der Patient wieder, weil er entweder einen Sturz oder eine Lungenentzündung oder einen Herzinfarkt hatte?" (Das nennt man eine „disjunktive" Frage).
• Die Metapher: EveryQuery kann nur nach einem Wort im Buch suchen. Um die Frage mit „oder" zu beantworten, müsste man ihn 70 Mal hintereinander fragen (einmal für Sturz, einmal für Lungenentzündung, usw.) und dann die Ergebnisse mühsam zusammenrechnen. Das funktioniert nicht gut.
• Der alte Detektiv hingegen, der die ganze Zukunft nachspielt, sieht automatisch, wenn irgendetwas davon passiert.

Fazit

EveryQuery ist ein großer Schritt vorwärts für die medizinische KI. Es verwandelt die langsame, mühsame Simulation der Zukunft in eine schnelle, direkte Frage-Antwort-Maschine.

• Bisher: „Lass uns 20 Szenarien durchspielen und hoffen, dass wir etwas finden." (Langsam, ungenau bei seltenen Dingen).
• Jetzt: „Hier ist die Frage, hier ist der Patient. Hier ist die Antwort." (Schnell, präzise, auch bei seltenen Dingen).

Es ist wie der Unterschied zwischen einem Menschen, der versucht, das Wetter vorherzusagen, indem er 20 verschiedene Wetterkarten zeichnet, und einem modernen Wetter-App, die sofort sagt: „Es wird regnen", weil sie die aktuellen Daten direkt analysiert.

Die Zukunft: Die Forscher wollen die Sprache von EveryQuery bald erweitern, damit er auch komplexe „Entweder-oder"-Fragen verstehen kann, ohne dabei seine Geschwindigkeit zu verlieren.

Technische Zusammenfassung

1. Problemstellung und Motivation

Derzeitige Foundation-Modelle für elektronische Gesundheitsakten (EHR) basieren überwiegend auf autoregressiven Ansätzen (ähnlich wie Large Language Models). Diese Modelle tokenisieren Patientenhistorien und trainieren Transformer, um zukünftige medizinische Ereignisse vorherzusagen. Um Vorhersagen zu treffen, generieren sie synthetische Zukunftspfade (Trajektorien) und aggregieren Statistiken über viele dieser Stichproben.

Dieser Ansatz weist jedoch drei wesentliche Nachteile auf:

1. Rechenineffizienz: Die Inferenz ist extrem teuer, da für jede Vorhersage viele Zukunftspfade (z. B. 20 Trajektorien pro Patient) generiert und aggregiert werden müssen.
2. Statistisches Rauschen: Die Vorhersagen sind hochvarianzbehaftet, insbesondere bei seltenen Ereignissen. Da die Wahrscheinlichkeit durch Zählen von Ereignissen in den generierten Pfaden geschätzt wird, führen seltene Ereignisse oft zu stark quantisierten oder null-Wahrscheinlichkeiten.
3. Fehlende Promptbarkeit: Benutzer können die Vorhersagen nicht direkt auf spezifische klinische Fragen konditionieren, ohne komplexe Aggregationsverfahren zu definieren oder die Inferenzpipeline neu zu gestalten.

Es fehlt ein Modell, das Zero-Shot-Inferenz (Aufgaben ohne Feinabstimmung), Effizienz (ein einziger Vorwärtsdurchlauf) und Promptbarkeit (Strukturierte Abfragen) gleichzeitig bietet.

2. Methodik: EveryQuery

EveryQuery ist ein EHR-Foundation-Modell, das diese Lücke schließt, indem es task-konditioniertes Pretraining verwendet. Anstatt zukünftige Ereignisse zu generieren, lernt das Modell, die Wahrscheinlichkeit eines spezifischen Ergebnisses direkt basierend auf einer strukturierten Abfrage zu schätzen.

Kernkonzept

Das Modell nimmt zwei Eingaben entgegen:

1. Die medizinische Historie des Patienten ($x$).
2. Eine strukturierte Query ($q$), die die klinische Aufgabe definiert.

Die Query wird als Parameterpaar $q = (c, \Delta t)$ formuliert, wobei $c$ ein medizinischer Code (z. B. eine Diagnose oder ein Medikament) und $\Delta t$ ein Zeitfenster ist. Die Aufgabe lautet: „Tritt der Code $c$ innerhalb von $\Delta t$ nach dem letzten Ereignis auf?"

Architektur

• Backbone: Ein bidirektionaler Transformer (basierend auf ModernBERT-base) mit 22 Schichten und ca. 149 Millionen Parametern.
• Query-Prepending: Der Query-Code wird in ein Token eingebettet und dem Patienten-Code-Sequence vorangestellt: $[q; x_1, ..., x_L]$.
• Cross-Attention: Durch die bidirektionale Verarbeitung kann das Query-Token auf den gesamten Patientenkontext achten und umgekehrt. Dies ermöglicht eine direkte Konditionierung der Repräsentation auf die Aufgabe.
• Ausgabeköpfe: Das Modell nutzt zwei separate MLP-Köpfe, die auf dem versteckten Zustand des Query-Tokens basieren:
  1. $\hat{y}_{occurs}$: Wahrscheinlichkeit, dass das Ereignis eintritt.
  2. $\hat{y}_{cens}$: Wahrscheinlichkeit, dass die Daten zensiert sind (d. h., das Zeitfenster wurde nicht vollständig beobachtet).

Training (Pretraining)

• Datengrundlage: MIMIC-IV-Datensatz, formatiert nach MEDS (Medical Event Data Standard).
• Query-Erstellung: Queries werden zufällig aus einem Pool von 10.000 Codes gezogen (aus insgesamt 11.467 Codes). Codes, die nicht als Query-Ziele dienen, erscheinen dennoch in den Patientenhistorien, um Generalisierung zu ermöglichen.
• Verlustfunktion: Ein Multi-Task-Objective kombiniert den Verlust für die Zensierung (Binary Cross-Entropy) und den Verlust für das Ereignis (nur für nicht-zensierte Daten).
• Inferenz: Der Benutzer gibt die Query-Parameter ein. Das Modell führt einen einzigen deterministischen Vorwärtsdurchlauf durch, um die Wahrscheinlichkeit zu schätzen. Es gibt keine Trajektorien-Generierung und kein Fine-Tuning.

3. Wichtige Beiträge und Ergebnisse

Die Evaluation erfolgte auf dem MIMIC-IV-Datensatz mit 39 zufällig ausgewählten Vorhersageaufgaben (inkl. Labordaten, Diagnosen, Medikamenten) und einem Baseline-Modell (MEDS-EIC-AR, autoregressiv).

Hauptergebnisse

1. Überlegene Zero-Shot-Leistung: EveryQuery übertraf den autoregressiven Baseline in 82 % der 39 Aufgaben (p < 10⁻⁵). Die durchschnittliche Verbesserung des AUC (Area Under the Curve) betrug +0,16 (95 % CI: [0,10, 0,22]).
2. Generalisierung auf ungesehene Codes (OOD): Das Modell generalisierte nahtlos auf Codes, die während des Trainings nicht als Query-Ziele dienten (Out-of-Distribution). Die Leistungseinbußen waren vernachlässigbar (94 % der OOD-Aufgaben wurden gewonnen).
3. Vorteil bei seltenen Ereignissen: Dies ist der signifikanteste Befund. Es bestand eine starke negative Korrelation zwischen der Häufigkeit eines Ereignisses und dem Leistungsvorteil von EveryQuery ($\rho = -0,32$).
   • Der autoregressive Baseline bricht bei seltenen Ereignissen zusammen, da diese in den wenigen generierten Trajektorien oft gar nicht vorkommen (hohe Varianz).
   • EveryQuery bleibt bei seltenen Ereignissen stabil, da es direkt auf die Evidenz im Patientenverlauf achtet, unabhängig von der Populationshäufigkeit.
4. Rechenleistung: EveryQuery ist für eine einzelne Aufgabe etwa 3.000-mal schneller als der Baseline (ein Vorwärtsdurchlauf vs. 20 Trajektorien-Generierungen).
5. Prompt-Spezifität der Repräsentationen: Embedding-Analysen zeigten, dass die internen Repräsentationen von EveryQuery primär nach Query und nicht nach Patient gruppiert sind. Dies bestätigt, dass die Query die Darstellung selbst modifiziert (Cross-Attention), anstatt nur als nachträglicher Selektor zu dienen.

Limitierungen

• Ausdrucksstärke der Query-Sprache: Das Modell ist auf einzelne Codes beschränkt. Aufgaben, die eine disjunktive Logik erfordern (z. B. „Wiederaufnahme innerhalb von 30 Tagen", was bedeutet: irgendeiner von 70 möglichen Aufnahmecodes), können nicht direkt abgefragt werden.
• Readmission-Test: Bei der Vorhersage von Wiederaufnahmen (Readmission) musste EveryQuery alle 70 Codes einzeln abfragen und die Ergebnisse aggregieren (Maximum oder Unabhängigkeitsannahme). Dies führte zu einem AUC von ~0,56, während der autoregressive Baseline (der ganze Trajektorien generiert) ~0,64 erreichte. Dies zeigt eine Grenze der aktuellen Query-Sprache bei komplexen, zusammengesetzten Aufgaben.

4. Bedeutung und Fazit

EveryQuery demonstriert, dass task-konditioniertes Pretraining eine leistungsfähige Alternative zur autoregressiven Generierung für klinische Vorhersagen ist.

• Paradigmenwechsel: Statt „Pretrain once, generate many" (einmal trainieren, viele Pfade generieren) nutzt EveryQuery „Pretrain once, query directly" (einmal trainieren, direkt abfragen).
• Klinische Relevanz: Die Fähigkeit, seltene Ereignisse präzise vorherzusagen und dies rechen-effizient zu tun, macht das Modell für den klinischen Einsatz in Echtzeit vielversprechender als bisherige autoregressive Modelle.
• Zukunftsausblick: Die größte Herausforderung liegt in der Erweiterung der Query-Sprache, um logische Operatoren (UND, ODER, NICHT) und numerische Prädikate zu unterstützen, um komplexe klinische Szenarien wie Wiederaufnahmen oder Kombinationen von Ereignissen direkt abdecken zu können.

Zusammenfassend bietet EveryQuery einen Weg zu skalierbaren, promptierbaren und effizienten klinischen Vorhersagemodellen, die die fundamentalen Limitierungen der Trajektorien-basierten Inferenz überwinden.