Dieser Beitrag ist Teil einer Reihe über Health Samurai-Sessions bei den HL7 FHIR DevDays 2025. In diesem Artikel, „FHIR Schema – Ergebnisse des ersten Jahres: Ecosystem-Evolution und Dev‑UX," teilt Evgenii Mukha, Software Engineer bei Health Samurai, seine Erkenntnisse aus einem Jahr Produktionsbetrieb einer neuen FHIR-Validierungs-Engine.
Was Sie lernen werden:
- Warum bestehende FHIR-Validatoren bei denselben Daten zu unterschiedlichen Ergebnissen kommen und was das für die Interoperabilität bedeutet.
- Was FHIR Schema ist und wie es sich von rohen StructureDefinitions unterscheidet.
- Wie der Snapshot‑freie Validierungsalgorithmus Multi-Profil-Prüfungen und Laufzeitanpassungen ermöglicht.
- Was das Team aus dem realen Einsatz gelernt hat und wohin FHIR Schema als nächstes führt.
Das Problem: inkonsistente Validierung
Der Vortrag beginnt mit einem einfachen, aber aufschlussreichen Randfall: Eine Patient-Ressource enthält eine primitive Extension mit Nullwerten, die eine el-1-FHIRPath-Bedingung verletzen sollte. Verschiedene öffentliche Server gehen damit auf völlig unterschiedliche Weise um – von der stillen Entfernung des Wertes über dessen Akzeptanz bis hin zur Meldung nicht zusammenhängender Fehler. Dies verdeutlicht, dass Validierung, die eigentlich ein Eckpfeiler der Interoperabilität sein sollte, in verschiedenen Implementierungen unvorhersehbar funktioniert.
Das Kernproblem sind nicht nur Fehler, sondern eine unzureichend spezifizierte Validierungsspezifikation: Wichtige Details zu Slicing, Terminology und Randfällen sind über Gespräche in Zulip und Tickets in JIRA verstreut, statt in einem klaren, implementierungsorientierten Dokument zusammengefasst zu sein. Engine-Autoren fehlt eine präzise Orientierung, wie sie für FHIRPath existiert, was eine vollständige Kompatibilität schwer erreichbar macht.
Der FHIR Schema-Ansatz
FHIR Schema wird als Möglichkeit eingeführt, Implementierern eine gemeinsame, sprachunabhängige Darstellung von Validierungsbedingungen sowie einen präzisen Validierungsalgorithmus bereitzustellen. Es wird aus StructureDefinitions abgeleitet, ohne diese zu ersetzen, und besteht aus drei Hauptteilen: einem Transpiler, der StructureDefinitions in Schema-Dateien umwandelt, einem JSON/YAML-Schema-Format, das Bedingungen als Baum darstellt, sowie einem Validierungsalgorithmus mit begleitender Test-Suite.
Das Ziel ist, dass Validierungs-Engines in verschiedenen Technologie-Stacks dieselbe Schema-Darstellung wiederverwenden, anstatt eigene interne Modelle zu entwickeln. Dies soll das Verhalten vorhersehbarer machen und die Abweichungen zwischen Servern reduzieren.
Baumförmiges Schema und Snapshot‑freie Validierung
Während StructureDefinitions Elemente als flache Tabelle auflisten, organisiert FHIR Schema sie in einem expliziten Baum, der echte FHIR-Daten widerspiegelt. Elemente definieren mögliche Schlüssel, Arrays sind erstklassig, Terminology-Bindungen und polymorphe Elemente werden direkt modelliert, und Pflicht- oder ausgeschlossene Felder werden ohne Ableitung aus der Kardinalität dargestellt. Slicing wird als Matcher ausgedrückt, die entscheiden, ob ein Element zu einem Slice gehört – basierend auf Kriterien wie Bindungen, Mustern oder Profilgültigkeit.
Der Validierungsalgorithmus erstellt eine Menge relevanter Schemata (Basisressource, Profile und Vorfahren), prüft übergeordnete Invarianten und durchläuft dann den Ressourcenbaum, wobei er knotenspezifische Prüfungen und Slicing-Regeln anwendet. Da er ohne vorab erstellte Snapshots arbeitet, unterstützt er Laufzeitänderungen an Bedingungen, die gleichzeitige Validierung gegen mehrere Profile sowie die Profilerkennung durch Testen, welche Schemata zu vorhandenen Daten passen.
Erkenntnisse aus dem Produktionsbetrieb und Roadmap
Nach einem Jahr Produktionseinsatz in Aidbox haben sich mehrere Erkenntnisse herauskristallisiert: Transpilation muss zustandslos und reproduzierbar sein; Slicing-Gruppen müssen eindeutig abgegrenzt sein, wenn mehrere Profile angewendet werden; und ein klareres Fehlerberichtsmodell ist erforderlich, damit Tools und Test-Suites Ergebnisse zuverlässig vergleichen können. Diese Punkte zeigen, dass die Standardisierung von Format und Algorithmus nur ein Teil der Aufgabe ist – auch die Fehlersemantik spielt eine Rolle.
Mit Blick auf die Zukunft plant das Team, seine Test-Suite zu öffnen, Referenzimplementierungen in JavaScript und Clojure zu veröffentlichen und eine versionierte Spezifikation in einer stärker „FHIR-ähnlichen" Form bereitzustellen – begleitet von einer Arbeitsgruppe, die sich auf Validator-Implementierer konzentriert. Das Ziel ist es, von einer einzelnen Engine mit internen Tests zu einem breiteren Ökosystem kompatibler Engines und gemeinsamer Testfälle zu gelangen.
Warum das für FHIR-Teams wichtig ist
Für Organisationen, die FHIR-Server und Validatoren aufbauen oder integrieren, bietet FHIR Schema einen klareren Weg zu konsistenter Validierung. Engine-Autoren erhalten ein implementierbares Format und einen Algorithmus, anstatt das Verhalten einer einzelnen Referenzimplementierung durch Reverse Engineering zu erschließen. Teams profitieren von besseren Chancen auf konsistente Bestehen/Nichtbestehen-Ergebnisse über verschiedene Server hinweg und erschließen sich fortgeschrittene Szenarien wie Multi-Profil-Validierung und Laufzeitanpassung von Bedingungen. Dadurch werden FHIR-basierte Systeme einfacher zu debuggen und verhalten sich in realen Interoperabilitätsszenarien vorhersehbarer.
Ressourcen
Sehen Sie sich Evgeniis vollständige Präsentation von den FHIR DevDays 2025 und die vollständige Health Samurai-Playlist an: Vollständiges Video ansehen Vollständige Playlist auf YouTube
Verbinden Sie sich mit Evgenii auf LinkedIn oder über den FHIR Schema-Zulip-Stream.
Erkunden Sie diese FHIR Schema-Ressourcen: Spezifikationsentwurf Playground Transpiled Package Dump Ref. Implementation (CLJ) Ref. Implementation (JS)
Siehe auch: Type Schema: FHIR SDKs erstellen.
