Zur Übersicht

8.6.2026

Dr. Jesús Calvillo Tinoco

LLMS im Medizinkontext? t2k erarbeitet FHIR-Benchmark

Im Rahmen der Arbeiten im Projekt FHIR-Starter, einem öffentlichen Forschungsvorhaben von Fraunhofer IESE und Partnern zur LLM-gestützten automatischen Strukturierung medizinischer Daten in interoperable FHIR-Ressourcen, haben wir Large Language Models (LLMs) an einer Reihe praxisnaher FHIR-Aufgaben gemessen.

Was ist FHIR und warum haben wir uns damit beschäftigt?

Das Akronym FHIR bedeutet "Fast Healthcare Interoperability Resources". Es ist ein weit verbreiteter Standard im Gesundheitswesen zur Darstellung und zum Austausch von Informationen wie z. B. Patientendaten, Messergebnissen, Medikamenten, Sprechstundenaufzeichungen und anderen klinischen Datensätzen. Diese Informationen werden mittels FHIR in ein einheitliches Format überführt, damit in einem zweiten Schritt verschiedene Softwaresysteme alle Informationen gleichermaßen und zuverlässig auswerten können. In der Praxis ist FHIR zu einem der wichtigsten Standards für die Strukturierung und den Austausch klinischer Daten geworden, auch in Deutschland, wo FHIR in nationalen Interoperabilitätsinitiativen eingesetzt und gefördert wird.

FHIR-Daten werden häufig als JSON dargestellt: strukturierter Text, der aus Feldern und Werten besteht. Eine FHIR-Ressource kann einen Patienten, ein Messergebnis, eine Medikationsverordnung oder eine andere klinische Entität in einem standardisierten Format beschreiben. Ein sehr kleines Beispiel könnte so aussehen:

{
  "resourceType": "Patient",
  "id": "123",
  "name": [
    {
      "family": "Smith",
      "given": ["John"]
    }
  ],
  "gender": "male",
  "..."
}

Schon dieses einfache Beispiel zeigt, warum das Format wichtig ist. Die Information steht nicht einfach als Freitext da. Sie muss in der richtigen Struktur erscheinen, mit den richtigen Feldnamen und an den richtigen Stellen.

Da LLMs immer leistungsfähiger werden, ist es leicht, sich von flüessigen Antworten und überzeugenden Demos beeindrucken zu lassen. Im Gesundheitswesen ist sprachliche Flüssigkeit jedoch nur der Ausgangspunkt. Entscheidend ist, ob ein LLM nützliche FHIR-bezogene Aufgaben zuverlässig und konsistent ausführen kann. Genau diese Frage stand hinter der Benchmarking-Arbeit, die wir bei t2k in den letzten Monaten durchgeführt haben.

Wir wollten LLMs nicht nur daraufhin bewerten, ob sie über FHIR sprechen köennen, sondern ob sie strukturierte Aufgaben bewältigen können, die realer Arbeit im Gesundheitswesen ähneln. Im größeren Kontext des Projekts FHIR-Starter baut unsere Arbeit auf dem FHIR-Workbench-Framework auf, das von Idrissi-Yaghir et al. in "Using a Diverse Test Suite to Assess Large Language Models on Fast Health Care Interoperability Resources Knowledge: Comparative Analysis" (Journal of Medical Internet Research, 2025) beschrieben wurde, und erweitert es zu einem breiteren, operativeren Benchmarking-Setup, das sowohl providergestützte als auch offene LLMs, eine reichhaltigere Ausgabenauswertung und eine detailliertere Behandlung strukturierter Generierung unterstützt.

An welchen Aufgaben haben wir die LLMs im FHIR-Kontext gemessen?

Auf Aufgabenebene umfasst der Benchmark vier zentrale Evaluierungen aus der FHIR-Workbench:

  • FHIR-QA ist eine Multiple-Choice-Aufgabe zu allgemeinen FHIR-Konzepten, Terminologie, Struktur und Standardverhalten. Ein LLM könnte zum Beispiel gefragt werden: "Wofür steht FHIR?", und sollte dann in der Lage sein, aus einer Reihe möglicher Antworten die richtige auszuwählen.
  • FHIR-RESTQA ist eine Multiple-Choice-Aufgabe zum Verhalten der FHIR-REST-API, einschließlich Operationen, Query-Struktur und Implementierungsdetails. Ein LLM könnte zum Beispiel gefragt werden, welche Ressource und welche Suchanfrage verwendet werden müssen, um Patienten mit einer Hypertonie-Diagnose zu finden.
  • FHIR-ResourceID ist eine Klassifikationsaufgabe, bei der das LLM den korrekten FHIR-Ressourcentyp anhand des Ressourceninhalts identifizieren muss, nachdem das Feld "resourceType" entfernt wurde. Wenn etwa ein JSON-Objekt Felder wie "status", "vaccineCode", "patient" und "occurrenceDateTime" enthält, sollte das LLM erkennen, dass es sich um eine "Immunization" handelt.
  • Note2FHIR ist eine Generierungsaufgabe, bei der das LLM eine klinische Notiz in strukturiertes FHIR-JSON überführen muss. Aus einer kurzen Notiz, die besagt, dass John Smith an Typ-2-Diabetes leidet und Metformin einnimmt, sollte das LLM beispielsweise strukturierte Informationen erzeugen, die den Patienten, die Erkrankung und das Medikament repräsentieren.

FHIR-QA, FHIR-RESTQA und FHIR-ResourceID sind relativ klar abgegrenzte Aufgaben. Sie testen, ob ein LLM FHIR-Konzepte, API-Nutzung und Ressourcenstruktur versteht.

Note2FHIR liegt viel näher an einer echten produktiven Herausforderung. Statt aus vorgegebenen Antworten auszuwählen, muss das LLM eine klinische Notiz lesen und daraus strukturierte FHIR-Ausgaben erzeugen. Das erfordert mehr als reines Erinnern. Das LLM muss die Notiz interpretieren, entscheiden, welche Details relevant sind, sie korrekt organisieren und eine Ausgabe erzeugen, die nicht nur für Menschen plausibel wirkt, sondern auch so gut strukturiert ist, dass sie nachgelagert tatsächlich nutzbar ist.

Zusammengenommen liefern diese Aufgaben ein nützlicheres Gesamtbild, als es eine einzelne Aufgabe allein könnte. Ein LLM kann bei wissensorientierten Aufgaben gut abschneiden und dennoch Schwierigkeiten haben, wenn es eine Ausgabe erzeugen soll, die ein anderes System tatsächlichh weiterverarbeiten kann.

Wie genau haben wir die Leistungsfähigkeit der LLMs gemessen?

Wir haben versucht, die Evaluierung breit, aber praxisnah zu halten. Bei FHIR-QA und FHIR-RESTQA ist die wichtigste Kennzahl die Genauigkeit: Hat das LLM die richtige Antwort gewählt? Bei FHIR-ResourceID verwendet der Benchmark ebenfalls die Korrektheit als zentrales Ergebnis, da die Aufgabe darin besteht, den richtigen Ressourcentyp zu identifizieren.

Bei Note2FHIR muss die Evaluierung weiter gehen. Die wichtigste semantische Kennzahl ist ein FHIR-JSON-Similarity-F1-Score, der die generierten FHIR-Inhalte mit einer Referenzantwort vergleicht, nachdem beide in strukturierte Pfad-Wert-Paare zerlegt wurden. Vereinfacht gesagt zeigt diese Kennzahl, wie viele der richtigen Informationen das LLM erfasst hat, wie viel ihm entgangen ist und wie viele zusätzliche oder falsche Inhalte es eingebracht hat.

Darüber hinaus verwendet der Benchmark zwei referenzfreie Strafmetriken. Die erste ist eine strukturelle FHIR-Strafe, die prüft, ob das generierte JSON als strukturell gültige FHIR-Ressource geparst werden kann, und zwar mit FHIR-Ressourcenmodellen in Python. Die zweite ist eine Validator-Strafe, die aus dem HL7 Java FHIR Validator stammt und tiefere Konformitätsprobleme wie Regelverletzungen, Terminologieprobleme und andere formale Validierungsbefunde erfasst.

Dies ist einer der zentralen Punkte, in denen unsere Arbeit über das ursprüngliche Framework hinausgeht. Wir wollten nicht bei einer einzigen Metrik stehen bleiben. Wir wollten einen Benchmarking-Prozess, der Generierungsausgaben beibehalten, Syntax- und Validator-Strafen getrennt nachverfolgen und die Inspektion erleichtern kann, wie und wo ein LLM versagt hat. Dadurch wird der Benchmark auch über verschiedene LLM-Familien und Bereitstellungsumgebungen hinweg besser wiederholbar.

Welche Schlussfolgerungen ziehen wir aus dem Benchmark?

Einige übergeordnete Muster stachen deutlich hervor.

Erstens schneiden viele starke Modelle bei FHIR-QA und FHIR-RESTQA sehr gut ab. Führende Modelle erreichen bei diesen Aufgaben oft sehr hohe Werte, was darauf hindeutet, dass moderne Modelle einen erheblichen Umfang an FHIR-Wissen aufnehmen und abrufen können.

Zweitens ist FHIR-ResourceID uneinheitlicher. Manche Modelle schneiden außerordentlich gut ab, während andere deutlich zurückfallen. Diese Lücke erinnert daran, dass allgemeine Modellstärke nicht immer automatisch zu konsistenter Leistung bei strukturierter Klassifikation führt.

Die deutlichste Beobachtung ist jedoch, dass Note2FHIR mit Abstand die schwierigste Aufgabe bleibt. Das galt selbst für die besser performenden Modelle. Einige erzeugten vielversprechende strukturierte Ausgaben und übertrafen andere klar, aber die Werte lagen dennoch deutlich unter denen der einfacheren Aufgaben. Der Sprung vom Verstehen von FHIR hin zur zuverlässigen Erzeugung guter FHIR-Ausgaben ist erheblich.

Das ist wahrscheinlich die wichtigste Erkenntnis aus dem Benchmark. Die Extraktion klinischer Daten ist nicht allein dadurch gelöst, dass ein LLM bei FHIR-QA oder FHIR-RESTQA gut abschneidet. Die robuste Erzeugung strukturierter Ausgaben über Note2FHIR hinweg bleibt ein deutlich schwierigeres Problem, und für offene Umwandlungen von klinischem Text in strukturierte Daten muss die Evaluierung streng sein.

Ein abschließender Gedanke

Die zentrale Aussage dieses Benchmarks ist nicht, dass LLMs schlecht in FHIR sind. Tatsächlich sind viele von ihnen bei enger abgegrenzten Aufgaben bereits recht fähig. Die wichtigere Erkenntnis ist, dass die Generierung strukturierter klinischer Daten eine andere Schwierigkeitsstufe darstellt. Sie erfordert nicht nur Fachwissen, sondern auch Konsistenz, Präzision und Konformität.

Genau hier wird sorgfältiges Benchmarking wertvoll. Es liefert ein klareres und ehrlicheres Bild davon, was diese Modelle bereits gut können, wo sie noch Schwierigkeiten haben und was nötig wäre, um sie verantwortungsvoll im Gesundheitswesen einzusetzen.

Literatur und Links