Einleitung
Digitale Fragebögen werden im Gesundheitswesen häufig zur Erfassung strukturierter Daten eingesetzt. Sie steuern, was abgefragt wird, und sorgen für konsistente Antworten.
Das Problem beginnt nach der Übermittlung. Eine QuestionnaireResponse speichert Antworten in einer verschachtelten, formularspezifischen Struktur. Diese Struktur ist zwar ideal für die Erfassung, aber nicht für Abfragen, Interoperabilität oder Analysen optimiert.
Datenextraktion löst dieses Problem. Sie ermöglicht mehrere kritische Fähigkeiten: Interoperabilität zwischen verschiedenen Gesundheitssystemen, Datenanalyse und Echtzeit-Datenintegration. Daten aus mehreren Quellen können konsolidiert werden, ohne in einem einzelnen System oder in QR-Code-Formaten zu verbleiben, die die Verarbeitung einschränken.
FHIR empfiehlt die Verwendung von Questionnaires zur Erfassung von Rohdaten und anschließend die Umwandlung der QuestionnaireResponse in Standard-FHIR-Ressourcen wie Observations oder MedicationStatements. Nach der Transformation können die Daten systemübergreifend gesucht, geteilt und genutzt werden.
Die Herausforderung der Datenextraktion
FHIR-Questionnaires eignen sich hervorragend für die strukturierte Datenerfassung. Die resultierenden QuestionnaireResponse-Instanzen sind jedoch schwer zu durchsuchen, zu vergleichen oder mit anderen FHIR-Ressourcen zu integrieren. Die zentrale Herausforderung besteht darin, diese Antworten in Standard-FHIR-Ressourcen (z. B. Observations, Patient, Condition) umzuwandeln, um sie nahtlos in Dokumenten, Nachrichten oder REST-APIs verwenden zu können.
Der SDC-Leitfaden bietet vier Extraktionsmechanismen, die jeweils auf spezifische Anwendungsfälle hinsichtlich Komplexität, Kontrolle und Skalierbarkeit zugeschnitten sind. In diesem Artikel werden wir nur drei davon besprechen und die StructureMap-basierte Extraktion auslassen. Mehr darüber können Sie hier lesen.
Observation-basierte Extraktion
Geeignet für: Einfache klinische Bewertungen oder Umfragen, die direkt einzelnen Observations zugeordnet werden.
- Verwenden Sie diese Methode, wenn Fragen 1:1 mit codierten Werten (z. B. LOINC/SNOMED) und Antworten übereinstimmen (z. B. PHQ-9, Vitalzeichen wie Gewicht oder Blutdruck).
- Schnell und leichtgewichtig – kein benutzerdefiniertes Mapping erforderlich.
- Einschränkung: Erzeugt nur Observations; ungeeignet für komplexe oder Multi-Ressourcen-Ausgaben.
Definition-basierte Extraktion
Geeignet für: Strukturierte Formulare, die FHIR-Profile oder Kernressourcen widerspiegeln.
- Ideal, wenn das Formularlayout die Zielressourcenstruktur widerspiegelt (z. B. Patientendemografie → Patient, Medikamentenliste → MedicationStatement).
- Verarbeitet automatisch wiederholende Gruppen, Backbone-Elemente, Slicing und Profilbeschränkungen (feste Werte, Pflichtfelder).
- Einschränkungen: Die Formularstruktur ist eng mit der Ressourcenstruktur verknüpft.
Template-basierte Extraktion
Geeignet für: Formulare, die mehrere verknüpfte Ressourcen erzeugen
Die Template-basierte Extraktion ist der neueste Mechanismus, der zur SDC-Spezifikation hinzugefügt wurde (nach der Observation-basierten, Definition-basierten und StructureMap-basierten). Sie verwendet enthaltene FHIR-Ressource- oder Bundle-Templates, die mit FHIRPath-Ausdrücken annotiert sind.
Sie wurde speziell eingeführt, um die Komplexitäts- und Governance-Herausforderungen zu überwinden, mit denen Implementierer bei den früheren Methoden häufig konfrontiert waren, und sie wird schnell zur bevorzugten Wahl in vielen Projekten.
- Unterstützt Schleifen und Bedingungen über FHIRPath (z. B. Bezeichner nur einschließen, wenn beantwortet; Namenskomponenten wiederholen).
- Vollständige Kontrolle über Boilerplate und statischen Inhalt
- Höchste Lesbarkeit und niedrigste technische Hürde
- Verwendet enthaltene Ressourcen-Templates – unabhängig von externen Profilen.
Was Template-basierte Extraktion in SDC ist
Template-basierte Extraktion ist einer der vier Mechanismen in der FHIR-SDC-Spezifikation zur Umwandlung einer ausgefüllten QuestionnaireResponse in eine oder mehrere FHIR-Ressourcen oder ein vollständiges Transaktions-Bundle.
Sie bietet einen ausgewogenen Ansatz:
- Ausdrucksstärker als die Observation-basierte Extraktion
- Viel einfacher zu erstellen und zu verstehen als die StructureMap-basierte Extraktion
- Expliziter und visueller als die Definition-basierte Extraktion
Teams entscheiden sich dafür, wenn sie eine klare Kontrolle über die Ausgabe benötigen und moderate Logik wie wiederholende Gruppen, Bedingungen, feste Werte und Profile benötigen, ohne die FHIR-Mapping-Sprache erlernen zu müssen.
Grundprinzip
Sie betten fertige Template-Ressourcen (oder ein Template-Bundle) direkt in die Questionnaire als enthaltene Ressourcen ein. Diese Templates enthalten bereits den erforderlichen Boilerplate – Meta-Profile, feste Codes, Extensions, Narrative usw.
Anschließend annotieren Sie Teile dieser Templates mit kleinen FHIRPath-Ausdrücken, die definieren, wie Daten befüllt werden:
- Ein Feld mit der Antwort auf eine bestimmte Frage füllen
- Einen Abschnitt einmal für jede vom Benutzer gegebene Antwort wiederholen
- Ein Element entfernen, wenn der Benutzer die Frage leer gelassen hat
Wenn die $extract-Operation ausgeführt wird, kopiert die Engine die Templates, wertet die Ausdrücke gegen die QuestionnaireResponse aus, wiederholt oder entfernt Elemente gemäß den Anweisungen und gibt ein zur Übermittlung bereites Transaktions-Bundle zurück.
Wie es in der Praxis funktioniert
Im Aidbox Form Builder ist der Prozess visuell: Sie zeichnen einfach Ihr Formular und fügen dann fertige Ressourcen-Templates genau in die Gruppen ein, in denen die Daten leben. Aidbox wiederholt die Templates automatisch, löst Referenzen auf, wendet Profile an und gibt ein perfektes Transaktions-Bundle zurück.
Lassen Sie uns ein vollständiges Allergie-Aufnahmeformular erstellen, das Folgendes extrahiert:
- Patient
- Eine AllergyIntolerance pro Allergie, verknüpft mit diesem Patienten
Schritt 1 – Benutzerseitige Questionnaire erstellen (Allergiehistorie)
Aidbox Form Builder → Neue Questionnaire → Titel: „Allergy History"
Genaue Formularübersicht (was Kliniker sehen):
-
Patientenkopf Vollständiger Name
-
Geburtsdatum
-
Geschlecht
-
Allergien Allergen
-
Allergietyp
-
Reaktion
-
Schweregrad
-
Kritikalität
Schritt 2 – Extraktions-Templates innerhalb der Patientengruppe definieren
Fügen Sie ein Patient-Ressourcen-Template als enthaltene Ressource hinzu.
Schritt 3 – Templates mit Werten befüllen
Ordnen Sie Formularfelder mithilfe von FHIRPath-Ausdrücken Patient-Elementen zu.
Schritt 4 – Template für die AllergyIntolerance-Extraktion hinzufügen
Fügen Sie ein AllergyIntolerance-Ressourcen-Template innerhalb der wiederholenden Allergiengruppe hinzu, sodass eine Ressource pro erfasster Allergie erstellt wird.
Schritt 5 – Template mit Werten befüllen und mit dem Patienten verknüpfen
Sie können Felder im Template auch mit statischen Werten befüllen, beispielsweise indem Sie eine Option aus einem ValueSet auswählen, wenn diese über Ressourcen hinweg konstant bleibt.
Schritt 6 – Extraktion testen
Alles ist automatisch verknüpft, profiliert und bereit zur Übermittlung per POST.
Fazit
Template-basierte Extraktion bietet eine praktische Balance zwischen Flexibilität, Lesbarkeit und Wartbarkeit innerhalb der FHIR-SDC-Spezifikation. Sie ist besonders nützlich, wenn keine umfassende StructureMap-Expertise vorhanden ist oder wenn Autoren eine direkte Kontrolle über die Struktur der resultierenden FHIR-Ressourcen benötigen.
Durch das Einbetten von Ressourcen- oder Bundle-Templates direkt in die Questionnaire (als enthaltene Ressourcen) und deren Annotierung mit einfachen FHIRPath-gesteuerten templateExtractContext- und templateExtractValue-Extensions können Autoren präzise definieren:
- welche Elemente nur dann erscheinen, wenn relevante Antworten gegeben werden,
- wie wiederholende Elemente mehrere Backbone-Elemente oder ganze Ressourcen erzeugen,
- Standard- oder feste Werte, Profilkonformitätsdetails und Bundle-Metadaten,
- bedingte Ein-/Ausschlusslogik und Schleifenverhalten – alles ohne eine einzige Zeile Mapping-Skript zu schreiben.
Diese Methode bietet visuelle Klarheit und sofortige Testbarkeit und unterstützt gleichzeitig komplexe Transformationen, einschließlich mehrerer Ressourcen, ressourcenübergreifender Referenzen über allocateId, bedingter Abschnitte und vollständiger Transaktions-Bundles. Da die Ausgabestruktur explizit im Template definiert ist, können Implementierer die erwarteten Ergebnisse zur Entwurfszeit validieren, was Laufzeitfehler im Vergleich zu den prozeduralen Alternativen erheblich reduziert.
Für Teams, die eine robuste, wiederverwendbare, profilkonforme Ressourcenerstellung aus Formularen wünschen, aber die Lernkurve von StructureMap oder die Starrheit rein definitionsbasierter Zuordnung vermeiden möchten, ist die Template-basierte Extraktion die zugänglichste leistungsstarke Option im SDC-Werkzeugkasten.
Siehe auch: SQL on FHIR: What is a ViewDefinition?.
