FHIR_HFIR_04_AkutAtemnot_ttl im LLM-Testsuite-Report

Testfallbeschreibung

Der Test prüft, ob das Modell ein FHIR Bundle mit einer Anamnese zur akuten Atemnot erzeugen kann, bei dem die HFIR Information strukturiert in vier Komponenten hinterlegt ist.

QuelldateiFHIR_HFIR_04_AkutAtemnot_ttl.txt
Serie2
Kategorienfhir, ttl, hfir, bundle
BewertungLLM-Judge
Prompt SHA-256b2f387bbff61b4e1605bf03687d745fd92a3e39cddeb2ccf715417baa6e26ef3
LLM-Judge: Die Antwort wird LLM-gestützt bewertet. Ein Judge-Modell vergleicht die Modellantwort mit der fachlichen Erwartung und entscheidet, ob sie inhaltlich erfüllt ist.

Erwartetes Ergebnis

Valides FHIR R4 RDF/Turtle Bundle mit Patient und Observation zur akuten Atemnot sowie vier klinisch plausiblen HFIR valueString Komponenten.

Erwartung im Katalognein
Korrektes Ergebnis im Katalogja

Judge-Anweisung

Prüfe neben der formalen FHIR R4 Struktur, ob die Observation klar akute Atemnot dokumentiert und H, F, I und R getrennt und klinisch plausibel ausgefüllt sind.

Muss erfüllt sein

  • Die Ausgabe besteht ausschließlich aus syntaktisch gültigem Turtle und lässt sich als RDF Graph parsen. Markdown Codezäune dürfen für die Prüfung entfernt werden, zusätzliche Prosa ist nicht zulässig.
  • Der Präfix fhir ist auf http://hl7.org/fhir/ gebunden.
  • Genau ein Knoten ist als fhir:Bundle typisiert und mit fhir:nodeRole fhir:treeRoot als Wurzelressource gekennzeichnet.
  • Patient und Observation sind als fhir:Patient und fhir:Observation Ressourcen modelliert und über die FHIR Bundle Struktur erreichbar.
  • FHIR Primitive verwenden die R4 RDF Modellierung mit fhir:value. Wiederholte Elemente besitzen konsistente, lückenlose fhir:index Werte ab 0.
  • Die Observation besitzt gültige FHIR RDF Aussagen für status und code. Die subject Reference enthält eine konsistente fhir:Reference.reference und sinnvollerweise einen auflösbaren fhir:link zum Patient.
  • Das Bundle enthält einen Patient und eine mit ihm verknüpfte Observation.
  • Observation.code oder Observation.code.text kennzeichnet das Thema akute Atemnot beziehungsweise eine semantisch eindeutige gleichwertige Formulierung.
  • Die Observation enthält genau vier component Einträge H, F, I und R mit jeweils nicht leerem valueString beziehungsweise formatkonformer FHIR RDF Darstellung.
  • Die vier Texte sind kurz, klinisch plausibel und beziehen sich auf eine akute Atemnot Anamnese. Es wird keine bestimmte wörtliche Formulierung verlangt.

Fehlerkriterien

  • Die Ausgabe ist kein parsebares Turtle, bindet fhir falsch oder enthält Prosa außerhalb der RDF Serialisierung.
  • Der Graph verwendet nur frei erfundene Prädikate statt der FHIR R4 RDF Eigenschaften.
  • Mehr als ein Knoten ist als treeRoot markiert oder die Wurzel ist kein Bundle.
  • Primitive Werte werden nicht mit fhir:value dargestellt oder Wiederholungen haben doppelte beziehungsweise lückenhafte fhir:index Werte.
  • Patient, Observation, status, code oder die auf den Patient gerichtete subject Reference fehlt.
  • Die Observation betrifft erkennbar ein anderes klinisches Thema oder enthält nur generische Platzhalter.
  • HFIR ist nur als Fließtext oder in weniger beziehungsweise mehr als vier Komponenten modelliert.
  • Mindestens einer der vier klinischen Werte ist leer oder widerspricht offensichtlich dem Szenario.

Judge-Hinweis: Bewerte die offizielle FHIR R4 RDF Darstellung. Turtle ist ein RDF Graph, doch die Reihenfolge wiederholter FHIR Elemente wird durch fhir:index festgelegt. Für die klinischen HFIR Texte zählt semantische Plausibilität, nicht eine bestimmte Wortwahl.

Prompt

Erstelle ein FHIR Bundle im ttl-Format, das eine Anamnese zur akuten Atemnot enthält.
Die Observation soll vier strukturierte HFIR-Komponenten enthalten.
Verwende in den Komponenten kurze klinische Angaben.
Achte auf korrekte Namespaces und gültige FHIR-Struktur.
Gib ausschließlich das Bundle aus.
721 Runs 704 bewertet 9.2 % Score 1.3 % exakt korrekt
Hilfe zu Bewertung, Score und exakter Korrektheit

Score ist eine abgestufte Gütebewertung: correct = 100 %, mostly_correct = 80 %, partial = 50 %, wrong/not_answered = 0 %.

Exakt korrekt ist strenger: Nur Runs mit dem Label correct zählen. Mostly correct erhöht den Score, zählt aber nicht als exakt korrekt.

Bewertet zählt alle Runs mit fachlichem Urteil. Bei LLM-Judge-Ergebnissen zählen auch Judge-Fehler als bewertet, aber mit Score 0 %.

Erzeugt am