FHIR_HFIR_03_SyntheticBundleUUID_json im LLM-Testsuite-Report

Testfallbeschreibung

Der Test prüft, ob das Modell ein synthetisches FHIR Bundle mit URN UUIDs generieren kann, das eine HFIR Anamnese dokumentiert, einschließlich Patient mit Geschlecht und Geburtsdatum und einer Observation mit HFIR ANAMNESE Code.

QuelldateiFHIR_HFIR_03_SyntheticBundleUUID_json.txt
Serie2
Kategorienfhir, json, hfir, bundle
BewertungLLM-Judge
Prompt SHA-25666bf84f902b1d6e3880a5b8a9f97edecba542f0663c944dddf06d28b02230971
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 synthetisches FHIR R4 JSON Bundle mit eindeutigen URN UUID Identitäten, Patient mit gender und birthDate sowie Observation HFIR-ANAMNESE mit vier HFIR Komponenten.

Erwartung im Katalognein
Korrektes Ergebnis im Katalogja

Judge-Anweisung

Prüfe gültige und konsistente URN UUIDs, Patientendaten, den Observation Code HFIR-ANAMNESE und die vollständige HFIR Komponentenstruktur.

Muss erfüllt sein

  • Die Ausgabe besteht ausschließlich aus einem syntaktisch gültigen JSON Objekt. Markdown Codezäune dürfen für die Prüfung entfernt werden, zusätzliche Prosa, Kommentare oder nachgestellte Kommata sind nicht zulässig.
  • Das Wurzelobjekt enthält resourceType mit dem Wert Bundle.
  • Bundle.entry ist ein Array, dessen resource Objekte die korrekten resourceType Werte Patient und Observation tragen.
  • FHIR Primitive werden als JSON Werte mit korrektem Datentyp modelliert. XML Attribute oder XML Namensraumdeklarationen dürfen nicht nachgeahmt werden.
  • Die Observation besitzt mindestens status und code. Observation.subject.reference verweist konsistent auf den Patient im Bundle.
  • Die Bundle Einträge für Patient und Observation besitzen jeweils eine eindeutige Identität im Format urn:uuid:<gültige UUID>.
  • Patient.gender enthält einen gültigen FHIR R4 AdministrativeGender Code und Patient.birthDate ein syntaktisch gültiges FHIR Datum.
  • Observation.code kennzeichnet die Observation eindeutig mit HFIR-ANAMNESE, entweder als Coding.code oder als gleichwertige CodeableConcept Modellierung.
  • Observation.subject verweist konsistent auf die Patient Identität im Bundle.
  • Die Observation enthält genau vier nicht leere component Einträge H, F, I und R.
  • Jedes verlangte entry.fullUrl ist ein String im Format urn:uuid:<UUID>.

Fehlerkriterien

  • Die Ausgabe ist kein parsebares JSON Objekt oder enthält Prosa beziehungsweise Kommentare außerhalb des JSON.
  • resourceType Bundle fehlt oder Patient und Observation sind nicht in entry[].resource modelliert.
  • XML typische value Attribute, xmlns Felder als vermeintliche Pflichtstruktur oder andere Mischsyntax wird verwendet.
  • Observation.status, Observation.code oder die konsistente Patient Referenz fehlt.
  • URN UUIDs sind syntaktisch ungültig, doppelt oder Referenzen zeigen auf eine andere beziehungsweise nicht vorhandene Ressource.
  • Ein FHIR Resource.id enthält unzulässigerweise den vollständigen Präfix urn:uuid: statt nur eines gültigen FHIR id Werts.
  • gender, birthDate oder der Code HFIR-ANAMNESE fehlt.
  • Die vier HFIR Komponenten sind nicht vollständig oder nicht getrennt strukturiert.

Judge-Hinweis: FHIR JSON besitzt keinen XML Namensraum. Ein fehlendes xmlns Feld ist daher niemals ein Fehler. Entscheidend ist die gültige FHIR R4 JSON Struktur. Für die klinischen HFIR Texte zählt semantische Plausibilität, nicht eine bestimmte Wortwahl.

Prompt

Erzeuge ein synthetisches FHIR Bundle (json), das eine HFIR-Anamnese dokumentiert.
Patient soll Geschlecht und Geburtsdatum haben.
Die Observation soll den Code HFIR-ANAMNESE tragen.
Füge die vier HFIR-Komponenten ein.
Verwende unique URN-UUIDs für fullUrl.
Das Ergebnis muss wohlgeformtes FHIR json sein.
733 Runs 718 bewertet 21.0 % Score 11.4 % 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