Vokabular-Einbindung
Inhaltsverzeichnis
- 1 Einbindung von Kodes, Value Sets und Kodesystemen
Einbindung von Kodes, Value Sets und Kodesystemen
Für eine HL7-konforme Implementierung müssen die Elemente, die kodierte Einträge transportieren sollen, fest mit einem Value Set verbunden sein, das alle gültigen Werte umfasst, die in diesem Element transportiert werden können. Eine solche Assoziation wird als vocabulary binding bezeichnet[1][2].
Dabei werden zwei Strategieansätze unterschieden um ein Value Set an ein Attribut oder einen Datentyp zu binden:
- Design-time binding: Bei dieser Form wird ein Attribut mit einem kodierten Datentyp direkt mit einem zum Zeitpunkt der Entwicklung der concept domain bestehenden Value Set verbunden. Die concept domain des übergeordneten Modells reglementiert somit die Semantik des Bindings. Das bedeutet, dass aus der concept domain abgeleitete Modelle das Binding in konsistenter Weise übernehmen müssen oder nur in angemessener Weise einschränken können.
- Runtime binding: Dieses Binding bietet sich während der Entwicklungszeit für Fälle an, in denen das spezifische und endgültige Value Set noch unbekannt ist. Hier wird ein Attribut oder Datentyp zunächst an eine Sammlung von Werten gebunden, die aus der concept domain stammen. Während einer späteren Implementierung wird diese Ansammlung durch ein spezifisches Value Set (zum Beispiel eines Terminologieservers) ersetzt. Dafür nutzt der Terminologieserver die concept domain und ihr "Thema" als Schlüssel, um das Value Set der concept domain zuzuordnen. Da die mit der Instanz verbundene Nutzung somit innerhalb der Instanz identifiziert wird, ist es für einen Empfänger, der die Spezifikation (und damit die concept domain) kennt, möglich das dazugehörende Value Set später zu ermitteln.
Die Flexibilität des Value Set Binding bezieht sich auf die Versionsnutzung des jeweiligen Value Sets. Sie kann entweder statisch oder dynamisch erfolgen.
- Bei einem statischen binding (static binding) werden die zugelassenen Werte innerhalb des angebundenen Value Sets nicht automatisch aktualisiert, sobald eine neue Version dieses Value Sets vorliegt. Somit bezieht sich das binding auf eine ganz bestimmte Version des Value Sets zu einem bestimmten Zeitpunkt.
- Bei einem dynamischen binding (dynamic binding) besteht die Verbindung immer zur aktuellen Version des Value Sets unabhängig von einem bestimmten Zeitpunkt, so dass zukünftige Änderungen automatisch übernommen werden.
Darstellung des Bindings
Darstellung der Binding-Stärke
Zur Darstellung der Stärke des Bindings werden die Begriffe „MUSS“, „SOLLTE“ und „KANN“ gemäß der folgenden Tabelle verwendet.
| Stärke der Bindung | positiver Ausdruck | negativer Ausdruck |
|---|---|---|
| erforderlich / zwingend erforderlich required / mandatory |
MUSS SHALL |
DARF NICHT SHALL NOT |
| empfohlen best practice / recommended |
SOLL SHOULD |
SOLL NICHT SHOULD NOT |
| akzeptiert / erlaubt acceptable / permitted |
DARF MAY |
MUSS NICHT NEED NOT |
Hinweise:
- Wird die Stärke des Bindings auf „SHALL“ / „MUSS“ festgelegt, entspricht die coding strength innerhalb des Datentyps CS (Coded Simple Value) CNE = coded, non-extensible / kodiert, nicht erweiterbar.
- Analog dazu wird die Coding Strength bei der Stärke des Bindings „SHOULD“ / „SOLL“ innerhalb des Datentyps CD (concept descriptor) auf CWE = coded with extensibility festgelegt.
Darstellung der Flexibilität des Value Sets Bindings
| Flexibilität des Bindings | Ausdruck |
|---|---|
| Statische Flexibilität | STATISCH |
| Dynamische Flexibilität | DYNAMISCH |
Binding-Strategien / Narrative Syntax
Aus den verschiedenen Ansätzen des bindings ergeben sich vier Binding-Strategien, deren narrative Syntax im folgenden beispielhaft dargestellt wird.
Design-time dynamic binding
Einsatz
Wird verwendet, wenn ein Value Set dynamisch an ein bereits bestehendes Value Set gebunden wird.
Syntax
Der Wert für („codedElement“) (MUSS | SOLL) DYNAMISCH aus dem ValueSet ([valueSetOID] | [valueSetName]) ausgewählt werden. Der Wert für („codedElement“) (MUSS | SOLL) DYNAMISCH aus dem ValueSet ([valueSetOID] | [valueSetName]) [ODER ([valueSetOID] | [valueSetName])] ausgewählt werden.
(Anm. zu „ODER“- Syntax: Die Reihenfolge der genannten ValueSets drückt die Präferenz der ValueSets aus.)
Beispiele:
Der Wert für „AdministrativeGender/code“ MUSS DYNAMISCH aus dem ValueSet 2.16.840.1.113883.5.1 HL7AdministrativeGenderCode ausgewählt werden. Der Wert für „ClinicalDocument/code“ SOLL DYNAMISCH aus dem ValueSet 2.16.840.1.113883.11.217892 LOINCDocumentTypeCode ODER 2.16.840.1.113883.11.XXXXX SNOMEDDocumentTypeCode ausgewählt werden.
Design-time static binding
Einsatz
Wird verwendet, wenn ein Value Set statisch an eine zum Zeitpunkt der Festlegung bestehende Version eines Value Set gebunden wird.
Syntax
Der Wert für („codedElement“) (MUSS | SOLL) STATISCH aus dem ValueSet ([valueSetOID] | [valueSetName]) (valueSetEffectiveDate) ausgewählt werden. Der Wert für („codedElement“) (MUSS | SOLL) STATISCH aus dem ValueSet ([valueSetOID] | [valueSetName]) (valueSetEffectiveDate) [ODER ([valueSetOID] | [valueSetName])] (valueSetEffectiveDate) ausgewählt werden.
(Anm. zu „ODER“- Syntax: Die Reihenfolge der genannten ValueSets drückt die Präferenz der ValueSets aus.)
Beispiele
Der Wert für „AdministrativeGender/code“ MUSS STATISCH aus dem ValueSet 2.16.840.1.113883.5.1 HL7AdministrativeGenderCode 20110930 ausgewählt werden. Der Wert für „ClinicalDocument/code“ SOLL STATISCH aus dem ValueSet 2.16.840.1.113883.11.217892 LOINCDocumentTypeCode 20110930 ODER 2.16.840.1.113883.11.XXXXX SNOMEDDocumentTypeCode 20110930 ausgewählt werden.
Design-time static binding für genau einen Code
Einsatz
Wird verwendet, wenn genau ein Code statisch an eine zum Zeitpunkt der Festlegung bestehende Version gebunden wird.
Syntax
Der Wert für („codedElement“) (MUSS | SOLL) STATISCH auf (code [„displayName“] codeSystemOID [codeSystemName]) [effectiveDate] festgelegt werden.
Beispiele
Der Wert für „ClinicalDocument/code“ MUSS STATISCH auf 28616-1 transfer summary (physician) 2.16.840.1.113883.6.1 LOINC 20110930 festgelegt werden.
Runtime dynamic binding
Hierbei kommt es zu zwei einzelnen binding- Operationen: Einem Schritt in der Entwicklungszeit (design-time) und einem Schritt während der Implementierung. Während der Entwicklungszeit wird ein Attribut oder ein Datentyp statisch an eine concept domain gebunden. Nach der Implementierung erfolgt das binding aller Attribute oder Datentypen entweder als design-time binding (s.o.) oder als runtime binding an genau eine concept domain.
Einsatz
Die runtime binding Syntax besteht aus zwei Teilen: Der erste Teil enthält das binding des Attributes oder des Datentyps an eine concept domain. Der zweite Teil stellt die Verbindung zwischen der concept domain und dem Value Set dar.
Syntax
Die VocabularyDomain für („codedElement“) (MUSS) (DomainName) sein. Das ValueSet für (DomainName) in (RealmName) (MUSS | SOLL) DYNAMISCH auf ([valueSetOID] | [valueSetName]) festgelegt werden. Die VocabularyDomain für („codedElement“) (MUSS) (DomainName) sein. Das ValueSet für (DomainName) in (RealmName) (MUSS | SOLL) DYNAMISCH auf ([valueSetOID] | [valueSetName]) [ODER ([valueSetOID] | [valueSetName])] festgelegt werden.
(Anm. zu „ODER“- Syntax: Die Reihenfolge der genannten ValueSets drückt die Präferenz der ValueSets aus.)
Beispiele
Die VocabularyDomain für „DocumentType/code“ MUSS MeinDokumentType sein. Das ValueSet für MyDocumentType in Deutschland MUSS DYNAMISCH auf 2.16.840.1.113883.11.217892 LOINCDocumentTypeCode festgelegt werden.
Runtime static binding
Einsatz
Die runtime binding Syntax besteht aus zwei Teilen: Der erste Teil enthält das binding des Attributes oder des Datentyps an eine concept domain. Der zweite Teil stellt die Verbindung zwischen der concept domain und dem Value Set dar.
Syntax
Die VocabularyDomain für („codedElement“) (MUSS) (DomainName) sein. Das ValueSet für (DomainName) in (RealmName) (MUSS | SOLL) STATISCH auf ([valueSetOID] | [valueSetName]) (valueSetEffectiveDate) festgelegt werden. Die VocabularyDomain für („codedElement“) (MUSS) (DomainName) sein. Das ValueSet für (DomainName) in (RealmName) (MUSS | SOLL) DYNAMISCH auf ([valueSetOID] | [valueSetName]) (valueSetEffectiveDate) [ODER ([valueSetOID] | [valueSetName])] (valueSetEffectiveDate) festgelegt werden.
(Anm. zu „ODER“- Syntax: Die Reihenfolge der genannten ValueSets drückt die Präferenz der ValueSets aus.)
Beispiele
Der VocabularyDomain für „DocumentType/code“ MUSS MeinDokumentType sein. Das ValueSet für MyDocumentType in Deutschland MUSS STATISCH auf 2.16.840.1.113883.11.217892 LOINCDocumentTypeCode 20110930 festgelegt werden.
Referenzen
- ↑ Health Level Seven Inc. (2011) Value Set Definition and Binding Document. Available from: <http://valuesets.org/wiki/index.php?title=Value_Set_Definition_and_Binding_Document#Bindings> [Accessed 30th September 2011].
- ↑ Health Level Seven Inc. (2011) Version 3 Publishing Facilitator's Guide. Available from: <http://www.hl7.org/v3ballot/html/help/pfg/pfg.html#shall_should_usage> [Accessed 30th September 2011].
