{{DocumentPart}}
=Einleitung=

== Hintergrund ==

Die IHE-Profile zum einrichtungsübergreifenden Austausch medizinischer Dokumente (XDS – Cross-Enterprise Document Exchange, XDR, XDM) werden in Projekten in ganz Deutschland verwendet. Sie stellen eine moderne, internationale Grundlage für den elektronischen Austausch medizinischer Dokumente im Gesundheitswesen dar. Das [[IHE DE Cookbook]] beschreibt sehr ausführlich, wie verschiedene [[IHE Integrationsprofile]] zu einem komplexen Use Case zusammengebaut und eingesetzt werden können. Zum besseren Wiederfinden, zur leichteren Anzeige, Auswertung und Archivierung sollten die ausgetauschten Dokumente mit einer Reihe von beschreibenden Codes indexiert werden. Daher schreiben die Profile einen umfangreichen Satz an Metadaten (wie z.B. Fachrichtung, Einrichtungsart und Dokumententyp) zur Beschreibung der medizinischen Dokumente vor. Die internationalen IHE-Profile geben hier jedoch keine konkreten Terminologien vor, um die häufig sehr landestypischen Konzepte (z.B. ein MVZ als Einrichtungsart) abzubilden.

== Aufgaben der Metadaten ==
Die Metadaten erfüllen im Wesentlichen folgende Aufgaben:
* Identifizierung des Patienten, auf den sich das Dokument bezieht
* Beschreibung der Herkunft des Dokuments
* Gewährleistung von Sicherheit und Vertraulichkeit der Dokumente
* inhaltlichen Beschreibung, um die Dokumente möglichst schnell und zuverlässig wiederzufinden und um eine einfach navigierbare Aktensicht aufzubauen
* Beschreibung des Lebenszyklus des Dokumentes, beispielsweise, ob es noch aktuell ist oder durch ein anderes Dokument ersetzt wurde
* Erleichterung des Austauschs der Dokumente (z.B. MIME – Type oder das Dokumentenformat)

== Beispiel für die Verwendung und das Zusammenspiel der Metadaten ==

In einem Krankenhaus wird von einem Radiologen ein Radiologie-Befund im Format PDF erstellt. Diesem werden nun folgende Metadaten zugeordnet:
* DocumentEntry.classCode: Befund (BEF)
* DocumentEntry.formatCode: application/pdf
* DocumentEntry.healthcareFacilityTypeCode: Krankenhaus (KHS)
* DocumentEntry.practiceSettingCode: Radiologie (RADI)
* DocumentEntry.typeCode: Ergebnisse Bildgebende Diagnostik ()

Diese Metadaten werden in der XDS Registry gespeichert und können für die Suche nach den Dokumenten genutzt werden. Beispielsweise können alle Radiologie-Befunde gefunden werden, indem in der XDS Registry nach XDSDocumentEntry.classCode = „Befund“, XDSDocumentEntry.typeCode = „Ergebnisse Bildgebende Diagnostik“ und XDSDocumentEntry.practiceSettingCode = „Radiologie“ gesucht wird. Zur korrekten Anzeige der Dokumente sind weitere Informationen über den XDSDocumentEntry.formatCode und den XDSDocumentEntry.mimeType notwendig.

== Ziel des Projekts ==
Ziel des Projektes ist die Erarbeitung gemeinsamer Metadaten, damit die unterschiedlichen IHE XDS Projekte in Deutschland in Zukunft auch überregional einfacher Dokumente austauschen können und um neuen Projekten einen schnelleren Einstieg zu ermöglichen.

Folgende Value Sets sollen bereitgestellt werden:

* DocumentEntry.authorRole
* DocumentEntry.authorSpeciality
* DocumentEntry.classCode
* DocumentEntry.typeCode
* DocumentEntry.codeList
* DocumentEntry.confidentialityCode
* DocumentEntry.contentTypeCode
* DocumentEntry.eventCodeList
* DocumentEntry.formatCode
* DocumentEntry.healthcareFacilityTypeCode
* DocumentEntry.practiceSettingCode
* DocumentEntry.languageCode
* Folder.codeList
* SubmissionSet.contentTypeCode

== Vorgehensweise ==

Zur Definition der Value Sets wurde eine Arbeitsgruppe aus Vertretern von Kliniken (Anwendern) und Herstellern von Anwendungssystemen gebildet. Diese Arbeitsgruppe „Value Sets“ ist Teil der „Cookbook“-Initiative von IHE Deutschland, deren Ziel es ist, die Nutzung moderner IHE-Profile durch die Beschreibung von „Lösungs-Rezepten“ für Deutschland zu vereinfachen.

Innerhalb der Arbeitsgruppe wurden zunächst die Value Sets identifiziert, deren Abstimmung als besonders hoch priorisiert wurde. Dazu zählen:

* Einrichtungsart (DocumentEntry.healthcareFacilityTypeCode) der erstellenden Institution
* Fachrichtung (DocumentEntry.practiceSettingCode) der erstellenden Institution
* Dokumentenklasse (DocumentEntry.classCode) zur Beschreibung des Inhalts
* Dokumententyp (DocumentEntry.typeCode) zur Beschreibung des Inhalts
* Dokumentenformat (DocumentEntry.formatCode) zur leichteren Dokumentenverarbeitung
* Dokumentensprache (DocumentEntry.languageCode) zur Beschreibung der Dokumentensprache

Zur Erarbeitung der Value Sets wurde ein Use Case erstellt, der beschreibt, welche Dokumente typischerweise während des Krankheitsverlaufes eines Herzinfarkts erstellt werden, und zwischen wem sie ausgetauscht werden. Parallel dazu wurde zunächst recherchiert, ob es bestehende Kodiersysteme gibt, aus denen die Value Sets jeweils gebildet werden können. Dazu wurden bestehende Dokumentenklassen und Dokumententypen aus verschiedenen Kliniken gesammelt. Dabei konnte auch auf Vorarbeiten eines Archivierungsdienstleisters, der für viele Kliniken konsolidierte Dokumentenklassen definiert hat, zurückgegriffen werden. Zusätzlich wurden LOINC-Codes auf ihre Verwendbarkeit hin geprüft. Für die Beschreibung der Fachrichtungen wurde auf die Weiterbildungsordnung für Ärzte zurückgegriffen.
Da in vielen Fällen keine kostenfreien Codesysteme die gestellten Anforderungen erfüllen konnten, wurden neue Codesysteme erstellt. Dabei wurde ein konzeptorientierter Ansatz verfolgt, d.h. die Arbeitsgruppe identifizierte zuerst die notwendigen Konzepte, entwickelte dann präzise Definitionen für die Konzepte und vergab zuletzt ein eindeutiges Kürzel. Die Praxistauglichkeit dieser Value Sets wurde anhand des Use Cases, sowie anhand vieler Beispiele aus der Berufspraxis der Arbeitsgruppen-Teilnehmer überprüft und verbessert.

Diese Vorschläge sollen nun national mit allen Interessierten abgestimmt werden. Daher lädt die Arbeitsgruppe dazu ein, sich an der Kommentierung der Value Sets zu beteiligen. Eine IHE Mitgliedschaft ist nicht notwendig um Kommentare einzureichen.

Zur Kommentierung stehen vom 23. Mai bis 26.Juni 2016:
* Einrichtungsart (DocumentEntry.healthcareFacilityTypeCode)
* Fachrichtung (DocumentEntry.practiceSettingCode)
* Dokumentenklasse (DocumentEntry.classCode)
* Dokumententyp (DocumentEntry.typeCode)
* Dokumentenformat (DocumentEntry.formatCode)

Die Arbeitsgruppe wird alle Kommentare bewerten und anschließend die Value Sets mit den resultierenden Änderungen erneut veröffentlichen.

== Verbindlichkeit der Value Sets ==

Die in diesem Leitfaden eingeführten Value Sets sind für Deutschland momentan nicht verbindlich, sondern stellen eine Empfehlung von IHE Deutschland dar.

== Änderung und Pflege ==

Änderung und Pflege der hier vorgestellten Value Sets erfolgt durch die IHE Deutschland Arbeitsgruppe "Value Sets".

[[Kategorie:ihevs]]

Ihevs:Einleitung

2016-05-17T10:20:36Z

Pgeibel: /* Vorgehensweise */

{{DocumentPart}}
=Einleitung=

== Hintergrund ==

Die IHE-Profile zum einrichtungsübergreifenden Austausch medizinischer Dokumente (XDS – Cross-Enterprise Document Exchange, XDR, XDM) werden in Projekten in ganz Deutschland verwendet. Sie stellen eine moderne, internationale Grundlage für den elektronischen Austausch medizinischer Dokumente im Gesundheitswesen dar. Das [[IHE DE Cookbook]] beschreibt sehr ausführlich, wie verschiedene [[IHE Integrationsprofile]] zu einem komplexen Use Case zusammengebaut und eingesetzt werden können. Zum besseren Wiederfinden, zur leichteren Anzeige, Auswertung und Archivierung sollten die ausgetauschten Dokumente mit einer Reihe von beschreibenden Codes indexiert werden. Daher schreiben die Profile einen umfangreichen Satz an Metadaten (wie z.B. Fachrichtung, Einrichtungsart und Dokumententyp) zur Beschreibung der medizinischen Dokumente vor. Die internationalen IHE-Profile geben hier jedoch keine konkreten Terminologien vor, um die häufig sehr landestypischen Konzepte (z.B. ein MVZ als Einrichtungsart) abzubilden.

== Aufgaben der Metadaten ==
Die Metadaten erfüllen im Wesentlichen folgende Aufgaben:
* Identifizierung des Patienten, auf den sich das Dokument bezieht
* Beschreibung der Herkunft des Dokuments
* Gewährleistung von Sicherheit und Vertraulichkeit der Dokumente
* inhaltlichen Beschreibung, um die Dokumente möglichst schnell und zuverlässig wiederzufinden und um eine einfach navigierbare Aktensicht aufzubauen
* Beschreibung des Lebenszyklus des Dokumentes, beispielsweise, ob es noch aktuell ist oder durch ein anderes Dokument ersetzt wurde
* Erleichterung des Austauschs der Dokumente (z.B. MIME – Type oder das Dokumentenformat)

== Beispiel für die Verwendung und das Zusammenspiel der Metadaten ==

In einem Krankenhaus wird von einem Radiologen ein Radiologie-Befund im Format PDF erstellt. Diesem werden nun folgende Metadaten zugeordnet:
* DocumentEntry.classCode: Befund (BEF)
* DocumentEntry.formatCode: application/pdf
* DocumentEntry.healthcareFacilityTypeCode: Krankenhaus (KHS)
* DocumentEntry.practiceSettingCode: Radiologie (RADI)
* DocumentEntry.typeCode: Ergebnisse Bildgebende Diagnostik ()

Diese Metadaten werden in der XDS Registry gespeichert und können für die Suche nach den Dokumenten genutzt werden. Beispielsweise können alle Radiologie-Befunde gefunden werden, indem in der XDS Registry nach XDSDocumentEntry.classCode = „Befund“, XDSDocumentEntry.typeCode = „Ergebnisse Bildgebende Diagnostik“ und XDSDocumentEntry.practiceSettingCode = „Radiologie“ gesucht wird. Zur korrekten Anzeige der Dokumente sind weitere Informationen über den XDSDocumentEntry.formatCode und den XDSDocumentEntry.mimeType notwendig.

== Ziel des Projekts ==
Ziel des Projektes ist die Erarbeitung gemeinsamer Metadaten, damit die unterschiedlichen IHE XDS Projekte in Deutschland in Zukunft auch überregional einfacher Dokumente austauschen können und um neuen Projekten einen schnelleren Einstieg zu ermöglichen.

Folgende Value Sets sollen bereitgestellt werden:

* DocumentEntry.authorRole
* DocumentEntry.authorSpeciality
* DocumentEntry.classCode
* DocumentEntry.typeCode
* DocumentEntry.codeList
* DocumentEntry.confidentialityCode
* DocumentEntry.contentTypeCode
* DocumentEntry.eventCodeList
* DocumentEntry.formatCode
* DocumentEntry.healthcareFacilityTypeCode
* DocumentEntry.practiceSettingCode
* DocumentEntry.languageCode
* Folder.codeList
* SubmissionSet.contentTypeCode

== Vorgehensweise ==

Zur Definition der Value Sets wurde eine Arbeitsgruppe aus Vertretern von Kliniken (Anwendern) und Herstellern von Anwendungssystemen gebildet. Diese Arbeitsgruppe „Value Sets“ ist Teil der „Cookbook“ Initiative von IHE Deutschland, deren Ziel es ist, die Nutzung moderner IHE-Profile durch die Beschreibung von „Lösungs-Rezepten“ für Deutschland zu vereinfachen.

Innerhalb der Arbeitsgruppe wurden zunächst die Value Sets identifiziert, deren Abstimmung als besonders hoch priorisiert wurde. Dazu zählen:

* Einrichtungsart (DocumentEntry.healthcareFacilityTypeCode) der erstellenden Institution
* Fachrichtung (DocumentEntry.practiceSettingCode) der erstellenden Institution
* Dokumentenklasse (DocumentEntry.classCode) zur Beschreibung des Inhalts
* Dokumententyp (DocumentEntry.typeCode) zur Beschreibung des Inhalts
* Dokumentenformat (DocumentEntry.formatCode) zur leichteren Dokumentenverarbeitung
* Dokumentensprache (DocumentEntry.languageCode) zur Beschreibung der Dokumentensprache

Zur Erarbeitung der Value Sets wurde ein Use Case erstellt, der beschreibt, welche Dokumente typischerweise während des Krankheitsverlaufes eines Herzinfarkts erstellt werden, und zwischen wem sie ausgetauscht werden. Parallel dazu wurde zunächst recherchiert, ob es bestehende Kodiersysteme gibt, aus denen die Value Sets jeweils gebildet werden können. Dazu wurden bestehende Dokumentenklassen und Dokumententypen aus verschiedenen Kliniken gesammelt. Dabei konnte auch auf Vorarbeiten eines Archivierungsdienstleisters, der für viele Kliniken konsolidierte Dokumentenklassen definiert hat, zurückgegriffen werden. Zusätzlich wurden LOINC-Codes auf ihre Verwendbarkeit hin geprüft. Für die Beschreibung der Fachrichtungen wurde auf die Weiterbildungsordnung für Ärzte zurückgegriffen.
Da in vielen Fällen keine kostenfreien Codesysteme die gestellten Anforderungen erfüllen konnten, wurden neue Codesysteme erstellt. Dabei wurde ein konzeptorientierter Ansatz verfolgt, d.h. die Arbeitsgruppe identifizierte zuerst die notwendigen Konzepte, entwickelte dann präzise Definitionen für die Konzepte und vergab zuletzt ein eindeutiges Kürzel. Die Praxistauglichkeit dieser Value Sets wurde anhand des Use Cases, sowie anhand vieler Beispiele aus der Berufspraxis der Arbeitsgruppen-Teilnehmer überprüft und verbessert.

Diese Vorschläge sollen nun national mit allen Interessierten abgestimmt werden. Daher lädt die Arbeitsgruppe dazu ein, sich an der Kommentierung der Value Sets zu beteiligen. Eine IHE Mitgliedschaft ist nicht notwendig um Kommentare einzureichen.

Zur Kommentierung stehen vom 23. Mai bis 26.Juni 2016:
* Einrichtungsart (DocumentEntry.healthcareFacilityTypeCode)
* Fachrichtung (DocumentEntry.practiceSettingCode)
* Dokumentenklasse (DocumentEntry.classCode)
* Dokumententyp (DocumentEntry.typeCode)
* Dokumentenformat (DocumentEntry.formatCode)

Die Arbeitsgruppe wird alle Kommentare bewerten und anschließend die Value Sets mit den resultierenden Änderungen erneut veröffentlichen.

== Verbindlichkeit der Value Sets ==

Die in diesem Leitfaden eingeführten Value Sets sind für Deutschland momentan nicht verbindlich, sondern stellen eine Empfehlung von IHE Deutschland dar.

== Änderung und Pflege ==

Änderung und Pflege der hier vorgestellten Value Sets erfolgt durch die IHE Deutschland Arbeitsgruppe "Value Sets".

[[Kategorie:ihevs]]

Diskussion:Ihevs:Einleitung

2016-05-17T10:18:53Z

Pgeibel:

Diskussion:Ihevs:Einleitung

2016-05-17T10:16:30Z

Pgeibel:

2016-05-17T08:34:58Z

Pgeibel: /* Vokabular-Management */

Ihevs:Vokabular-Management

2016-05-17T08:33:01Z

Pgeibel: /* Vokabular-Management */

2016-05-17T08:05:19Z

Pgeibel: /* Vokabular-Management */

{{DocumentPart}}
=Vokabular-Management=

[[Kategorie:ihevs]]

Die Festlegung der Werte für ein kodiertes Attribut erfolgt über die Angabe von Konzeptdomänen (Concept Domains), Kodiersystemen (Code Systems) und Value Sets. Eine Konzeptdomäne dient dazu, den Wertebereich eines Attributs einzugrenzen ohne 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 DocumentEntry.typeCode laut dem IHE IT Infrastructure Technical Framework 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 Kodes 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 werden können. Die Value Sets für DocumentEntry.classCode und DocumentEntry.typeCode sind hingegen geschlossen. D.h., 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.

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 der sog. Realm festgelegt (z.B. der Realm „Deutschland“). Das effektive Value Set wird dann dynamisch über einen Terminologieserver an Hand von Konzeptdomäne und Realm ermittelt.
Bindings können verpflichtend sein (requested), 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:
{| class="hl7table"
|-
!XDS-Metadatum!!Beschreibung!!Definitionsart!!Erweiterbarkeit!!Bindungsstärke!!Bindungsart!!Version
|-
|formatCode||Dokumentenformat||intensional||open||suggested||design-time||dynamic

|-
|practiceSettingCode||Erstellende Fachrichtung||extensional||closed||suggested||design-time||dynamic

|-
|healthcareFacilityTypeCode||Einrichtungsart||extensional||closed||suggested|| design-time||dynamic

|-
|classCode||Dokumentenklasse||extensional||closed||suggested||design-time||dynamic

|-
|typeCode||Dokumententyp||extensional||closed||suggested||design-time||dynamic

|-
|languageCode||Sprachcode||intentsional||open||suggested||design-time||dynamic

|-}

Ihevs:Vokabular-Management

2016-05-12T12:40:57Z

Pgeibel: /* Vokabular-Management */

{{DocumentPart}}
=Vokabular-Management=

[[Kategorie:ihevs]]

Die Festlegung der Werte für ein kodiertes Attribut erfolgt über die Angabe von Konzeptdomänen (Concept Domains), Kodiersystemen (Code Systems) und Value Sets. Eine Konzeptdomäne dient dazu, den Wertebereich eines Attributs einzugrenzen ohne 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 DocumentEntry.typeCode laut dem IHE IT Infrastructure Technical Framework 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 Kodes 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 oder intensional über Berechnungsvorschriften und Beschreibungen. 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 werden können. Die Value Sets für DocumentEntry.classCode und DocumentEntry.typeCode sind hingegen geschlossen. D.h., 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.

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 der sog. Realm festgelegt (z.B. der Realm „Deutschland“). Das effektive Value Set wird dann dynamisch über einen Terminologieserver an Hand von Konzeptdomäne und Realm ermittelt.
Bindings können verpflichtend sein (requested), 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:

{| class="hl7table"
|-
!XDS-Metadatum!!Beschreibung!!Definitionsart!!Erweiterbarkeit!!Bindungsstärke!!Bindungsart!!Version
|-
|formatCode||Dokumentenformat||intensional||open||suggested||design-time||dynamic

|-
|practiceSettingCode||Erstellende Fachrichtung||extensional||closed||suggested||design-time||dynamic

|-
|healthcareFacilityTypeCode||Einrichtungsart||extensional||closed||suggested|| design-time||dynamic

|-
|classCode||Dokumentenklasse||extensional||closed||suggested||design-time||dynamic

|-
|typeCode||Dokumententyp||extensional||closed||suggested||design-time||dynamic

|-
|languageCode||Sprachcode||intentsional||open||required||design-time||dynamic

|-}