FHIR_HFIR_02_BundleCollection_ttl im LLM-Testsuite-Report

Testfallbeschreibung

Der Test prüft, ob das Modell ein FHIR Bundle vom Typ collection erzeugen kann, mit einer Patient Ressource und einer Observation, in der HFIR als Observation.component mit valueString abgebildet ist.

QuelldateiFHIR_HFIR_02_BundleCollection_ttl.txt
Serie2
Kategorienfhir, ttl, hfir, bundle
BewertungLLM-Judge
Prompt SHA-256d73afad8df61c7a19af012b7bbd34150e0b04878b690ec5b65d5b27cff37c647
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 vom Typ collection mit Patient, Observation und vier ausschließlich als Observation.component modellierten HFIR valueString Komponenten.

Erwartung im Katalognein
Korrektes Ergebnis im Katalogja

Judge-Anweisung

Prüfe Bundle.type collection, die Patient Observation Beziehung und die ausschließliche strukturierte HFIR Abbildung in vier Komponenten.

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.
  • Bundle.type ist exakt collection.
  • Das Bundle enthält genau einen Patient und genau eine Observation.
  • Die HFIR Inhalte sind ausschließlich in genau vier Observation.component Einträgen H, F, I und R modelliert.
  • Jede HFIR Komponente verwendet valueString beziehungsweise dessen formatkonforme FHIR RDF Darstellung und enthält einen nicht leeren Wert.

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.
  • Bundle.type fehlt oder ist nicht collection.
  • HFIR wird zusätzlich oder ausschließlich als Observation.valueString, note, extension, narrative oder separate Ressource modelliert.
  • Eine HFIR Komponente verwendet einen anderen value Typ als valueString oder ist leer.
  • Der Graph enthält neben den geforderten Patient und Observation Ressourcen zusätzliche klinische Bundle Ressourcen, obwohl der Test genau diese beiden Ressourcen verlangt.

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

Baue ein FHIR Bundle als ttl mit type collection.
Erzeuge eine Patient-Ressource mit zufälliger ID.
Danach eine Observation, in der die HFIR-Elemente als Observation.component vorkommen.
Jeder Abschnitt H, F, I, R soll valueString nutzen.
Inhaltlich soll es eine typische Anamnese aus der Allgemeinmedizin sein.
Gib nur FHIR ttl aus.
737 Runs 720 bewertet 17.0 % Score 9.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