FHIR-Agents: KI lernt die Sprache der Krankenhausdaten

Unsere Arbeit „Reinforcement Learning for Tool-Calling Agents in Fast Healthcare Interoperability Resources (FHIR)" wurde auf der ICML 2026 angenommen, einer einflussreichen Konferenz für KI. Wir trainieren darin mit Reinforcement Learning einen Retrieval-Agenten, der klinische Fragen über echte Patientendaten in FHIR-Form beantwortet. Auf dem Benchmark FHIR-AgentBench übertrifft unser kompaktes 8B-Modell deutlich größere kommerzielle Systeme wie o4-mini, Gemini 3 Flash und GLM-5, bei einem Bruchteil der Modellgröße und 100% lokal.

Worum geht es?

Krankenhäuser tauschen Patientendaten zunehmend über einen gemeinsamen Standard aus: FHIR (Fast Healthcare Interoperability Resources). FHIR ist ein etabliertes Format für interoperablen Datenaustausch im Gesundheitswesen, und gleichzeitig eine Datenstruktur, die beim Beantworten klinischer Fragen neue Herausforderungen mit sich bringt.

Der Grund: FHIR ist kein flacher Datensatz, sondern ein gerichteter, typisierter Graph. Ein Patient verweist auf seine Aufenthalte (Encounter), die wiederum auf Beobachtungen (Observation), Diagnosen (Condition) und Medikamentenanforderungen (MedicationRequest) zeigen. Jede dieser Ressourcen kann weitere Verweise enthalten.

Eine einzelne klinisch relevante Frage wie „Welches Medikament wurde dem Patienten bei seinem letzten Aufenthalt zuerst verabreicht?" erfordert daher mehrere Schritte: den richtigen Aufenthalt finden, die verknüpften Medikamentenanforderungen identifizieren, die referenzierte Medikamentenressource auflösen, nach Zeit sortieren. Und das alles, ohne dass das Datenmodell überall gleich aussieht. FHIR standardisiert zwar die Schnittstelle, aber in der Praxis treffen wir auf verschiedene Arten von Heterogenität, darunter:

• Semantische Heterogenität: Dieselbe klinische Information wird in unterschiedlichen Terminologien, Kodierungssystemen oder Einheiten ausgedrückt.
• Strukturelle Heterogenität: Optionale Felder sind unterschiedlich befüllt, lokale Profile fügen eigene Felder hinzu, und derselbe Sachverhalt kann in verschiedenen Ressourcentypen abgebildet sein.

Diese Vielfalt macht jeden FHIR-Server in der Praxis ein Stück weit zu einem Unikat.

Warum kleine, lokale Modelle in der Klinik wichtig sind

Sprachmodelle sind ein vielversprechender Baustein, um klinische Daten zugänglicher zu machen, etwa als Schnittstelle, die Ärztinnen und Ärzten erlaubt, Fragen an die Patientenakte in natürlicher Sprache zu stellen, statt durch verschachtelte FHIR-Strukturen zu navigieren. In vielen Bereichen sind dafür große kommerzielle Modelle (GPT-5, Gemini, Claude) die einfachste Antwort. In der Klinik nicht: Patientendaten dürfen aus Datenschutzgründen oft nicht an externe Cloud-Dienste übertragen werden. Wer LLMs in der Klinik einsetzen möchte, ist deshalb auf lokal betriebene, kleinere Modelle angewiesen, die in der Regel deutlich schwächer abschneiden als ihre großen Konkurrenten.

Unsere Arbeit zeigt, dass dieser Leistungsnachteil nicht zwangsläufig ist, sofern man das Modell auf die Aufgabe spezialisiert.

Was wir gebaut haben

Unser Ansatz besteht aus einem Agenten, der über zwei Werkzeuge mit einem echten FHIR-Server interagiert, und einem Reinforcement-Learning-Verfahren, das ihm beibringt, diese Werkzeuge im richtigen Moment einzusetzen. Trainiert und evaluiert wird auf FHIR-AgentBench (Lee et al., 2025), einem Benchmark mit 2.931 klinisch motivierten Fragen über echte, de-identifizierte Patientenakten aus MIMIC-IV im FHIR-Format.

Zur Verfügung stehen dem Agenten zwei Werkzeuge:

• Ein Retrieval-Tool für die FHIR-Datenbank, das Ressourcen eines bestimmten Typs für einen Patienten lädt.
• Ein Python-Interpreter, der die zurückgegebenen JSON-Daten transformiert: filtern, sortieren, aggregieren, Referenzen auflösen. Python eignet sich hier gut, weil sich genau diese Operationen auf verschachteltem JSON in wenigen Zeilen ausdrücken lassen.

Der Agent arbeitet in einer ReAct-Schleife: in jedem Schritt denkt er kurz nach, ruft eines seiner Werkzeuge auf und liest dessen Rückgabe, bevor er den nächsten Schritt plant. Weil eine der Aktionen ausführbarer Code ist, entspricht das Setup einer CodeAct-Variante von ReAct, also ReAct mit Code als Aktionsformat. Der Agent entscheidet selbst, wann er die Antwort liefern kann oder noch eine weitere Recherchestufe braucht.

Ein automatischer LLM-Judge vergleicht die Antwort mit der Referenzantwort aus FHIR-AgentBench und gibt ein binäres Reward-Signal zurück (richtig/falsch). Aus diesen Signalen lernt das Modell Schritt für Schritt, welche Tool-Aufrufe in welcher Reihenfolge zum Ziel führen.

Abbildung 1: Trainingspipeline. Der Agent beantwortet eine Frage über mehrere Tool-Aufrufe, ein Judge bewertet die Antwort, das Modell lernt aus dem Reward-Signal.

Wichtig: Wir trainieren das Modell nicht auf einem statischen Datensatz vorgegebener Lösungswege. Es lernt durch Interaktion mit dem echten FHIR-Server und entdeckt dabei selbst, wie die Daten in diesem speziellen Server organisiert sind.

Die Ergebnisse

Abbildung 2: Beispiellauf. Der Agent lädt die passenden FHIR-Ressourcen vom Server, analysiert sie mit Python und gibt am Ende die richtige Antwort.

Spezialisierung schlägt Skalierung

Wir vergleichen unseren trainierten 8B-Agenten einerseits mit verschiedenen Qwen3-Größen ohne Spezialisierung (4B, 8B, 14B, 32B) und andererseits mit kommerziellen API-Modellen: o4-mini (OpenAI), Gemini 3 Flash (Google) und GLM-5 (Zhipu, 744B Parameter). Die FHIR-AgentBench-Studie berichtet 50% Genauigkeit mit o4-mini im besten Setup. Unser RL-trainiertes Modell erreicht 77%.

Abbildung 3: Links: Answer Correctness auf FHIR-AgentBench. Unser RL-trainierter Qwen3-8B erreicht 77% und übertrifft damit alle API-Baselines deutlich. Rechts: Genauigkeit nach FHIR-Ressourcentyp über den Trainingsverlauf. Der Agent lernt zuerst, „leere" Fragen korrekt zu beantworten, dann nach und nach die schwierigeren Ressourcentypen; Fragen zu Medikamenten bleiben am Ende die größte Hürde.

Das Modell wird auch effizienter

Eine schöne Nebenwirkung: Nach dem Training braucht der Agent weniger Schritte pro Anfrage. Das untrainierte Qwen3-8B verteilt seine (selteneren) Erfolge über bis zu 12 Tool-Aufrufe; das trainierte Modell beantwortet die meisten Fragen in deutlich unter 6 Schritten. Das senkt Wartezeit und Betriebskosten in der Produktion.

Limitationen und Ausblick

Wir haben die Fehler nach Ressourcentyp aufgeschlüsselt. Die schwierigsten Fragen sind die, bei denen der Agent Referenzen zwischen Ressourcen auflösen muss, typisch das Paar MedicationRequest → Medication. Der Agent beherrscht das Auflösen von Referenzen grundsätzlich, wendet diesen Skill aber noch nicht so zuverlässig an wie die einfacheren Lookup-Schritte. Hier sehen wir den klarsten Hebel für weitere Verbesserungen. Zur Einordnung: 77% Genauigkeit sind ein deutlicher Sprung gegenüber dem Stand der Technik, aber weit unterhalb der Schwelle für autonome klinische Entscheidungen. Unser Agent ist als Werkzeug für medizinisches Fachpersonal gedacht, nicht als dessen Ersatz.

Was bedeutet das für die Praxis?

Wir zeigen einen konkreten Weg, wie Kliniken leistungsfähige KI-Assistenten betreiben können, ohne Patientendaten aus dem Haus zu geben. Das Trainingsverfahren lässt sich an die lokalen Eigenheiten eines beliebigen FHIR-Servers anpassen, ein wichtiger Punkt, weil jede Einrichtung eigene Ausprägungen nutzt.

Wir verstehen unseren Agenten als Brücke zwischen FHIR-Daten und fortschrittlichen medizinischen KI-Anwendungen: Diagnose-Modelle, Risikoprädiktoren oder klinische Assistenten brauchen am Ende immer Zugriff auf die richtigen Patientendaten. Genau diese Brücke wollen wir bauen: spezialisiert, lokal, datenschutzkonform und auf Augenhöhe mit den großen Modellen.

---

Die Arbeit ist gemeinsam mit Robert Müller entstanden und in voller Länge auf arXiv verfügbar. Fragen, Kooperationsideen, Kritik: hallo@idmedizin.de.