Vokabular-Einbindung: Unterschied zwischen den Versionen

Aus Hl7wiki
Wechseln zu: Navigation, Suche
(→‎Darstellung der Binding-Stärke)
 
(14 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 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.
+
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<ref>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].</ref><ref>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].
 +
</ref><ref>Vocabulary Bindings Syntax Wiki, available from <http://wiki.hl7.org/index.php?title=Binding_Syntax#German>
 +
</ref>.
  
 
Dabei werden zwei '''Strategieansätze''' unterschieden um ein Value Set an ein Attribut oder einen Datentyp zu binden:
 
Dabei werden zwei '''Strategieansätze''' unterschieden um ein Value Set an ein Attribut oder einen Datentyp zu binden:
Zeile 25: Zeile 27:
 
| erforderlich / zwingend erforderlich<br/>''required / mandatory'' || MUSS<br/>''SHALL'' || DARF NICHT<br/>''SHALL NOT''
 
| erforderlich / zwingend erforderlich<br/>''required / mandatory'' || MUSS<br/>''SHALL'' || DARF NICHT<br/>''SHALL NOT''
 
|-
 
|-
−
| empfohlen<br/>''best practice / recommended'' || SOLL<br/>''SHOULD'' || SOLL NICHT<br/>''SHOULD NOT''
+
| empfohlen<br/>''best practice / recommended'' || SOLLTE<br/>''SHOULD'' || SOLLTE NICHT<br/>''SHOULD NOT''
 
|-
 
|-
 
| akzeptiert / erlaubt<br/>''acceptable / permitted'' || DARF<br/>''MAY'' || MUSS NICHT<br/>''NEED NOT''
 
| akzeptiert / erlaubt<br/>''acceptable / permitted'' || DARF<br/>''MAY'' || MUSS NICHT<br/>''NEED NOT''
Zeile 33: Zeile 35:
 
* 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''.
 
* 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.
+
* Analog dazu wird die Coding Strength bei der Stärke des Bindings „SHOULD“ / „SOLLTE“ innerhalb des Datentyps CD (concept descriptor) auf ''CWE = coded with extensibility'' festgelegt.
 +
 
 +
=== Darstellung der Flexibilität des Value Sets Bindings ===
 +
 
 +
{|  class= hl7table
 +
! Flexibilität des Bindings !! Ausdruck
 +
|-
 +
| Statische Flexibilität || STATISCH<br/>''STATIC''
 +
|-
 +
| Dynamische Flexibilität || DYNAMISCH<br/>''DYNAMIC''
 +
|}
 +
 
 +
== 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====
 +
DesignTimeDynamicBindingSyntax =
 +
"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."
 +
 
 +
{{EMBox|zur „ODER“- Syntax: Die Reihenfolge der genannten ValueSets drückt die Präferenz der ValueSets aus.}}
 +
 
 +
Beispiele:
 +
Der Wert für „administrativeGenderCode“ MUSS DYNAMISCH aus dem ValueSet 2.16.840.1.113883.11.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.
 +
 
 +
{{EMBox|Value Set OIDs gehören in Deutschland (und anderswo) zum OID-Ast .11. Ein Beispiel dafür ist hier im Wiki unter [[Hilfe:Terminologien]] gegeben.}}
 +
 
 +
=== 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====
 +
DesignTimeStaticBindingSyntax =
 +
"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."
 +
 
 +
{{EMBox|zur „ODER“- Syntax: Die Reihenfolge der genannten ValueSets drückt die Präferenz der ValueSets aus.}}
 +
 
 +
====Beispiele====
 +
Der Wert für „administrativeGenderCode“ MUSS STATISCH aus dem ValueSet 2.16.840.1.113883.11.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====
 +
DesignTimeStaticBindingSingleCodeSyntax =
 +
"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====
 +
RuntimeDynamicBindingSyntax =
 +
"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."
 +
 
 +
{{EMBox|zur „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====
 +
RuntimeStaticBindingSyntax =
 +
"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."
 +
 
 +
{{EMBox|zur „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.
 +
 
 +
==Beispiel für die Einbindung im Text==
 +
Im Folgenden soll ein Beispiel gegeben werden, wie die Einbindung im Text (zum Beispiel in der Wiki-Darstellung aussehen soll.
 +
{{ConstraintBox|Der Wert für LevelOfCareAssignment.value in der Observation levelOfCareAssignment MUSS STATISCH aus dem ValueSet LevelOfCareAssignment.value <valueSystemOID fehlt noch> 20110930 ausgewählt werden.}}
 +
==Referenzen==
 +
<references/>

Aktuelle Version vom 19. Juni 2012, 08:46 Uhr

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][3].

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		 SOLLTE
SHOULD		 SOLLTE 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“ / „SOLLTE“ 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
STATIC
Dynamische Flexibilität DYNAMISCH
DYNAMIC

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

DesignTimeDynamicBindingSyntax = 

"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."
Talk.svg zur „ODER“- Syntax: Die Reihenfolge der genannten ValueSets drückt die Präferenz der ValueSets aus.

Beispiele: 

Der Wert für „administrativeGenderCode“ MUSS DYNAMISCH aus dem ValueSet 2.16.840.1.113883.11.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.
Talk.svg Value Set OIDs gehören in Deutschland (und anderswo) zum OID-Ast .11. Ein Beispiel dafür ist hier im Wiki unter Hilfe:Terminologien gegeben.

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

DesignTimeStaticBindingSyntax = 

"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."
Talk.svg zur „ODER“- Syntax: Die Reihenfolge der genannten ValueSets drückt die Präferenz der ValueSets aus.

Beispiele

Der Wert für „administrativeGenderCode“ MUSS STATISCH aus dem ValueSet 2.16.840.1.113883.11.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

DesignTimeStaticBindingSingleCodeSyntax = 

"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

RuntimeDynamicBindingSyntax = 

"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."
Talk.svg zur „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

RuntimeStaticBindingSyntax = 

"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."
Talk.svg zur „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.

Beispiel für die Einbindung im Text

Im Folgenden soll ein Beispiel gegeben werden, wie die Einbindung im Text (zum Beispiel in der Wiki-Darstellung aussehen soll.

Conformance.svg Der Wert für LevelOfCareAssignment.value in der Observation levelOfCareAssignment MUSS STATISCH aus dem ValueSet LevelOfCareAssignment.value <valueSystemOID fehlt noch> 20110930 ausgewählt werden.

Referenzen

  1. ↑ 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].
  2. ↑ 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].
  3. ↑ Vocabulary Bindings Syntax Wiki, available from <http://wiki.hl7.org/index.php?title=Binding_Syntax#German>
Abgerufen von „https://wiki.hl7.de/index.php?title=Vokabular-Einbindung&oldid=5052“