Ihevs:Vokabular-Management

Aus Hl7wiki
(Teildokument von )
Wechseln zu: Navigation, Suche
(→‎Vokabular-Management: Folder.codeList hinzugefügt)
(→‎Identifikation von Kodesystemen in FHIR-basierter Kommunikation: URLs basierend auf gihub export geändert)
 
(12 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
{{DocumentPart}}
 
{{DocumentPart}}
 
=Vokabular-Management=
 
=Vokabular-Management=
−
 
−
Die Festlegung der Werte für ein kodiertes Attribut erfolgt über die Angabe von sog. Konzept- oder Vokabeldomänen (''Concept / Vocabulary Domains''), Kodiersystemen (''Code Systems'') und Wertemengen (''Value Sets''). Eine Konzeptdomäne dient dazu, den Wertebereich eines Attributs einzugrenzen ohne dabei direkt schon feste Kodiersysteme oder Value Sets vorzugeben. Eine Konzeptdomäne wird durch einen Namen, eine textuelle Beschreibung sowie eine Reihe von Beispielkonzepten definiert. Zum Beispiel soll die Konzeptdomäne DocumentEntry.typeCode den Typ eines Dokuments aus Benutzersicht kodieren.
 
  
−
Ein Value Set ist eine eindeutige identifizierbare Sammlung von Konzeptrepräsentationen und es ist einer oder mehreren Konzeptdomänen zugeordnet. Ein Value Set kann Codes aus einem oder mehreren Kodiersystemen enthalten. Ein Kodiersystem wird dabei durch eine Liste von Codes mit zugehörigen Anzeigenamen und Beschreibungen definiert. Innerhalb eines Kodiersystems muss ein Code eine eindeutig definierte Bedeutung haben.  
+
Die Übermittlung von konkreten Daten kann auf zweierlei Art und Weise erfolgen: Die einfachste Variante ist Freitext, bei der beliebige Daten - als Zeichenkette (ggf. noch eingeschränkt auf einen bestimmten Datentyp) - übertragen werden. Dieses Verfahren bietet sich an, wenn die individuelle Ausprägung sehr unterschiedlich sein kann wie bspw. der Name des Patienten oder ein Kommentar. Für immer wiederkehrende und im Prinzip gleiche Information, wie bspw. der Familienstand, werden die zu übertragenden Daten abgekürzt und durch einen "Platzhalter" ersetzt. Bei letzterem muss die Bedeutung aber klar sein. Hierfür werden Kodesysteme definiert, die sowohl die Abkürzungen - Kodes - als auch deren Bedeutung auflisten. Die Zuordnung von einzelnen Feldern in einer Datenaustauschspezifikation zu konkreten Wertelisten erfolgt mehrstufig: Die Festlegung der erlaubten Werte für ein kodiertes Attribut erfolgt über die Angabe von sog. Konzept- oder Vokabeldomänen (''Concept / Vocabulary Domains''), Kodiersystemen (''Code Systems'') und Wertemengen (''Value Sets'').
 +
 
 +
Eine '''Konzeptdomäne''' dient dazu, den Wertebereich eines Attributs einzugrenzen ohne dabei direkt schon feste Kodiersysteme oder Value Sets vorzugeben. Eine Konzeptdomäne wird durch einen Namen, eine textuelle Beschreibung sowie eine Reihe von Beispielkonzepten definiert. Zum Beispiel soll die Konzeptdomäne DocumentEntry.typeCode den Typ eines Dokuments aus Benutzersicht kodieren.
 +
 
 +
Ein '''Value Set''' ist eine eindeutige identifizierbare Sammlung von Konzeptrepräsentationen und es ist einer oder mehreren Konzeptdomänen zugeordnet. Ein Value Set kann Codes aus einem oder mehreren Kodiersystemen enthalten. Ein '''Kodiersystem''' wird dabei durch eine Liste von Codes mit zugehörigen Anzeigenamen und Beschreibungen definiert. Innerhalb eines Kodiersystems muss ein Code eine eindeutig definierte Bedeutung haben.  
  
 
Value Sets können in unterschiedlicher Art und Weise definiert werden: ''extensional'' als Sammlungen von Codes (Konzepten) oder ''intensional'' über einen berechenbaren Ausdruck, aus dem sich eine Codeliste exakt ermitteln lässt. Die Value Sets für DocumentEntry.typeCode und DocumentEntry.classCode in diesem Leitfaden sind beispielsweise extensional als Listen definiert, während das Value Set für DocumentEntry.formatCode intensional über Konstruktionsvorschriften für URNs definiert wurde.
 
Value Sets können in unterschiedlicher Art und Weise definiert werden: ''extensional'' als Sammlungen von Codes (Konzepten) oder ''intensional'' über einen berechenbaren Ausdruck, aus dem sich eine Codeliste exakt ermitteln lässt. Die Value Sets für DocumentEntry.typeCode und DocumentEntry.classCode in diesem Leitfaden sind beispielsweise extensional als Listen definiert, während das Value Set für DocumentEntry.formatCode intensional über Konstruktionsvorschriften für URNs definiert wurde.
Zeile 10: Zeile 12:
 
Wenn ein Value Set neben den genannten oder beschriebenen Codes zusätzliche Werte erlaubt, wird es als offen (''open'') bezeichnet, andernfalls als geschlossen (''closed''). Das Value Set für DocumentEntry.languageCode ist beispielsweise offen, da neue Sprachcodes gebildet und wenn notwendig auch verwendet werden können. Die Value Sets für DocumentEntry.classCode und DocumentEntry.healthcareFacilityTypeCode sind hingegen geschlossen. Das heißt, dass eine Erweiterung nur über eine neue Version der Value Sets erfolgen sollte.
 
Wenn ein Value Set neben den genannten oder beschriebenen Codes zusätzliche Werte erlaubt, wird es als offen (''open'') bezeichnet, andernfalls als geschlossen (''closed''). Das Value Set für DocumentEntry.languageCode ist beispielsweise offen, da neue Sprachcodes gebildet und wenn notwendig auch verwendet werden können. Die Value Sets für DocumentEntry.classCode und DocumentEntry.healthcareFacilityTypeCode sind hingegen geschlossen. Das heißt, dass eine Erweiterung nur über eine neue Version der Value Sets erfolgen sollte.
  
−
Die Identifikation eines Value Sets erfolgt normalerweise über eine OID. Die Version eines Value Sets wird über einen Zeitstempel charakterisiert. Die Bindung eines kodierten Elementes an ein Value Set (Binding) kann nun dynamisch (''dynamic'') oder statisch (''static'') erfolgen. Ein dynamisches Binding bezieht sich auf die jeweils aktuellste Version eines Value Sets, während bei einem statischen Binding eine feste Version angegeben wird. Bei einem statischen Binding müssen OID bzw. ein eindeutiger Bezeichner sowie ein Zeitstempel angegeben werden. Beim dynamischen Binding fehlt der Zeitstempel.  
+
Die Identifikation eines Value Sets erfolgt bei CDA und IHE XDS über eine OID, bei FHIR über eine URL. Die Version eines Value Sets wird über einen Zeitstempel charakterisiert. Die Bindung eines kodierten Elementes an ein Value Set (Binding) kann nun dynamisch (''dynamic'') oder statisch (''static'') erfolgen. Ein dynamisches Binding bezieht sich auf die jeweils aktuellste Version eines Value Sets, während bei einem statischen Binding eine feste Version angegeben wird. Bei einem statischen Binding müssen OID bzw. ein eindeutiger Bezeichner sowie ein Zeitstempel angegeben werden. Beim dynamischen Binding fehlt der Zeitstempel.
 +
 
 +
Unabhängig davon gibt es für das Binding von ValueSets noch weitere Unterscheidungsmöglichkeiten. Beim ''Design-Time Binding'' wird das zu verwendende Value Set explizit angegeben. Beim ''Runtime Binding'' werden nur die Konzeptdomäne und die sogenannte Realm (z.B. „Deutschland“) festgelegt. Das effektive Value Set wird dann dynamisch über einen Terminologieserver an Hand von Konzeptdomäne und Realm ermittelt.  
  
−
Für kodierte Elemente gibt es zwei weitere Arten von Bindungen an Value Sets. Beim ''Design-Time Binding'' wird das zu verwendende Value Set explizit angegeben. Beim ''Runtime Binding'' werden nur die Konzeptdomäne und die sogenannte Realm (z.B. „Deutschland“) festgelegt. Das effektive Value Set wird dann dynamisch über einen Terminologieserver an Hand von Konzeptdomäne und Realm ermittelt.
 
 
Bindings können verpflichtend sein (''required''), empfohlen werden (''suggested'' oder ''preferred'') oder dienen nur als Beispiel (''example''). Einzelne Werte eines Value Sets können als verpflichtend (''required''), erlaubt (''permitted'') oder ausgeschlossen (''excluded'') gekennzeichnet werden. Die in diesem Leitfaden definierten Codes besitzen alle den Status permitted.
 
Bindings können verpflichtend sein (''required''), empfohlen werden (''suggested'' oder ''preferred'') oder dienen nur als Beispiel (''example''). Einzelne Werte eines Value Sets können als verpflichtend (''required''), erlaubt (''permitted'') oder ausgeschlossen (''excluded'') gekennzeichnet werden. Die in diesem Leitfaden definierten Codes besitzen alle den Status permitted.
  
 
Die folgende Tabelle gibt eine Übersicht über die Eigenschaften der bereits definierten Value Sets:
 
Die folgende Tabelle gibt eine Übersicht über die Eigenschaften der bereits definierten Value Sets:
 +
<div class="landscape">
 
{| class="hl7table"
 
{| class="hl7table"
 
|-
 
|-
−
!XDS-Metadatum!!Beschreibung!!Definitionsart!!Erweiterbarkeit!!Bindungsstärke!!Bindungsart!!Version
+
!XDS-Metadatum!!Beschreibung!!Definitionsart!!Erweiterbarkeit!!Bindungsstärke!!Bindungsart!!Versionsbindung
 +
|-
 +
|[[Ihevs:DocumentEntry.authorRole|authorRole]] ||Rolle des Autors||extensional||open||suggested||design-time||dynamic
 +
|-
 +
|[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]] ||Fachrichtung des Autors||extensional||open||suggested||design-time||dynamic
 +
|-
 +
|[[Ihevs:DocumentEntry.classCode|classCode]] ||Dokumentenklasse||extensional||closed||suggested||design-time||dynamic
 +
|-
 +
|[[Ihevs:DocumentEntry.confidentialityCode|confidentialityCode]] ||Dokumenten-Vertraulichkeitsstufe||extensional||open||suggested||design-time||dynamic
 +
|-
 +
|[[Ihevs:DocumentEntry.eventCodeList|eventCodeList]] ||Tätigkeitskennzeichen/Zusätzliche Kennzeichnung||intensional||open||suggested||design-time||dynamic
 
|-
 
|-
 
|[[Ihevs:DocumentEntry.formatCode|formatCode]] ||Dokumentenformat||intensional||open||suggested||design-time||dynamic
 
|[[Ihevs:DocumentEntry.formatCode|formatCode]] ||Dokumentenformat||intensional||open||suggested||design-time||dynamic
 
|-
 
|-
−
|[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]] ||Erstellende Fachrichtung||extensional||closed||suggested||design-time||dynamic
+
|[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]] ||Einrichtungsart||extensional||closed||suggested|| design-time||dynamic
 
|-
 
|-
−
|[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]] ||Einrichtungsart||extensional||closed||suggested|| design-time||dynamic
+
|[[LanguageCode|languageCode]] ||Dokumentensprache||intensional||open||suggested||design-time||dynamic
 
|-
 
|-
−
|[[Ihevs:DocumentEntry.classCode|classCode]] ||Dokumentenklasse||extensional||closed||suggested||design-time||dynamic
+
|[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]] ||Erstellende Fachrichtung||extensional||closed||suggested||design-time||dynamic
 
|-
 
|-
 
|[[Ihevs:DocumentEntry.typeCode|typeCode]] ||Dokumententyp||extensional||closed||suggested||design-time||dynamic
 
|[[Ihevs:DocumentEntry.typeCode|typeCode]] ||Dokumententyp||extensional||closed||suggested||design-time||dynamic
 
|-
 
|-
−
|[[LanguageCode|languageCode]] ||Dokumentensprache||intensional||open||suggested||design-time||dynamic
+
|[[Ihevs:SubmissionSet.contentTypeCode|SubmissionSet.contentTypeCode]] ||Inhaltskennzeichen des SubmissionSets||extensional||open||suggested||design-time||dynamic
 
|-
 
|-
 
|[[Ihevs:Folder.codeList|Folder.codeList]] ||Ordnerklassifizierung||extensional||open||suggested||design-time||dynamic
 
|[[Ihevs:Folder.codeList|Folder.codeList]] ||Ordnerklassifizierung||extensional||open||suggested||design-time||dynamic
−
|-}
+
|}
 +
</div>
 +
 
 +
== Identifikation von Kodesystemen in FHIR-basierter Kommunikation ==
 +
 
 +
FHIR empfiehlt die Verwendung einer URL als primäre Identifikation eines Kodesystems. Es ist zwar grundsätzlich zulässig eine OID in ihrer URN-form, d.h. beginnend mit "urn:oid:", als Identifikation zu verwenden, aber es gilt als nicht-idiomatisch. Aus technischen Gründen können die von dieser Arbeitsgruppe erstellten Kodesysteme in ART-DECOR nicht konsistent mit einer URL versehen werden. Daher werden die in FHIR zu verwendenen Canonical URLs in der folgenden Tabelle für alle in diesem Leitfaden eingeführten Kodesysteme aufgeführt. Die OID-URNs, die in den in diesem Leitfaden inkludierten ART-DECOR Auszügen verwendet werden, sind als zusätzliche, sekundäre Identifikatoren zu verstehen.
 +
{| class="hl7table"
 +
|-
 +
!Kodesystem!!Canonical URL!!sekundärer Identifier||aus Value Set
 +
|-
 +
|Prozessrollen für Autoren||http://ihe-d.de/CodeSystems/ProzessrollenFuerAutoren||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.13||[[Ihevs:DocumentEntry.authorRole|authorRole]]
 +
|-
 +
|Patientenbeziehungsrollen für Autoren||http://ihe-d.de/CodeSystems/PatientenbeziehungsrollenFuerAutoren||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.14||[[Ihevs:DocumentEntry.authorRole|authorRole]]
 +
|-
 +
|Qualifikationen nicht ärztlicher Autoren||http://ihe-d.de/CodeSystems/QualifikationenNichtAerztlicherAutoren||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.11||[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]]
 +
|-
 +
|Facharzttitel der Ärztekammern||http://ihe-d.de/CodeSystems/FacharzttitelDerAerztekammern||urn:oid:1.2.276.0.76.5.514||[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]]
 +
|-
 +
|Qualifikatoren zahnärztlicher Autoren||http://ihe-d.de/CodeSystems/QualifikatorenZahnaerztlicherAutoren||urn:oid:1.2.276.0.76.5.492||[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]]
 +
|-
 +
|Ärztliche Berufsvarianten||http://ihe-d.de/CodeSystems/AerztlicheBerufsvarianten||urn:oid:1.2.276.0.76.5.493||[[Ihevs:DocumentEntry.authorSpecialty|authorSpecialty]]
 +
|-
 +
|Dokumentenklassen||http://ihe-d.de/CodeSystems/IHEXDSclassCode||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.8||[[Ihevs:DocumentEntry.classCode|classCode]]
 +
|-
 +
|Betroffeneneinschätzung der Vertraulichkeitsstufe||http://ihe-d.de/CodeSystems/BetroffeneneinschaetzungVertraulichkeitsstufe||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.10||[[Ihevs:DocumentEntry.confidentialityCode|confidentialityCode]]
 +
|-
 +
|Dokumenten-Warnhinweise||http://ihe-d.de/CodeSystems/DokumentenWarnhinweise||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.15||[[Ihevs:DocumentEntry.eventCodeList|eventCodeList]]
 +
|-
 +
|Fallkontext bei Dokumentenerstellung||http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.16||[[Ihevs:DocumentEntry.eventCodeList|eventCodeList]]
 +
|-
 +
|Deutsche Dokumentenformate||http://ihe-d.de/CodeSystems/DeutscheDokumentenformate||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.6||[[Ihevs:DocumentEntry.formatCode|formatCode]]
 +
|-
 +
|Einrichtungsarten der patientenbezogenen Gesundheitsversorgung||http://ihe-d.de/CodeSystems/EinrichtungsartenPatientenbezogen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.2||[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]]
 +
|-
 +
|Einrichtungsarten ausserhalb der patientenbezogenen Gesundheitsversorgung||http://ihe-d.de/CodeSystems/EinrichtungsartenNichtPatientenbezogen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.3||[[Ihevs:DocumentEntry.healthcareFacilityTypeCode|healthcareFacilityTypeCode]]
 +
|-
 +
|Ärztliche Fachrichtungen||http://ihe-d.de/CodeSystems/AerztlicheFachrichtungen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.4||[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]]
 +
|-
 +
|Nicht-ärztliche Fachrichtungen||http://ihe-d.de/CodeSystems/NichtaerztlicheFachrichtungen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.5||[[Ihevs:DocumentEntry.PracticeSettingCode|practiceSettingCode]]
 +
|-
 +
|Dokumententypen||http://ihe-d.de/CodeSystems/IHEXDStypeCode||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.9||[[Ihevs:DocumentEntry.typeCode|typeCode]]
 +
|-
 +
|Grund der Übermittlung||http://ihe-d.de/CodeSystems/GrundDerUebermittlung||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.12||[[Ihevs:SubmissionSet.contentTypeCode|SubmissionSet.contentTypeCode]]
 +
|-
 +
|Ordnertypen||http://ihe-d.de/CodeSystems/Ordnertypen||urn:oid:1.3.6.1.4.1.19376.3.276.1.5.7||[[Ihevs:Folder.codeList|Folder.codeList]]
 +
|}
 +
 
 +
{{FAQBox|
 +
'''Wie geht man mit Anforderungen nach Kodes um, die in den Value Sets nicht vorkommen?'''
 +
 
 +
Das hängt primär von der Erweiterbarkeit und der Bindungsstärke ab!
 +
 
 +
Value Set Vorgaben mit der Bindungsstärke "required" müssen verwendet werden. Bei "suggested" kann eine Alternative definiert werden, die dann genutzt werden kann. Allerdings ist hierbei zu beachten, dass man von einer Empfehlung abweicht und damit in zukünftigen Anbindungen Probleme bekommen kann.
 +
 
 +
Die Erweiterbarkeit zeigt an, ob das Value Set durch eigene Festlegungen ergänzt werden kann ("open") oder nicht ("closed"). Wenn Ergänzungen zugelassen sind, so ist ein eigenes Kodesystem zu definieren, das in das Value Set mit eingebunden wird. Auf diese Weise werden die bekannten Kodes aus dem bereits vorhandenen Kodesystem eingesetzt und nur für fehlende, aber notwendige Konzepte eigene Kodes definiert.
 +
 
 +
Eine elegantere Methode ist die Kontaktaufnahme mit dem Interoperabilitätsforum, um neue Kodes für eine Aufnahme in das offizielle Value Set vorzuschlagen. Dort werden die Vorschläge diskutiert und über einen Änderungs-/Erweiterungsvorschlag in einem Abstimmungsverfahren (Ballot) abgestimmt.
 +
}}
 +
 
 +
{{BestPracticeBox|
 +
Wie soll verfahren werden, wenn das hier beschriebene Vorgehen nicht ganz klar ist?
 +
 
 +
Das einfachste ist eine eMail an tcs@hl7.de, in der die Frage übermittelt wird. Das Interoperabilitätsforum wird versuchen, darauf schnellstmöglich eine Antwort allgemein verfügbar bereitzustellen.
 +
}}
 +
 
 
[[Kategorie:ihevs]]
 
[[Kategorie:ihevs]]

Aktuelle Version vom 29. September 2023, 11:57 Uhr

Dieses Material ist Teil des Leitfadens [[Category:|Ihevs:Vokabular-Management]].
  • Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise.
  • Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden.
  • Liste der Seiten dieses Leitfadens: [[:Category:|hier]], Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Vokabular-Management

Die Übermittlung von konkreten Daten kann auf zweierlei Art und Weise erfolgen: Die einfachste Variante ist Freitext, bei der beliebige Daten - als Zeichenkette (ggf. noch eingeschränkt auf einen bestimmten Datentyp) - übertragen werden. Dieses Verfahren bietet sich an, wenn die individuelle Ausprägung sehr unterschiedlich sein kann wie bspw. der Name des Patienten oder ein Kommentar. Für immer wiederkehrende und im Prinzip gleiche Information, wie bspw. der Familienstand, werden die zu übertragenden Daten abgekürzt und durch einen "Platzhalter" ersetzt. Bei letzterem muss die Bedeutung aber klar sein. Hierfür werden Kodesysteme definiert, die sowohl die Abkürzungen - Kodes - als auch deren Bedeutung auflisten. Die Zuordnung von einzelnen Feldern in einer Datenaustauschspezifikation zu konkreten Wertelisten erfolgt mehrstufig: Die Festlegung der erlaubten Werte für ein kodiertes Attribut erfolgt über die Angabe von sog. Konzept- oder Vokabeldomänen (Concept / Vocabulary Domains), Kodiersystemen (Code Systems) und Wertemengen (Value Sets).

Eine Konzeptdomäne dient dazu, den Wertebereich eines Attributs einzugrenzen ohne dabei direkt schon feste Kodiersysteme oder Value Sets vorzugeben. Eine Konzeptdomäne wird durch einen Namen, eine textuelle Beschreibung sowie eine Reihe von Beispielkonzepten definiert. Zum Beispiel soll die Konzeptdomäne DocumentEntry.typeCode den Typ eines Dokuments aus Benutzersicht kodieren.

Ein Value Set ist eine eindeutige identifizierbare Sammlung von Konzeptrepräsentationen und es ist einer oder mehreren Konzeptdomänen zugeordnet. Ein Value Set kann Codes aus einem oder mehreren Kodiersystemen enthalten. Ein Kodiersystem wird dabei durch eine Liste von Codes mit zugehörigen Anzeigenamen und Beschreibungen definiert. Innerhalb eines Kodiersystems muss ein Code eine eindeutig definierte Bedeutung haben.

Value Sets können in unterschiedlicher Art und Weise definiert werden: extensional als Sammlungen von Codes (Konzepten) oder intensional über einen berechenbaren Ausdruck, aus dem sich eine Codeliste exakt ermitteln lässt. Die Value Sets für DocumentEntry.typeCode und DocumentEntry.classCode in diesem Leitfaden sind beispielsweise extensional als Listen definiert, während das Value Set für DocumentEntry.formatCode intensional über Konstruktionsvorschriften für URNs definiert wurde.

Wenn ein Value Set neben den genannten oder beschriebenen Codes zusätzliche Werte erlaubt, wird es als offen (open) bezeichnet, andernfalls als geschlossen (closed). Das Value Set für DocumentEntry.languageCode ist beispielsweise offen, da neue Sprachcodes gebildet und wenn notwendig auch verwendet werden können. Die Value Sets für DocumentEntry.classCode und DocumentEntry.healthcareFacilityTypeCode sind hingegen geschlossen. Das heißt, dass eine Erweiterung nur über eine neue Version der Value Sets erfolgen sollte.

Die Identifikation eines Value Sets erfolgt bei CDA und IHE XDS über eine OID, bei FHIR über eine URL. Die Version eines Value Sets wird über einen Zeitstempel charakterisiert. Die Bindung eines kodierten Elementes an ein Value Set (Binding) kann nun dynamisch (dynamic) oder statisch (static) erfolgen. Ein dynamisches Binding bezieht sich auf die jeweils aktuellste Version eines Value Sets, während bei einem statischen Binding eine feste Version angegeben wird. Bei einem statischen Binding müssen OID bzw. ein eindeutiger Bezeichner sowie ein Zeitstempel angegeben werden. Beim dynamischen Binding fehlt der Zeitstempel.

Unabhängig davon gibt es für das Binding von ValueSets noch weitere Unterscheidungsmöglichkeiten. Beim Design-Time Binding wird das zu verwendende Value Set explizit angegeben. Beim Runtime Binding werden nur die Konzeptdomäne und die sogenannte Realm (z.B. „Deutschland“) festgelegt. Das effektive Value Set wird dann dynamisch über einen Terminologieserver an Hand von Konzeptdomäne und Realm ermittelt.

Bindings können verpflichtend sein (required), empfohlen werden (suggested oder preferred) oder dienen nur als Beispiel (example). Einzelne Werte eines Value Sets können als verpflichtend (required), erlaubt (permitted) oder ausgeschlossen (excluded) gekennzeichnet werden. Die in diesem Leitfaden definierten Codes besitzen alle den Status permitted.

Die folgende Tabelle gibt eine Übersicht über die Eigenschaften der bereits definierten Value Sets:

XDS-Metadatum Beschreibung Definitionsart Erweiterbarkeit Bindungsstärke Bindungsart Versionsbindung
authorRole Rolle des Autors extensional open suggested design-time dynamic
authorSpecialty Fachrichtung des Autors extensional open suggested design-time dynamic
classCode Dokumentenklasse extensional closed suggested design-time dynamic
confidentialityCode Dokumenten-Vertraulichkeitsstufe extensional open suggested design-time dynamic
eventCodeList Tätigkeitskennzeichen/Zusätzliche Kennzeichnung intensional open suggested design-time dynamic
formatCode Dokumentenformat intensional open suggested design-time dynamic
healthcareFacilityTypeCode Einrichtungsart extensional closed suggested design-time dynamic
languageCode Dokumentensprache intensional open suggested design-time dynamic
practiceSettingCode Erstellende Fachrichtung extensional closed suggested design-time dynamic
typeCode Dokumententyp extensional closed suggested design-time dynamic
SubmissionSet.contentTypeCode Inhaltskennzeichen des SubmissionSets extensional open suggested design-time dynamic
Folder.codeList Ordnerklassifizierung extensional open suggested design-time dynamic

Identifikation von Kodesystemen in FHIR-basierter Kommunikation

FHIR empfiehlt die Verwendung einer URL als primäre Identifikation eines Kodesystems. Es ist zwar grundsätzlich zulässig eine OID in ihrer URN-form, d.h. beginnend mit "urn:oid:", als Identifikation zu verwenden, aber es gilt als nicht-idiomatisch. Aus technischen Gründen können die von dieser Arbeitsgruppe erstellten Kodesysteme in ART-DECOR nicht konsistent mit einer URL versehen werden. Daher werden die in FHIR zu verwendenen Canonical URLs in der folgenden Tabelle für alle in diesem Leitfaden eingeführten Kodesysteme aufgeführt. Die OID-URNs, die in den in diesem Leitfaden inkludierten ART-DECOR Auszügen verwendet werden, sind als zusätzliche, sekundäre Identifikatoren zu verstehen.

Kodesystem Canonical URL sekundärer Identifier aus Value Set
Prozessrollen für Autoren http://ihe-d.de/CodeSystems/ProzessrollenFuerAutoren urn:oid:1.3.6.1.4.1.19376.3.276.1.5.13 authorRole
Patientenbeziehungsrollen für Autoren http://ihe-d.de/CodeSystems/PatientenbeziehungsrollenFuerAutoren urn:oid:1.3.6.1.4.1.19376.3.276.1.5.14 authorRole
Qualifikationen nicht ärztlicher Autoren http://ihe-d.de/CodeSystems/QualifikationenNichtAerztlicherAutoren urn:oid:1.3.6.1.4.1.19376.3.276.1.5.11 authorSpecialty
Facharzttitel der Ärztekammern http://ihe-d.de/CodeSystems/FacharzttitelDerAerztekammern urn:oid:1.2.276.0.76.5.514 authorSpecialty
Qualifikatoren zahnärztlicher Autoren http://ihe-d.de/CodeSystems/QualifikatorenZahnaerztlicherAutoren urn:oid:1.2.276.0.76.5.492 authorSpecialty
Ärztliche Berufsvarianten http://ihe-d.de/CodeSystems/AerztlicheBerufsvarianten urn:oid:1.2.276.0.76.5.493 authorSpecialty
Dokumentenklassen http://ihe-d.de/CodeSystems/IHEXDSclassCode urn:oid:1.3.6.1.4.1.19376.3.276.1.5.8 classCode
Betroffeneneinschätzung der Vertraulichkeitsstufe http://ihe-d.de/CodeSystems/BetroffeneneinschaetzungVertraulichkeitsstufe urn:oid:1.3.6.1.4.1.19376.3.276.1.5.10 confidentialityCode
Dokumenten-Warnhinweise http://ihe-d.de/CodeSystems/DokumentenWarnhinweise urn:oid:1.3.6.1.4.1.19376.3.276.1.5.15 eventCodeList
Fallkontext bei Dokumentenerstellung http://ihe-d.de/CodeSystems/FallkontextBeiDokumentenerstellung urn:oid:1.3.6.1.4.1.19376.3.276.1.5.16 eventCodeList
Deutsche Dokumentenformate http://ihe-d.de/CodeSystems/DeutscheDokumentenformate urn:oid:1.3.6.1.4.1.19376.3.276.1.5.6 formatCode
Einrichtungsarten der patientenbezogenen Gesundheitsversorgung http://ihe-d.de/CodeSystems/EinrichtungsartenPatientenbezogen urn:oid:1.3.6.1.4.1.19376.3.276.1.5.2 healthcareFacilityTypeCode
Einrichtungsarten ausserhalb der patientenbezogenen Gesundheitsversorgung http://ihe-d.de/CodeSystems/EinrichtungsartenNichtPatientenbezogen urn:oid:1.3.6.1.4.1.19376.3.276.1.5.3 healthcareFacilityTypeCode
Ärztliche Fachrichtungen http://ihe-d.de/CodeSystems/AerztlicheFachrichtungen urn:oid:1.3.6.1.4.1.19376.3.276.1.5.4 practiceSettingCode
Nicht-ärztliche Fachrichtungen http://ihe-d.de/CodeSystems/NichtaerztlicheFachrichtungen urn:oid:1.3.6.1.4.1.19376.3.276.1.5.5 practiceSettingCode
Dokumententypen http://ihe-d.de/CodeSystems/IHEXDStypeCode urn:oid:1.3.6.1.4.1.19376.3.276.1.5.9 typeCode
Grund der Übermittlung http://ihe-d.de/CodeSystems/GrundDerUebermittlung urn:oid:1.3.6.1.4.1.19376.3.276.1.5.12 SubmissionSet.contentTypeCode
Ordnertypen http://ihe-d.de/CodeSystems/Ordnertypen urn:oid:1.3.6.1.4.1.19376.3.276.1.5.7 Folder.codeList
Faq.svg Wie geht man mit Anforderungen nach Kodes um, die in den Value Sets nicht vorkommen?

Das hängt primär von der Erweiterbarkeit und der Bindungsstärke ab!

Value Set Vorgaben mit der Bindungsstärke "required" müssen verwendet werden. Bei "suggested" kann eine Alternative definiert werden, die dann genutzt werden kann. Allerdings ist hierbei zu beachten, dass man von einer Empfehlung abweicht und damit in zukünftigen Anbindungen Probleme bekommen kann.

Die Erweiterbarkeit zeigt an, ob das Value Set durch eigene Festlegungen ergänzt werden kann ("open") oder nicht ("closed"). Wenn Ergänzungen zugelassen sind, so ist ein eigenes Kodesystem zu definieren, das in das Value Set mit eingebunden wird. Auf diese Weise werden die bekannten Kodes aus dem bereits vorhandenen Kodesystem eingesetzt und nur für fehlende, aber notwendige Konzepte eigene Kodes definiert.

Eine elegantere Methode ist die Kontaktaufnahme mit dem Interoperabilitätsforum, um neue Kodes für eine Aufnahme in das offizielle Value Set vorzuschlagen. Dort werden die Vorschläge diskutiert und über einen Änderungs-/Erweiterungsvorschlag in einem Abstimmungsverfahren (Ballot) abgestimmt.
Bestpractice.svg Wie soll verfahren werden, wenn das hier beschriebene Vorgehen nicht ganz klar ist? Das einfachste ist eine eMail an tcs@hl7.de, in der die Frage übermittelt wird. Das Interoperabilitätsforum wird versuchen, darauf schnellstmöglich eine Antwort allgemein verfügbar bereitzustellen.
Abgerufen von „https://wiki.hl7.de/index.php?title=Ihevs:Vokabular-Management&oldid=80495“