GerMedBench

Methodik

Datengrundlage, Evaluationsverfahren und Bewertungskriterien

Warum GerMedBench?

Im Gesundheitswesen gelten strenge Datenschutz- und Regulierungsanforderungen. Patientendaten dürfen in der Regel nicht an externe Cloud-Dienste übermittelt werden — in der Praxis bedeutet das, dass Kliniken und Gesundheitsunternehmen auf Open-Weights-Modelle angewiesen sind, die lokal oder on-premise betrieben werden können.

Allgemeine LLM-Leaderboards wie Artificial Analysis und LM Arena messen Modelle auf englischsprachigen, domänenübergreifenden Tasks. GerMedBench ergänzt diese um eine Dimension, die dort fehlt: die Evaluation von Open-Weights-Modellen auf deutschen klinischen Texten mit fachspezifischen Aufgaben wie ICD-10-Kodierung, Arztbrief-Zusammenfassung und Differentialdiagnostik — genau die Modelle, die im klinischen Alltag tatsächlich einsetzbar sind.

Datengenerierung

Die Benchmark-Daten werden synthetisch generiert. Ein Frontier-Modell (gemini-3-flash-preview) erstellt für jeden Task fokussierte klinische Texte mit passender Ground Truth. Jeder Task erhält Texte in der optimalen Länge und mit dem passenden Detailgrad:

  • — ICD-10-Kodierung: Kurzepikrisen (150–300 Wörter)
  • — Arztbrief-Zusammenfassung: Vollständige Entlassbriefe (600–1000 Wörter)
  • — Klinisches Reasoning: Fallvignetten ohne explizite Diagnose (200–400 Wörter)
  • — Medikamentenextraktion: Texte mit Medikamentenlisten (150–300 Wörter)
  • — Medizinisches Wissen: IMPP-Stil MC-Fragen mit Fallvignette (5 Antwortmöglichkeiten)
  • — Patientenverständliche Erklärung: Medizinische Fachtexte (Befundberichte, Histopathologie, Laborbefunde, 100–250 Wörter)

Alle Texte variieren über neun Fachbereiche (Innere Medizin, Kardiologie, Pneumologie, Neurologie, Gastroenterologie, Onkologie, Orthopädie/Unfallchirurgie, Psychiatrie/Psychosomatik, Gynäkologie/Geburtshilfe) und drei Komplexitätsgrade. Die synthetische Generierung vermeidet Datenschutzprobleme und ermöglicht eine kontrollierte Variation. Langfristig ist die Integration öffentlicher Korpora (GraSCCo, GGPONC 2.0) sowie community-beigetragener anonymisierter Fälle geplant.

Evaluationsverfahren

ICD-10-GM Kodierung
Aktiv

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.
Klinisches Reasoning
Aktiv

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. Diagnose-Namen werden per LLM-assistiertem Matching verglichen (Gemini Flash Lite), um Synonym-Varianten korrekt zu erkennen (z.B. "Bakterielle Pneumonie" ↔ "Ambulant erworbene Pneumonie"). 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?
Medikamentenextraktion
Aktiv

Aufgabe: Das Modell erhält einen klinischen Text mit Medikamentenangaben und soll für jedes Medikament Wirkstoff, Dosis und Einnahmefrequenz strukturiert extrahieren.

Evaluation: Vollautomatisch. Wirkstoff-Matching per LLM-assistiertem Vergleich (Gemini Flash Lite), um Handelsnamen, Salzformen und Abkürzungen korrekt zuzuordnen (z.B. "ASS" ↔ "Acetylsalicylsäure"). 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.
Medizinisches Wissen
Aktiv

Aufgabe: Das Modell erhält eine klinische Multiple-Choice-Frage im Stil des IMPP M2 Staatsexamens (Zweiter Abschnitt der Ärztlichen Prüfung). Jede Frage enthält eine kurze Fallvignette und fünf Antwortmöglichkeiten (A–E), von denen genau eine korrekt ist.

Evaluation: Vollautomatisch, kein LLM-as-Judge erforderlich. Eine Metrik:

  • Accuracy — Anteil korrekt beantworteter Fragen. Misst klinisches Fachwissen über Diagnostik, Therapie, Pharmakologie und Pathophysiologie auf Staatsexamen-Niveau.
Patientenverständliche Erklärung
Aktiv

Aufgabe: Das Modell erhält einen komplexen medizinischen Fachtext (Befundbericht, Laborbefund, Histopathologie, OP-Bericht) und soll diesen so erklären, dass ein Patient ohne medizinische Vorkenntnisse alles versteht.

Evaluation: LLM-as-Judge (gemini-3-flash-preview) bewertet jede Erklärung anhand einer strengen Rubrik mit drei Dimensionen (je 1–5):

  • Verständlichkeit — Ist der Text für einen Laien ohne Vorkenntnisse verständlich? Jeder unerklärte Fachbegriff ist ein Fehler.
  • Medizinische Korrektheit — Sind alle medizinischen Sachverhalte korrekt vereinfacht? Keine irreführenden Vereinfachungen.
  • Vollständigkeit — Sind alle klinisch relevanten Informationen kommuniziert?
Arztbrief-Zusammenfassung
Aktiv

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-flash-preview) bewertet jede Zusammenfassung anhand einer strengen klinischen Rubrik mit drei Dimensionen (je 1–5, alle Ankerpunkte definiert):

  • Faktentreue — Sind alle genannten Fakten korrekt und im Original belegbar? Halluzinationen zählen als schwere Fehler.
  • Vollständigkeit — Sind alle klinisch relevanten Informationen aus dem Gold Standard enthalten? Punkt-für-Punkt-Vergleich.
  • Klinische Präzision — Ist die Zusammenfassung spezifisch und klinisch verwertbar? Generische Formulierungen werden bestraft.

Modell-Inferenz

Open-Source-Modelle werden über Together AI und DeepInfra 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.
  • — GerMedBench verwendet Frontier-Modelle (Gemini) als Ground-Truth-Generator und LLM-as-Judge. Die Qualität der Benchmark-Daten und der generativen Bewertungen ist damit durch die Fähigkeiten dieser Modelle begrenzt — insbesondere bei deutschem medizinischem Fachvokabular können auch Frontier-Modelle Fehler machen.
  • — 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 der ThalamiQ GmbH.