Methodik
Datengrundlage, Evaluationsverfahren und Bewertungskriterien
Warum GerMedBench?
Für den englischsprachigen Raum existieren etablierte medizinische LLM-Benchmarks wie MedQA, MedHELM oder LLMEval-Med. Der deutschsprachige klinische Bereich ist hingegen ein blinder Fleck: Bestehende deutsche Datensätze (GGPONC, BRONCO, GraSCCo) wurden für die BERT-Ära entwickelt und evaluieren vorwiegend klassische NLP-Tasks wie Named Entity Recognition. Generative klinische Fähigkeiten moderner LLMs — Kodierung, Zusammenfassung, klinisches Reasoning — wurden für Deutsch bisher nicht systematisch und öffentlich bewertet.
Datengenerierung
Die Benchmark-Daten werden synthetisch generiert. Ein Frontier-Modell (gemini-3.1-pro-preview) erstellt realistische deutsche Kurzepikrisen nach klinisch validierten Templates. Jeder Fall enthält:
- — Klinischer Freitext im deutschen Arztbrief-Stil (150–300 Wörter)
- — Strukturierte Ground Truth (z.B. ICD-10-GM Codes mit Haupt-/Nebendiagnose-Klassifikation)
- — Fachbereich (Innere Medizin, Kardiologie, Pneumologie, Neurologie, Gastroenterologie, Onkologie)
- — Komplexitätsgrad (einfach: 2–3 Diagnosen, mittel: 3–5, komplex: 5–7)
Die synthetische Generierung vermeidet Datenschutzprobleme und ermöglicht eine kontrollierte Variation von Fachbereich, Komplexität und Schreibstil. Langfristig ist die Integration öffentlicher Korpora (GraSCCo, GGPONC 2.0) sowie community-beigetragener anonymisierter Fälle geplant.
Evaluationsverfahren
Aufgabe: Das Modell erhält einen klinischen Freitext und soll alle kodierbaren ICD-10-GM Codes extrahieren, inklusive der Klassifikation als Haupt- oder Nebendiagnose.
Evaluation: Vollautomatisch, kein LLM-as-Judge erforderlich. Drei Metriken:
- Exact Match F1 — Precision und Recall auf Ebene der vollständigen ICD-10-GM Codes (z.B. I21.0). Misst, ob das Modell die exakten Codes findet.
- Category F1 — Matching auf Kategorie-Ebene (z.B. I21 statt I21.0). Erkennt, ob das Modell zumindest die richtige Diagnose-Kategorie identifiziert, auch wenn die letzte Stelle abweicht.
- Hauptdiagnose Accuracy — Ob das Modell die korrekte Hauptdiagnose identifiziert. Klinisch besonders relevant, da die Hauptdiagnose abrechnungsrelevant ist.
Aufgabe: Das Modell erhält einen Auszug aus einem Entlassbrief und soll alle klinischen Entitäten erkennen und klassifizieren: Diagnosen (mit ICD-10-GM), Prozeduren (mit OPS), Medikamente (Wirkstoff, Dosierung) und Laborwerte (Parameter, Wert, Einheit).
Evaluation: Vollautomatisch, kein LLM-as-Judge erforderlich. Fünf Metriken:
- Micro F1 — Micro-gemittelter F1-Score über alle Entitätstypen. Primäre Leaderboard-Metrik.
- Diagnose F1 — F1 für Diagnose-Entitäten (Name + ICD-10-GM Code).
- Prozedur F1 — F1 für Prozedur-Entitäten (Name + OPS Code).
- Medikament F1 — F1 für Medikamenten-Entitäten (Wirkstoff, Dosierung).
- Laborwert F1 — F1 für Laborwert-Entitäten (Parameter, Wert, Einheit).
Aufgabe: Das Modell erhält eine klinische Fallvignette mit Anamnese, Untersuchungsbefund, Laborwerten und ggf. Bildgebung. Es soll eine geordnete Differentialdiagnose-Liste mit klinischer Begründung erstellen.
Evaluation: Hybrid — automatische DDx-Metriken plus LLM-as-Judge. Sechs Metriken:
- Top-1 Accuracy — Hat das Modell die korrekte Diagnose an erster Stelle?
- Top-3 Recall — Ist die korrekte Diagnose unter den ersten drei Differentialdiagnosen?
- DDx Overlap F1 — Überlappung der vorgeschlagenen mit den Referenz-Differentialdiagnosen.
- Reasoning-Qualität — Sind die Begründungen klinisch nachvollziehbar und befundbasiert?
- DDx-Plausibilität — Ist die Reihenfolge der Differentialdiagnosen klinisch sinnvoll?
- Red-Flag-Bewusstsein — Werden gefährliche Differentialdiagnosen angemessen berücksichtigt?
Aufgabe: Das Modell erhält einen klinischen Text mit Medikamentenangaben und soll für jedes Medikament Wirkstoff, Dosis und Einnahmefrequenz strukturiert extrahieren.
Evaluation: Vollautomatisch, kein LLM-as-Judge erforderlich. Drei Metriken:
- Wirkstoff F1 — F1 auf Ebene der Wirkstoff-Erkennung (fuzzy Matching). Primäre Leaderboard-Metrik.
- Partial F1 — Wirkstoff korrekt und mindestens Dosis oder Frequenz stimmen.
- Exact F1 — Wirkstoff, Dosis und Frequenz alle korrekt.
Aufgabe: Das Modell erhält einen vollständigen Entlassbrief und soll eine strukturierte Zusammenfassung mit vier Feldern erstellen: Hauptdiagnose, Therapie, Procedere und offene Fragen.
Evaluation: LLM-as-Judge (gemini-3.1-pro-preview) bewertet jede Zusammenfassung anhand einer klinischen Rubrik mit vier Dimensionen (je 1–5):
- Faktentreue — Sind alle genannten Fakten korrekt und im Original belegbar?
- Vollständigkeit — Sind alle klinisch relevanten Informationen enthalten?
- Halluzinationsfreiheit — Enthält die Zusammenfassung keine erfundenen Informationen?
- Formatkonformität — Entspricht die Zusammenfassung dem erwarteten Format?
Modell-Inferenz
Open-Source-Modelle werden über Together AI evaluiert. Jedes Modell erhält denselben Prompt mit dem klinischen Text und soll die Ergebnisse in einem strukturierten JSON-Format zurückgeben. Die Inferenz erfolgt mit Temperatur 0 für maximale Reproduzierbarkeit. Antworten, die nicht als gültiges JSON geparst werden können, werden als Parse-Fehler gewertet — auch das ist eine relevante Metrik für die klinische Einsatzfähigkeit eines Modells.
Einschränkungen und Transparenz
- — Die aktuelle Datengrundlage ist synthetisch. Synthetische Texte können systematische Muster aufweisen, die in echten klinischen Texten nicht vorkommen.
- — ICD-10-GM Kodierung ist ein komplexer Prozess, der in der Praxis Kontextwissen erfordert, das über den reinen Text hinausgeht (z.B. Kodierrichtlinien, DRG-Relevanz).
- — Die Benchmark-Ergebnisse sind nicht direkt auf klinische Einsatzszenarien übertragbar, sondern dienen als vergleichende Orientierung.
- — Alle Daten, Prompts und Evaluations-Logik sind Open Source und reproduzierbar.
GerMedBench ist ein Open-Source-Projekt von ThalamiQ GmbH in Zusammenarbeit mit dem Institut für KI in der Medizin (IKIM), Universitätsklinikum Essen.