Das Problem ist lösbar
Die FHIR R5-Spezifikation umfasst 157 Ressourcen – von grundlegenden wie Patient und Observation bis hin zu spezifischen wie ExplanationOfBenefit für die Abrechnung. Es gibt jedoch Fälle, in denen Ihre Daten in keine vorhandene FHIR-Ressource passen und Sie einen benutzerdefinierten Ressourcentyp erstellen möchten.
In diesem Artikel stellen wir 3 Möglichkeiten zur Erstellung benutzerdefinierter Ressourcentypen auf Ihrem FHIR-Server vor und bewerten deren Stärken und Schwächen.
Ein genauerer Blick
Grundsätzlich schlägt FHIR mehrere Wege zur Erstellung benutzerdefinierter Ressourcen vor:
- Verwenden Sie die Basic-Ressource mit Extensions: Dies ermöglicht es Ihnen, Ihr Datenmodell anzupassen und gleichzeitig die Kompatibilität mit dem FHIR-Framework beizubehalten.
- Erstellen Sie neue Ressourcen auf dieselbe Weise wie FHIR: Dies ist durch die FHIR-Spezifikation nicht erlaubt, das Ergebnis ist jedoch am stärksten an FHIR angelehnt.
- Verwenden Sie logische Modelle: Diese kann jeder definieren, sie fühlen sich jedoch oft vom FHIR-Ressourcenmodell entfremdet an.
Lassen Sie uns jede dieser Methoden untersuchen, um die beste Lösung für Ihre Anforderungen zu finden.
1. Die Basic-Ressource in FHIR verwenden
Die Basic-Ressource ist dafür konzipiert, Konzepte zu verwalten, die im FHIR-Framework noch nicht definiert sind. Sie stellt in erster Linie Metadaten über die Ressource bereit, während alle anderen Datenelemente mithilfe von FHIR Extensions ausgedrückt werden.
Vorteile:
- Von FHIR selbst empfohlen
- Gewährleistet Interoperabilität
Nachteile:
- Erfordert Extension-Management über einen Implementation Guide
- Kann zu einem komplexen Datenmodell führen
Eines der Hauptprobleme besteht darin, dass Sie Ihre Daten aus Basic-Ressourcen heraus und in sie hinein abbilden müssen. Hier ist ein Beispiel einer einfachen Ressource:
id: my-custom-resource
resourceType: MyCustomResource
myKey: test
Und so sieht es aus, wenn es mithilfe der Basic-Ressource modelliert wird:
id: my-custom-resource
resourceType: Basic
code:
coding:
- system: http://example.org/CodeSystem/my-custom-resorces
code: my-custom-resource
meta:
profile:
- http://example.org/StructureDefinition/my-custom-resource
extension:
- url: http://example.org/StructureDefinition/my-custom-resource-my-key
valueString: test
2. Neue Ressourcen auf dieselbe Weise wie FHIR erstellen
Eine alternative Möglichkeit besteht darin, eine benutzerdefinierte Ressource mithilfe von StructureDefinition mit 'kind: resource' und 'derivation: specialization' zu definieren. Auf diese Weise definiert FHIR alle seine Ressourcen.
Die Spezifikation verbietet dies jedoch für jeden außer der FHIR-Spezifikation selbst.
Dieser Ansatz hat dennoch einige Einschränkungen. Einige FHIR-Ressourcen wie SearchParameter oder CapabilityStatement verweisen auf Ressourcentypen und erlauben nur die Verwendung von Ressourcentypen, die in der FHIR-Spezifikation definiert sind (über eine erforderliche Bindung an ein bestimmtes ValueSet). Eine weitere Einschränkung ist, dass eine benutzerdefinierte Ressource kein Ziel einer Referenz sein kann.
Vorteile:
- Unkomplizierte Ressourcendefinition mithilfe von StructureDefinition, die speziell für diesen Zweck entwickelt wurde
- Einige Implementierungen verwenden diese Methode bereits
Nachteile:
- Führt zu nicht interoperablen Ressourcen
- Durch die FHIR-Spezifikation verboten
- Hat einige Einschränkungen bei der Interaktion mit anderen Ressourcen
3. Logische Modelle verwenden
Eine weitere Möglichkeit zur Definition einer benutzerdefinierten Ressource ist die Verwendung von StructureDefinition mit 'kind' auf 'logical' und 'derivation' auf 'specialization' gesetzt. Im Gegensatz zur vorherigen Methode kann diese Ressourcen jeder erstellen. Diese StructureDefinitions, oft als FHIR-Logikdatenmodelle oder einfach als logische Modelle bezeichnet, sollen beliebige Daten mithilfe von FHIR-Abstraktionen modellieren.
Ein gutes Beispiel für den jüngsten Einsatz logischer Modelle ist der SQL on FHIR Implementation Guide und die ViewDefinition-Ressource. Dieses Modell stellt eine tabellarische Projektion einer FHIR-Ressource dar, bei der die Spalten und Einschlusskriterien durch FHIRPath-Ausdrücke definiert werden.
Das Da Vinci Project nutzt logische Modelle ebenfalls in seinen Implementation Guides, um die Interoperabilität zu verbessern und wertbasierte Versorgungsinitiativen zu unterstützen. So enthält der Coverage Requirements Discovery (CRD)-Leitfaden beispielsweise logische Modelle, um die Informationen zu beschreiben, die für jede CRD-Transaktion erfasst werden sollen, und gewährleistet so eine konsistente Datenerfassung und -berichterstattung über verschiedene Systeme hinweg.
Dieser Ansatz hat jedoch auch Nachteile. Logische Modelle wurden nicht als Ressourcen konzipiert. Es wird erwartet, dass ein logisches Modell vom Base- oder Element-Typ abgeleitet wird. Obwohl es nicht verboten ist, ein logisches Modell von Resource abzuleiten, gibt es in diesem Fall keine Hinweise aus der FHIR-Spezifikation zur Semantik. Wenn Sie einen neuen Ressourcentyp mithilfe eines logischen Modells definieren, gelten alle Einschränkungen des vorherigen Ansatzes. Darüber hinaus können Bundles nur logische Modelle enthalten, die vom Resource-Typ abgeleitet sind. Zusätzlich muss die 'type'-Eigenschaft des logischen Modells eine vollständige URL einschließlich Schema und anderer URL-Details enthalten, was als Implementierer bei CRUD-Interaktionen zusätzliche Verarbeitung erfordert.
Vorteile:
- Unkomplizierte Ressourcendefinition über StructureDefinition
- Interoperabel
Nachteile:
- Logische Modelle sind ein Bürger zweiter Klasse
- Sollten von zu rudimentären Typen abgeleitet werden
- Haben Einschränkungen bei der Interaktion mit anderen Ressourcen
- Haben Einschränkungen bei der Interaktion mit der Bundle-Ressource
Kein Zaubertrick: Nur Methoden, die funktionieren
So können Sie benutzerdefinierte Ressourcen mithilfe der integrierten Funktionen des Aidbox FHIR-Servers erstellen und warum diese Methode so praktisch ist.
Benutzerdefinierte Ressourcen wie Standard-FHIR-Ressourcen definieren
Obwohl die FHIR-Spezifikation dies nicht erlaubt, ist der FHIR-Ansatz für benutzerdefinierte Ressourcen häufig der einfachste Weg. Er verhält sich genau wie jede andere Ressource. Sie können Standard-Tooling zur Erstellung verwenden. Aidbox bietet eine Möglichkeit, die Einschränkungen dieser Methode zu beheben.
Denken Sie jedoch daran, dass benutzerdefinierte Ressourcen nicht interoperabel sind und nur dann verwendet werden sollten, wenn die vordefinierten FHIR-Ressourcen Ihre Anforderungen nicht erfüllen können.
Bisherige Einschränkungen lösen
FHIR definiert einige ValueSets, die alle Ressourcentypen auflisten. Bei der Validierung prüft Aidbox, ob der Ressourcentyp im ValueSet enthalten ist oder ob es sich um eine benutzerdefinierte Ressource handelt. Dies ermöglicht die Verwendung benutzerdefinierter Ressourcen innerhalb anderer Ressourcen wie CapabilityStatement oder SearchParameter oder in der 'type'-Eigenschaft von Referenzen.
FHIR erlaubt Referenzen nur auf FHIR-Ressourcen. Aidbox erweitert diese Möglichkeit, indem es Ihnen erlaubt, auch benutzerdefinierte Ressourcen als Referenzziele anzugeben.
👉 Klicken Sie hier, um mehr in der Aidbox-Dokumentation zu lesen.
Aidbox lokal oder in der Cloud betreiben
Aidbox kann lokal oder in der Cloud betrieben werden und bietet damit die Flexibilität, alle diese Methoden zu testen. Ob Sie benutzerdefinierte Ressourcen erkunden oder vorhandene nutzen – Aidbox bietet eine leistungsstarke Plattform zur Erweiterung der Funktionen Ihres FHIR-Servers.
Kostenlose Entwicklungslizenzen sind ebenfalls verfügbar.
Autoren: Evgeny Mukha, Full-Stack Software Engineer bei Health Samurai
Vasiliy Kupriakov, Full-Stack Software Engineer bei Health Samurai
