--- { "title": "Zweiphasige FHIR-Terminology: Authoring & Nutzung", "description": "Warum FHIR-Terminology in Authoring- und Laufzeitphasen aufgeteilt wird — Code-Systeme, Value Sets, Expansion-Denormalisierung und die Rolle eines FHIR-Servers.", "date": "2019-04-30", "author": "Nikolai Ryzhikov", "reading-time": "2 min read", "tags": [ "Terminology", "FHIR Standard" ], "seo-tags": [ "API", "FHIR", "Terminology" ] } --- [Terminology](/blog/introducing-hybrid-terminology-engine) ist im Bereich Health IT ein äußerst wichtiger und komplexer Aspekt. Ein Großteil der Interoperabilität hängt davon ab, wie präzise Sie Ihre Daten **ko**dieren. Die FHIR-[Terminology](/blog/automate-terminology-translation-with-aidbox-tx-engine)-Service-Spezifikation leistet hervorragende Arbeit, indem sie Entwicklern eine einfache und unkomplizierte API für den [Terminology-Service](https://www.hl7.org/fhir/terminology-service.html) bereitstellt. Terminology-Management ist eine komplexe Domäne — Sie müssen externe Code-Systeme aktuell halten, ihre interne Struktur verstehen sowie Werkzeuge für Authoring, Versionierung und Veröffentlichung bereitstellen. Man könnte eine Architektur mit getrenntem [FHIR-Server](https://www.health-samurai.io/fhir-server) und Terminology-Service in Betracht ziehen. Ein „guter" [FHIR-Server](https://www.health-samurai.io/fhir-server) weist jedoch eine sehr starke Abhängigkeit von Terminology auf — für Validierung, Lookups und Subsumptions-Abfragen. Die vollständige Implementierung der Terminology-Service-Spezifikation in einem [FHIR-Server](https://www.health-samurai.io/fhir-server) ist aufwendig. Die Nutzung eines externen Terminology-Service macht Ihren [FHIR-Server](https://www.health-samurai.io/fhir-server) hingegen nicht autonom. Wir stehen also vor einem Kompromiss :( > Starten Sie mit dem Aidbox [FHIR-Server](https://www.health-samurai.io/fhir-server) für Datenspeicherung, Integrationen, Healthcare-Analysen und mehr, oder [beauftragen Sie unser Team](https://www.health-samurai.io/services) zur Unterstützung Ihrer Softwareentwicklung. ### Authoring vs. Nutzung Wenn Sie [FHIR-Terminology](/articles/state-of-fhir-terminology-2024) genauer betrachten, werden Sie feststellen, dass Terminology in zwei Bereiche unterteilt werden kann — **Authoring/Verwaltung** und **Nutzung**. Für **Authoring-Anwendungsfälle** benötigen Sie aktuelle CodeSystems, ValueSets-Design-Werkzeuge mit Expansion-Engine, Versionsverwaltung usw. Für die **Nutzung** arbeiten Sie größtenteils mit unveränderlichen ValueSets und müssen effiziente Filter- und Lookup-Funktionen zur Validierung bereitstellen. Um die Kopplung zwischen Terminology und [FHIR-Server](https://www.health-samurai.io/fhir-server) zu reduzieren, können wir die Verantwortlichkeiten auf folgende Weise trennen: - ValueSets im Terminology-Service entwerfen und in expandierter Form über eine Art Bulk-Export-API/Format veröffentlichen - ValueSets in optimierter Form in [FHIR-Server](https://www.health-samurai.io/fhir-server) laden und verwenden Im Folgenden werden die technischen Details erläutert, wie dies umgesetzt werden kann. ### Concept-Ressource In [Aidbox](https://www.health-samurai.io/fhir-server) teilen wir CodeSystem in Header-Informationen und eine Menge von [Concept](https://app.gitbook.com/@aidbox/s/project/terminology/concept)-Ressourcen (noch nicht FHIR-konform :) auf, die eine ähnliche Struktur wie das [CodeSystem.concept](https://www.hl7.org/fhir/codesystem-definitions.html#CodeSystem.concept)-Element und den Coding-Datentyp aufweisen. Dies ermöglicht es uns, einen Teil der Terminology-Service-API in eine einheitliche FHIR CRUD/Search-API über Concept-Ressourcen zu überführen. Wir konvertieren gängige Terminologien in eine Menge von Concept-Ressourcen, die als ndjson-Dateien für effizienten Bulk-Export/-Import verteilt werden können. Hier ein Beispiel für LOINC: > --- *-* *code: 10000-8* ** *display: R wave duration in lead AVR* ** *names: - R wave dur L-AVR - Cardiac - "Durat" - "ECG" ....* ** *property:* ** *loinc:* ** *relatednames2: Cardiac; Durat; ECG; EKG.MEASUREMENTS; ...* ** *method_typ: EKG* ** *classtype: '2'* ** *system: Heart* ** *time_aspct: Pt* ** *common_order_rank: '0'* ** *property: Time* ** *order_obs: Observation* ** *unitsrequired: Y ....* ### Expansion-Denormalisierung Wenn wir der Concept-Ressource mehrere Verweise auf Value Sets hinzufügen, können wir alle komplexen Value-Set-Expansionen folgendermaßen denormalisieren: > *code: 10000-8* *system:* [*http://loinc.org*](http://loinc.org/)***display: R wave duration in lead AVR* *valueSet: -* *reference: ValueSet/LL1162-8 -* *reference: ValueSet/another-vs* Eine Menge von Concepts mit denormalisierten ValueSets kann mit einer Art Bulk-Export-API in ndjson exportiert und in den [FHIR-Server](https://www.health-samurai.io/fhir-server) hochgeladen werden. ### [FHIR-Server](https://www.health-samurai.io/fhir-server)-Laufzeit Die Concept-Ressource mit Verweisen auf ValueSets kann im [FHIR-Server](https://www.health-samurai.io/fhir-server) genutzt werden, um grundlegende Nutzungsoperationen zu implementieren — **$expand** mit Filter, **$validate-code** und **$lookup** — durch eine einfache Such-API über Concept: > *GET /ValueSet/v1/$expand?_filter=x* ***=>*** *GET /Concept?vs=v1&display=???/ValueSet/v1/$validate-code?system=???code=???* ***=>*** */Concept?vs=v1&system=???code=???* ### Fazit Um die Nutzung von Terminology zu vereinfachen und [FHIR-Server](https://www.health-samurai.io/fhir-server) von Terminology zu entkoppeln, können wir einen neuen Concept-Ressourcentyp einführen, das gesamte ValueSet-Authoring im Terminology-Service durchführen und denormalisierte (expandierte) Concepts mit einer deutlich einfacheren Implementierung der Grundoperationen per Bulk-Export/-Import in [FHIR-Server](https://www.health-samurai.io/fhir-server) übertragen. Ihr Feedback ist herzlich willkommen! [![Aidbox FHIR Platform Free Trial](image-1.avif)](https://www.health-samurai.io/aidbox)