ILF:XDS Metadaten (Version 3)

ELGA CDA
Implementierungsleitfäden

Registrierung von CDA Dokumenten für ELGA mit IHE Cross-Enterprise Document Sharing:
XDS Metadaten (XDSDocumentEntry)

Zur Anwendung im österreichischen
Gesundheitswesen [1.2.40.0.34.7.1.6.2]

20. März 2017

2.06.2

Entwurf

1 Informationen über dieses Dokument

1.1 Allgemeines

Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012), aber auch für medizinische Dokumente im österreichischen Gesundheitswesen.

Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit der Rechtsordnung der Republik Österreich und insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz 2000, Gesundheitstelematikgesetz 2012) zu erfolgen. Technische Möglichkeiten können gesetzliche Bestimmungen selbstverständlich nicht verändern, vielmehr sind die technischen Möglichkeiten im Einklang mit den Gesetzen zu nutzen.

<rim:Slot name="authorPerson">
  <rim:ValueList>
    <rim:Value>Name des Arztes^^^^^&1.2.276.0.76.4.16&ISO^^^^12345678</rim:Value> 
  </rim:ValueList>
</rim:Slot>

1.2 Sprachliche Gleichbehandlung

Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer und Frauen in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.

1.3 Verbindlichkeit

Review notwendig Mit der ELGA-Verordnung 2015 (in der Fassung der ELGA-VO-Nov-2015) macht die Bundesministerin für Gesundheit und Frauen die Festlegungen für Inhalt, Struktur, Format und Codierung verbindlich, die in den Implementierungsleitfäden Entlassungsbrief Ärztlich, Entlassungsbrief Pflege, Pflegesituationsbericht, Laborbefunde, Befund bildgebender Diagnostik, e-Medikation sowie XDS Metadaten (jeweils in der Version 2.06) getroffen wurden. Die anzuwendende ELGA-Interoperabilitätsstufen ergeben sich aus §21 Abs.6 ELGA-VO. Die Leitfäden in ihrer jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind von der Gesundheitsministerin auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Dokumente für ELGA wird durch das Gesundheitstelematikgesetz 2012 (GTelG 2012) und darauf basierenden Durchführungsverordnungen durch die Bundesministerin für Gesundheit und Frauen vorgegeben.

Die Verbindlichkeit und die Umsetzungsfrist dieses Leitfadens ist im Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.

Neue Hauptversionen der Implementierungsleitfäden KÖNNEN ab dem Tag ihrer Veröffentlichung durch die Bundesministerin für Gesundheit und Frauen (www.gesundheit.gv.at) verwendet werden, spätestens 18 Monate nach ihrer Veröffentlichung MÜSSEN sie verwendet werden. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.

Die Einhaltung der gesetzlichen Bestimmungen liegt im Verantwortungsbereich der Ersteller der CDA-Dokumente.

1.4 Zielgruppe

Anwender dieses Dokuments sind Softwareentwickler und Berater, die allgemein mit Implementierungen und Integrationen im Umfeld der ELGA, insbesondere der ELGA-Gesundheitsdaten, betraut sind. Eine weitere Zielgruppe sind alle an der Erstellung von CDA-Dokumenten beteiligten Personen, einschließlich der Endbenutzer der medizinischen Softwaresysteme und der Angehörigen von Gesundheitsberufen.

1.5 Hinweis auf verwendete Grundlagen

Der vorliegende Leitfaden wurde unter Verwendung der nachstehend beschriebenen Dokumente erstellt. Das Urheberrecht an allen genannten Dokumenten wird im vollen Umfang respektiert.

Dieser Standard beruht auf der Spezifikation "HL7 Clinical Document Architecture, Release 2.0", für die das Copyright © von Health Level Seven International gilt. HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria), die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden (www.hl7.at). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.

Die Vorgaben für das Österreichische Patient Summary wurden weitgehend aus dem HL7 Leitfaden für das Internationale Patient Summary entlehnt (HL7 IPS).

Dieser Leitfaden beruht auf Inhalten des LOINC® (Logical Observation Identifiers Names and Codes, siehe http://loinc.org). Die LOINC-Codes, Tabellen, Panels und Formulare unterliegen dem Copyright © 1995-2014, Regenstrief Institute, Inc. und dem LOINC Committee, sie sind unentgeltlich erhältlich. Lizenzinformationen sind unter http://loinc.org/terms-of-use abrufbar. Weiters werden Inhalte des UCUM® verwendet, UCUM-Codes, Tabellen und UCUM Spezifikationen beruhen auf dem Copyright © 1998-2013 des Regenstrief Institute, Inc. und der Unified Codes for Units of Measures (UCUM) Organization. Lizenzinformationen sind unter http://unitsofmeasure.org/trac/wiki/TermsOfUse abrufbar.

1.6 Danksagung

Die ELGA GmbH weist auf das Dokument „Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2.0 für das deutsche Gesundheitswesen“ hin, welches vom Verband der Hersteller von IT-Lösungen für das Gesundheitswesen (VHitG) herausgegeben wurde. Einige Ausführungen in dem genannten Dokument wurden in das vorliegende Dokument übernommen. Das Urheberrecht an dem Dokument „Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2.0 für das deutsche Gesundheitswesen“, wird im vollen Umfang respektiert.

1.7 Revisionsliste

Diese Version ist eine Nebenversion zur Hauptversion 2.06 und ersetzt diese. Die durchgeführten Änderungen ersehen Sie der Revisionsliste.

1.8 Weitere unterstützende Materialien

Gemeinsam mit diesem Leitfaden werden auf der Website der ELGA GmbH [1] weitere Dateien und Dokumente zur Unterstützung bereitgestellt: Beispieldokumente, zu verwendende Codes, Vorgaben zur Registrierung von CDA-Dokumenten, das Referenz-Stylesheet zur Darstellung von CDA-Dokumenten, Algorithmen zur Prüfung der Konformität von CDA-Dokumenten etc.

Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an cda@elga.gv.at[2] gesendet werden. Weitere Informationen finden Sie unter http://www.elga.gv.at/CDA.

1.9 Bedienungshinweise für die PDF-Version

Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

• Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
• Seitenweise blättern: "Bild" Tasten
• Scrollen: Pfeil nach oben bzw. unten
• Zoomen: Strg + Mouserad drehen
• Suchen im Dokument: Strg + F

1.10 Impressum

Medieneigentümer, Herausgeber, Hersteller, Verleger:
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: 01. 2127050. Internet: http://www.elga.gv.at. Email: cda@elga.gv.at.
Geschäftsführer: DI Dr. Günter Rauchegger, DI (FH) Dr. Franz Leisch

Redaktion, Projektleitung, Koordination:
Mag. Dr. Stefan Sabutsch, stefan.sabutsch@elga.gv.at

Abbildungen: © ELGA GmbH

Nutzung: Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria, Franckstrasse 41/5/14, 8010 Graz; www.hl7.at.
Die Nutzung ist zum Zweck der Erstellung medizinischer Dokumente ohne Lizenz- und Nutzungsgebühren ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter www.gesundheit.gv.at und www.elga.gv.at/cda

2 Harmonisierung

Erarbeitung des Implementierungsleitfadens
Dieser Implementierungsleitfaden entstand in Zusammenarbeit der nachfolgend genannten Personen:

Autoren
Kürzel	Organisation	Person1
Herausgeber, Projektleiter, CDA-Koordinator
SSA	ELGA GmbH	Stefan Sabutsch
Autoren
JB	CodeWerk Software Services and Development GmbH	Jürgen Brandstätter
SSA	ELGA GmbH, HL7 Austria	Stefan Sabutsch
OKU	ELGA GmbH	Oliver Kuttin
KHO	Wiener Krankenanstaltenverbund	Konrad Hölzl

¹ Personen ohne Titel

3 Einleitung

3.1 Intention und Abgrenzung

Dieses Dokument beschreibt den dokumentspezifischen Teil der Metadaten für die Registrierung von CDA-Dokumenten über IHE XDS in ELGA unter dem Aspekt der Ableitung von XDS Metadaten aus CDA Dokumenten und der Etablierung von einheitlichen Vokabularen.

Für die Registrierung von Bilddaten über XDS-I wird eine eigene Spezifikation veröffentlicht.

Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) sind nicht Teil dieser Spezifikation.

3.2 Gegenstand dieses Dokuments

Dieses Dokument definiert die Metadaten² beim Einbringen von CDA-Dokumenten³ in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)⁴. Die hier definierten Regeln sind von den folgenden „Technical Frameworks“ der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:

• Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten (Metadaten der XDSDocumentEntry Objekte)
  • IT Infrastructure (ITI), Volume 3, Rev. 10.0 (27.9.2013) Final Text
• Darüber hinaus gehende Spezifikation speziell für CDA Dokumente
  • Patient Care Coordination (PCC), Volume 2

Ausgehend von obiger Basis definiert das vorliegende Dokument die genaue Spezifikation der Befüllung der XDS Metadaten speziell für die Anwendung im Rahmen der österreichischen Gesundheitsakte ELGA.

Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.

Eine weitere Profilierung des XDS SubmissionSets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.

Die vorliegende Spezifikation wurde im Zusammenhang mit den „ELGA CDA Implementierungsleitfäden“ erstellt. Zum Zeitpunkt der Erstellung liegen folgende Implementierungsleitfäden vor:

• ELGA CDA Implementierungsleitfäden (HL7 Implementation Guide for CDA® R2):
  • „Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1]
  • „Entlassungsbrief (Ärztlich)“ [2]
  • „Pflegerischer Entlassungsbrief“ [3]
  • „Laborbefund“ [4]
  • „Befund bildgebende Diagnostik“ [5]
  • „e-Medikation“ [6]
  • „Pflegesituationsbericht“ [7]

² Daten, die andere Daten definieren und beschreiben. Eine Registry verwaltet Metadaten und ermöglicht so die Recherche nach Metadaten. Werden mehrere Registries gemeinsam genutzt, müssen die Metadaten übergreifend harmonisiert werden, bzw. Metadatenstandards bereitgestellt werden: Wertebereiche, Abhängigkeiten, Zuständigkeit, Abbildungsregeln, Versionierung und Policies.
³ HL7 Clinical Document Architecture, Release 2.0 (http://www.hl7.org)
⁴ IHE IT Infrastructure Technical Framework (http://www.ihe.net)

3.3 Hinweise zur Verwendung des Dokuments

3.3.1 Farbliche Hervorhebungen

Themenbezogene Hinweise zur besonderen Beachtung:

<Hinweis>
authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:

Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):

<BEISPIEL>
<languageCode code="de-AT" />

Verweis auf ELGA Value Set:

<Verweis>
Zulässige Werte gemäß Value Set „ELGA_FormatCode“.

3.3.2 Codesysteme und Value Sets

Die in diesem Dokument erwähnten Codesysteme bzw. Value Sets werden im Terminologieserver (https://www.gesundheit.gv.at/gesundheitssystem/professional/it-services/terminologieserver-doku) und auf der Website der ELGA GmbH (http://www.elga.gv.at) veröffentlicht.

Wenn codierte Werte angegeben werden, ist es immer die Aufgabe des Document Consumers, die korrekten lesbaren Werte anzuzeigen. Es wird nicht empfohlen, die in den XDS-Metadaten verfügbaren DisplayNames direkt zur Anzeige zur verwenden, da Schreibweisen der DisplayNames variieren oder in unterschiedlichen Sprachen angegeben sein können.

3.3.3 OID

In diesem Dokument wird an vielen Stellen die Verwendung von OID vorgeschrieben. OID sind Objekt-Identifikatoren oder Objektkennungen, die als weltweit eindeutige Namen für Informationsobjekte dienen (ISO/IEC 9834-1). Weitere Informationen zur Verwendung und Registrierung von OID sind im „OID-Portal für das Österreichische Gesundheitswesen“ publiziert (https://www.gesundheit.gv.at/OID_Frontend/).

3.4 Allgemeines zu Dokumenten in ELGA

Für die erste Umsetzungsphase von ELGA wurden die Dokumentenklassen Entlassungsbrief (Ärztlich, Pflegerisch), Laborbefund und Befunde der bildgebenden Diagnostik („Radiologiebefunde“) festgelegt. Zur Verwendung in ELGA werden diese Dokumente in standardisierte XML-Dateien im Format HL7 CDA R2 umgesetzt.

Die Vorgaben für die Erstellung der CDA-Dokumente sind die "ELGA CDA-Implemen-tierungs¬leitfäden". Nur über eine Verordnung definierte Dokumentenklassen dürfen in ELGA verwendet werden, alle Dokumente MÜSSEN entsprechend der Spezifikationen der ELGA CDA-Implementierungsleitfäden erstellt werden.

3.4.1 Dokumentlebenszyklus und XDS-Transaktionen

ELGA unterstützt die im Folgenden aufgezählten Aktionen (in Klammer die entsprechende ITI-Transaktion). Alle Transaktionen werden in den Protokollierungssystemen aufgezeichnet:

3.4.1.1 Bereitstellen [ITI-41] und Veröffentlichen [ITI-42]

Ein neues Dokument wird entsprechend IHE XDS im Repository gespeichert und durch Registrieren der XDS-Metadaten in der Registry für ELGA bereitgestellt. Neu veröffentlichte Dokument-Metadaten werden immer mit dem Status „approved“ versehen.

3.4.1.2 Ersetzen eines Dokuments durch eine neue Version („Updaten“) [ITI-41]

Änderungen eines für ELGA bereitgestellten Dokumentes sind NICHT ERLAUBT.

Es ist allerdings möglich, ein Dokument durch ein anderes zu ersetzen, indem ein neues Dokument (bzw. eine neue Version des Dokumentes) gespeichert und registriert wird, die XDS-Metadaten des bestehenden Dokumentes bekommen den Status „deprecated“. In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp „replace“ (RPLC)).

Beim Ersetzen von ELGA Dokumenten wird das ELGA Berechtigungssystem eventuell zugeordnete individuelle Zugriffsberechtigungen unabhängig von ihrer Anzahl auch auf die Nachfolgeversionen anwenden.

3.4.1.3 Stornieren [ITI-57, XDS Metadata Update]

Dokumente werden „Storniert“, indem der Dokumentstatus auf „deprecated“ gesetzt wird und keine neue Dokumentenversion registriert wird. Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.

3.4.1.4 Löschen aus der Registry [ITI-62]

Das Löschen von Dokumenten in ELGA erfolgt ausschließlich in folgenden Fällen: Löschen durch Bürger, Opt-Out, Ablauf der Aufbewahrungsdauer (nach 10 Jahren müssen Dokumente gelöscht werden). Das Löschen erfolgt i.d.R. „sicher“, sodass die Daten nicht wiederhergestellt werden können, sowohl für Verweise als auch Dokumente. Über die Transaktion ITI-62 kann ein Dokument aus der Registry gelöscht werden. Beim Löschen werden sowohl der Registereintrag als auch das Dokument aus dem Repository gelöscht; falls das Löschen der Dokumente aufgrund anderer Verpflichtungen ausgeschlossen ist, sind nur die Verweise zu löschen. Siehe „Organisationshandbuch ELGA-Bereiche und Krankenanstalten“ [8].

3.4.2 Größenbeschränkung

ELGA schreibt keine Größenbeschränkung für registrierte Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1].

3.5 Allgemeines zu XDS-Metadaten

Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumente entsprechend klassifiziert und beschrieben werden. Diese beschreibenden „Metadaten“ werden in Form einer Nachricht gemeinsam mit dem Dokument an das Repository mitgegeben. Da IHE XDS Systeme grundsätzlich für beliebige Dokumentformate offen sind, gilt dies für alle Arten von Dokumenten (CDA, PDF, Bilder, etc.) gleichermaßen.

Die Metadaten eines Dokuments (XDSDocumentEntry) in einem IHE XDS System beinhalten Informationen

• über das Dokument selbst – um eine Klassifizierung und eine korrekte Darstellung des Dokumenteninhalts zu ermöglichen
• über eventuelle Beziehungen zu anderen Dokumenten (z.B. zu älteren Versionen eines Dokuments)
• über den Speicherort des Dokuments
• über den GDA, welcher das Dokument erstellt hat
• über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).

Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE „IT-Infrastructure“ (ITI) Technical Framework, Volume 3 festgelegt (IHE ITI-TF3).

Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.

Die Metadaten sind die ausschließliche Grundlage für das Suchen und Filtern von Dokumenten in einem XDS Dokumentenregister und somit im ELGA Verweisregister, daher ist die korrekte Verschlagwortung der Dokumente mit den Metadaten eine notwendige Voraussetzung.

Hinweis: Sehen Sie auch die Vorschrift zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE „IT Infrastructure“ (ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)⁶.

⁶ http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf, zuletzt besucht am 26.3.2014

3.5.1 Metadaten aus unstrukturierten Dokumenten

Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument entnommen werden und müssen daher von der erstellenden Anwendung mitgegeben werden. Es entsteht dadurch ein zusätzlicher Aufwand insbesondere hinsichtlich der Qualität der Daten. Die Metadaten müssen das beiliegende Dokument korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.

3.5.2 Metadaten aus strukturierten Dokumenten (CDA)

Strukturierte Dokumente bieten die Möglichkeit, die Informationen für die Metadaten beim Einbringen in ein Repository in gewissem Maße aus den Dokumenten selbst automatisiert zu entnehmen. Das vermindert daher die Menge der Informationen, die separat erhoben oder ermittelt werden muss.

Die IHE hat im Rahmen des „Patient Care Coordination“ (PCC) Technical Frameworks eine genaue Vorschrift spezifiziert, aus welchen Bereichen des CDA Dokuments die Metadaten entnommen werden sollen.

Die genaue Beschreibung der einzelnen XDS Metadaten Bindings sind im IHE „Patient Care Coordination“ (PCC) Technical Frameworks Revision 9.0, Volume 2 (4.10.2013)⁷, Kapitel XDSDocumentEntry Metadata beschrieben.

⁷ http://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf, zuletzt besucht am 26.3.2014

3.5.3 Metadaten aus „On-Demand Documents“ (ODD)

Über XDS können auch Dokumente abgerufen werden, die zum Abfragezeitpunkt automatisch generiert werden. Für diese Dokumente werden Verweise in der Registry eingetragen, damit sie bei der Abfrage auch gefunden werden können. Die Metadaten von ODD unterscheiden sich notwendigerweise von den Metadaten der „stabilen Dokumente“ (SD), da sie erst bei Generierung des Dokuments vorhanden sind. Die genaue Beschreibung der für On-Demand Documents findet sich im IHE IT Infrastructure Technical Framework, Revision 12 (18.9.2015)⁸.

3.5.4 XDS Metadaten im Vergleich IHE vs. ELGA

Die vollständige Liste der XDS Metadaten Elemente kann man in folgende Arten von Elementen unterteilen:

• Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
• Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)
• Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können
• Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
  • ELGA relevante
  • Nicht ELGA relevante

Dieses Dokument behandelt nur XDS Metadaten Elemente der fett und rot markierten Kategorien.

⁸ http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf, zuletzt besucht am 08.10.2015

4 XDS Metadaten für CDA Dokumente

4.1 Überblickstabelle der XDS Metadaten

Die folgende Tabelle gibt einen Überblick über alle XDS-Metadaten-Elemente. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in IHE bzw. ELGA für das Einbringen von Dokumenten, sowie die Quelle aus der die Informationen stammen.

In der Tabelle 3 werden die XDS-Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität), jeweils für Stable Documents (SD) und On-Demand-Documents (ODD) angegeben.

Code	Bedeutung
C	Aus CDA-Inhalt abgeleitet (direkt oder indirekt, gilt nicht für On-Demand-Documents)
E1	Explizit gesetzt (ELGA relevant)
E2	Explizit gesetzt (nicht ELGA relevant)
A	Von Registry oder Repository automatisch gesetzt
B	Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt

Tabelle 1: Legende zur Spalte „Quelle“ der folgenden Tabelle

Code	Bedeutung
R	Verpflichtend („Required”)
R2	Verpflichtend wenn bekannt („Required if Known“)
O	Optional
X	Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen

Tabelle 2: Legende zur Spalte „Optionalität“ der folgenden Tabelle

Metadaten Element		Optionalität		Beschreibung	Quelle
		SD9	ODD10
Aus dem CDA-Inhalt ableitbare Metadaten
author (besteht aus den folgenden Komponenten)		R	R	Die Person, welche das Dokument verfasst hat	-
	authorInstitution	R	R	ID der Organisation der die Person angehört. (OID aus dem GDA-Index)	C
	authorPerson	R	R	Daten der Person. (Name, ID, etc.)	C
	authorRole	R2	X	Rolle der Person	C
	authorSpeciality	R2	X	Fachrichtung der Person	C
classCode		R	R	Dokumentenklasse (Oberklasse) z.B.: 18842-5 „Entlassungsbrief“	C
confidentialityCode		R	X	Vertraulichkeitscode des Dokuments	C
creationTime		R	R	Zeitpunkt der Dokumentenerstellung	C
eventCodeList		R2	R2	Liste von Gesundheitsdienstleistungen	C
intendedRecipient		O	X	Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.	C
languageCode		R	R	Sprachcode des Dokuments z.B.: "de-AT"	C
legalAuthenticator		R2	X	Rechtlicher Unterzeichner des Dokuments	C
serviceStartTime		R2	O	Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme	C
serviceStopTime		R2	O	Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung	C
sourcePatientId		R	R	Patienten ID im Informationssystem des GDA. z.B.: im KIS des KH	C
sourcePatientInfo		R	R	Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)	C
Title		R	R	Titel des Dokuments	C
typeCode11		R	R	Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, „Entlassungsbrief aus stationärer Behandlung (Arzt)“	C
uniqueId		R	R	Global eindeutige ID des Dokuments	C
referenceIdList		R	O	Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert	C
healthcareFacilityTypeCode		R	R	Klassifizierung des GDA	C
Explizit zu setzende Metadaten
availabilityStatus		R	R	Gültigkeit des Dokuments	E1
formatCode		R	R	Format des Dokumenteninhalts	E1
mimeType		R	R	Mime Type des Dokuments z.B.: „text/xml“ für CDA	E1
parentDocumentId		O12	O	Verweis auf ein referenziertes Dokument	E1
parentDocumentRelationship		O13	O	Typ der Relation zu dem referenzierten Dokument. z.B.: RPLC, XFRM	E1
practiceSettingCode		R	R	Fachliche Zuordnung des Dokuments	E1
entryUUID		R	R	UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)	E1
objectType		R	R	Typ des DocumentEntries (SD oder ODD)	E1
comments		O	O	Kommentar zum Dokument	E2
patientId		R	R	Patienten-ID in der XDS Affinity Domain	E1
Von Registry oder Repository automatisch gesetzte Metadaten
hash		R	X	Hash Wert des Dokuments. Wird vom Repository befüllt.	A
homeCommunityId		R	R	Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine „Community“, die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.	A
repositoryUniqueId		R	R	Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.	A
size		R	X	Größe des Dokuments in Bytes. Wird vom Repository befüllt.	A
URI		-14	-	Wird in XDS nicht verwendet	A
Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)
elgaFlag		R	R	Kennzeichnet ein Dokument als „ELGA-Dokument“	B
elgaHash		R	R	Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes	B

Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)

⁹ SD: „Stable Document“: Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht.
¹⁰ ODD: „On-Demand Document“: Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird.
¹¹ Der Inhalt des typeCodes soll mit dem contentTypeCode des SubmissionSets übereinstimmen.
¹² MUSS vorhanden sein, wenn eine „parentDocumentRelationship“ existiert.
¹³ MUSS gemeinsam mit einer „parentDocumentId“ angegeben sein.
¹⁴ Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.

4.2 XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet

4.2.1 author

Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).

CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist nur das jeweils erste Author-Element zu mappen.

4.2.1.1 authorInstitution

Das authorInstitution Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurde.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört grundsätzlich in folgendem Element abgelegt:
   1. ClinicalDocument/author/assignedAuthor/representedOrganization
2. Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:
   1. id[1] … ID der Organisation mit den folgenden Attributen:
      1. @root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)
      2. @extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)
   2. name … Name der Organisation als String
      Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, soll das name Element SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird.
      Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz"

1. GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente „GDA Index“ mit einer eindeutigen OID ausgestattet.
2. Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.

4.2.1.1.1 Spezifikation

authorInstitution wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$inst … ClinicalDocument/author/assignedAuthor/representedOrganization

• Fall 1:
  

Element $inst/id[1] ist vorhanden
Attribut $inst/id[1]/@root ist vorhanden
Attribut $inst/id[1]/@extension ist nicht vorhanden

concat(
$inst/name,"^^^^^^^^^",
$inst/id[1]/@root
)

<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
    <Slot name="authorInstitution">
        <ValueList>
            <Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&ISO</Value>
        </ValueList>
    </Slot>    
</Classification>

• Fall 2:
  

Element $inst/id[1] ist vorhanden
Attribut $inst/id[1]/@root ist vorhanden
Attribut $inst/id[1]/@extension ist vorhanden

concat(
$inst/name,"^^^^^&",
$inst/id[1]/@root,"&ISO^^^^"
$inst/id[1]/@extension
)

<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
    <Slot name="authorInstitution">
        <ValueList>
            <Value>Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&ISO^^^^45</Value>
        </ValueList>
    </Slot>    
</Classification>

Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß [IHE ITI-TF3].

4.2.1.2 authorPerson

Das Element authorPerson beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche das Dokument inhaltlich erstellt hat (also nicht die Schreibkraft). Mindestens eine Person

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit CDA Header Elementen:

1. Laut Festlegung wird der Autor im Header-Element „author“ abgelegt:
   1. ClinicalDocument/author/assignedAuthor
2. Der Autor (Person)
   1. Ein Personenelement enthält unter anderem die folgenden Unterelemente:
      1. id … ID der Person mit den folgenden Attributen:
         1. @root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
         2. @extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
      2. assignedPerson
         1. Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
            1. name
3. Gerät oder Software als Autor
   1. Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:
      1. assignedAuthoringDevice
         1. Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software
            1. manufacturerModelName
         2. Enthält ein Element mit dem Namen des Geräts oder der Software
            1. softwareName

4.2.1.2.1 Spezifikation für Personen

authorPerson wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$person = ClinicalDocument/author/assignedAuthor

concat(
$person/id/@extension,"^",
$person/assignedPerson/name/family,"^",
$person/assignedPerson/name/given[1],"^",
$person/assignedPerson/name/given[2],"^",
$person/assignedPerson/name/suffix,"^",
$person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;",
$person/id/@root,"&amp;ISO"
)

<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
    <Slot name="authorPerson">
        <ValueList>
            <Value>2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
            </Value>
        </ValueList>
    </Slot>    
</Classification>

Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.

Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].

4.2.1.2.2 Spezifikation für Software und Geräte

authorPerson wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$person = ClinicalDocument/author/assignedAuthor

concat(
"^",
$person/assignedAuthoringDevice/manufacturerModelName,"^",
$person/assignedAuthoringDevice/softwareName
)

<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
    <Slot name="authorPerson">
        <ValueList>
            <Value>^Good Health System^Best Health Software Application</Value>
        </ValueList>
    </Slot>
</Classification>

Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].

4.2.1.3 authorRole

Das authorRole Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.

Beispiel:

• „Diensthabender Oberarzt“
• „Verantwortlicher diensthabender Arzt für die Dokumenterstellung“

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Laut Festlegung wird die „Rolle“ der Person, welche das Dokument inhaltlich erstellt hat im Element functionCode des Autors abgelegt:
   1. ClinicalDocument/author/functionCode
2. Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden [R2].
3. Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.

4.2.1.3.1 Spezifikation

authorRole wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/functionCode/@displayName

<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
    <Slot name="authorRole">
        <ValueList>
            <Value>Diensthabender Oberarzt</Value>
        </ValueList>
    </Slot>    
</Classification>

Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer

4.2.1.4 authorSpeciality

Das authorSpeciality Element beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.

Beispiel:

• „Facharzt für Gynäkologie“
• „Facharzt für interne Medizin“

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Laut Festlegung wird die „Fachrichtung“ der Person, welche das Dokument inhaltlich erstellt hat im Element code des Autors abgelegt:
   1. ClinicalDocument/author/assignedAuthor/code
2. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden [R2].
3. Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.

4.2.1.4.1 Spezifikation

authorSpeciality wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/assignedAuthor/code/@displayName

<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
    <Slot name="authorSpeciality">
        <ValueList>
            <Value>Anästhesiologie und Intensivmedizin</Value>
        </ValueList>
    </Slot>    
</Classification>

Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer

4.2.2 classCode (und classCodeDisplayName)

Das classCode Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:

classCode	Dokumentenklasse in grober Granularität
typeCode	Dokumentenklasse in feiner Granularität. Siehe Kapitel 4.2.15

Ausgangsbasis dieses Werts ist das Element ClinicalDocument/code, welches ELGA auf hierarchische Überbegriffe (die Dokumentenklasse) gemappt werden kann. Der Wert für classCode ergibt sich aus dieser Zusammenfassung.

Vorschrift für die Zusammenfassung ClassCode - TypeCode:
Als classCode MUSS dasjenige Element des Lvl-Typ „0“ des Value Sets „ELGA_Dokumentenklassen“ angegeben werden, in dessen Unterelementen sich der Wert der Ausgangsbasis (ClinicalDocument/code) befindet. Weitere Informationen finden sich in den ELGA CDA Implementierungsleitfäden.

Beispiel:

Die Spezialisierungen des Entlassungsbriefes „Ärztlich“ und „Pflege“ werden unter dem Sammelbegriff „Entlassungsbrief“ zusammengefasst:

Lvl-Typ	Code (LOINC)	DisplayName	Deutsche Sprachvariante15	Element in XDS
0-S	18842-5	Discharge summary	Entlassungsbrief	classCode
1-L	11490-0	Physician Discharge summary	Entlassungsbrief Ärztlich	typeCode
1-L	34745-0	Nurse Discharge summary	Entlassungsbrief Pflege	typeCode

Als typeCode wird 11490-0 oder 34745-0 angegeben, als classCode entsprechend 18842-5.

¹⁵ Die deutsche Sprachvariante wird im SVS Format als Attribut „deutsch“ geführt, im CSV-Export als Spalte „meaning“.

4.2.2.1 Spezifikation

classCode (und classCodeDisplayName) wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

$typeCode = ClinicalDocument/code/@code

Mapping der Dokumentenklasse (feine Granularität) auf Sammelbegriff:
$code = Mapping-Tabelle($typeCode)
$displayName = displayName($code)
$codeSystem = fixe OID aus der Mapping-Tabelle

<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
    classifiedObject="theDocument" nodeRepresentation="$code">
    <Name>
        <LocalizedString value="$displayName"/>
    </Name>
    <Slot name="codingScheme">
        <ValueList>
            <Value>urn:oid:$codeSystem</Value>
        </ValueList>
    </Slot>
</Classification>

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste “hl7-austria-Dokumentenklassen” OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

4.2.3 confidentialityCode

Das confidentialityCode Element beschreibt die Vertraulichkeitsstufe des Dokuments.

Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf Dokumente ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt.

Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich und wird fix auf "N" (normal) gesetzt.

Es wird der Vertraulichkeitscode aus dem CDA Header Element gemäß folgender Spezifikation übernommen:

4.2.3.1 Spezifikation

confidentialityCode wird als ebRIM Slot gemäß folgendem Beispiel abgebildet:

<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
    classifiedObject="theDocument" nodeRepresentation="N">
    <Name>
        <LocalizedString value="normal"/>
    </Name>
    <Slot name="codingScheme">
        <ValueList>
            <Value>urn:oid:2.16.840.1.113883.5.25</Value>
        </ValueList>
    </Slot>
</Classification>

4.2.4 creationTime

Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:
   1. ClinicalDocument/effectiveTime
2. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
3. Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:
4. @value … enthält das Datum in folgenden möglichen Formen
   1. YYYYMMDD
   2. YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
      1. Bsp: 20081224082015+0100
      2. Für: 24.12.2008, 08:20:14, Zeitzone GMT+1

CreationTime entfällt bei On-Demand Documents.

4.2.4.1 Spezifikation

creationTime wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/effectiveTime/@value = "20200511193000+0200"

<ExtrinsicObject mimeType="text/xml"
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
    id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
    <Slot name="creationTime">
        <ValueList>
            <Value>20200511173000</Value>
        </ValueList>
    </Slot>
</ExtrinsicObject>

Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß [IHE ITI-TF3].

creationTime MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig.

Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, MUSS diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200511173000).

4.2.5 eventCodeList (und eventCodeListDisplayName)

Im Fall eines Entlassungsbriefs beschreibt dieses Element die Liste der vollbrachten Gesundheitsdienstleistungen für den im Dokument dokumentierten Patientenkontakt.

Im allgemeinen Fall eines beliebigen CDA R2 Dokuments gilt grundsätzlich folgende Verknüpfung mit den CDA Header Elementen:

1. Im CDA wird die Liste der Service-Events wie folgt abgelegt:
   1. ClinicalDocument/documentationOf/serviceEvent
2. Mehrere dieser Service-Events können durch beliebig viele „documentationOf“ Elemente ausgedrückt werden.
3. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines Service-Events verpflichtend, wenn bekannt [R2].
4. Ein serviceEvent Element in CDA beinhaltet unter anderem die folgenden Elemente:
   1. code … ein Code-Element, welches die Art des ServiceEvents angibt

Die Vorschriften zur Befüllung der CDA R2 ServiceEvents leiten sich vom Allgemeinen und vom jeweiligen speziellen CDA Implementierungsleitfäden ab. In den speziellen Implementierungsleitfäden wird definiert, ob im Service Event eine Gesundheitsdienstleistung angegeben werden muss, und welche Bedeutung dieses Element hat.

4.2.5.1 Spezifikation

eventCodeList (und eventCodeListDisplayName) wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

Für jedes documentationOf Element 1..n:

$code = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code
$displayName = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName
$codeSystem = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem

<Classification
    classificationScheme=
    "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
    classifiedObject="theDocument"
    nodeRepresentation="$code">
    <Slot name="codingScheme">
        <ValueList>
            <Value>urn:oid:$codeSystem</Value>
        </ValueList>
    </Slot>
    <Name>
        <LocalizedString value="$displayName"/>
    </Name>
</Classification>

4.2.5.2 Spezielle Vorschriften laut IHE PCC

Das PCC Profil definiert in Kapitel „Medical Document Bindings“ Spezialbehandlungen für gewissen Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC).

Diese speziellen Vorschriften werden in ELGA nicht angewandt.

4.2.6 languageCode

Das languageCode Element beschreibt den Sprachcode in dem das Dokument verfasst ist. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

4.2.6.1 Spezifikation

languageCode wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/languageCode/@code = "de-AT"

<ExtrinsicObject mimeType="text/xml"
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
    id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
    <Slot name="languageCode">
        <ValueList>
            <Value>de-AT</Value>
        </ValueList>
    </Slot>
</ExtrinsicObject>

4.2.7 legalAuthenticator

Das legalAuthenticator Element beschreibt die Identifikation und demographische Informationen der Person, welche das Dokument rechtlich verbindlich unterzeichnet hat. Entfällt bei automatisch erstellten und nicht durch natürliche Personen freigegebenen Dokumenten (z.B. On-Demand Documents wie der „Medikationsliste“).

Für CDA R2 Dokumente gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Laut Festlegung wird die Person, welche das Dokument vidiert hat, im Element „legalAuthenticator“ abgelegt:
   1. ClinicalDocument/legalAuthenticator/assignedEntity
2. Die vidierende Person
   1. Ein Personenelement in CDA beinhaltet unter anderem die folgenden Unterelemente:
      1. id … ID der Person mit den folgenden Attributen:
         1. @root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
         2. @extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
      2. assignedEntity
         1. Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
            1. Name

4.2.7.1 Spezifikation

legalAuthenticator wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$person = ClinicalDocument/legalAuthenticator/assignedEntity

concat(
$person/id/@extension,"^",
$person/assignedPerson/name/family,"^",
$person/assignedPerson/name/given[1],"^",
$person/assignedPerson/name/given[2],"^",
$person/assignedPerson/name/suffix,"^",
$person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;",
$person/id/@root,"&amp;ISO"
)

<ExtrinsicObject mimeType="text/xml"
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
    id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
    <Slot name="legalAuthenticator">
        <ValueList>
            <Value>1234^Musterdoktor^Herbert^^^Dr.^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO</Value>
        </ValueList>
    </Slot>
</ExtrinsicObject>

Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].

4.2.8 serviceStartTime / serviceStopTime

Die serviceStartTime/serviceStopTime Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts/Behandlung.

Laut ELGA Implementierungsleitfäden ist in ELGA CDA Dokumenten die Angabe von mindestens einer Gesundheitsdienstleistung (“documentationOf/serviceEvent“) verpflichtend, wenn bekannt [R2].

Wenn vorhanden, beinhaltet dieses Element die semantisch korrekten Informationen zu Start- und Enddatum gemäß der jeweiligen Fachdomäne (z.B.: das Aufnahme/Entlassungsdatum im Falle von Entlassungsbriefen aus stationärer Behandlung). Die relevanten Informationen dazu finden sich in den speziellen ELGA CDA Implementierungsleitfäden.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens einem Service-Event verpflichtend:
   1. ClinicalDocument/documentationOf/serviceEvent
2. Das Element serviceEvent beinhaltet unter anderem die folgenden Unterelemente:
   1. effectiveTime gibt das Zeitintervall an, in dem die Gesundheitsdienstleistung durchgeführt wurde
   2. Laut Vorgabe der ELGA Gesundheitsdaten SOLL ein Zeitintervall (HL7 IVL_TS) in wie folgt angeordnet werden:
      1. low … enthält das Startdatum
      2. high … enthält das Endedatum
      3. Andere im CDA möglichen Angaben (low/width, width/high, ...) sind nicht gestattet

TODO: Welches serviceEvent für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.

4.2.8.1 Spezifikation

serviceStartTime wird gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value
Bsp: 20110504120000

Hinweis:
Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig.

Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20100511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, MUSS diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20100511173000).

serviceStopTime wird gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value
Bsp: 20110510173000

Hinweis:
Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ auf andere Formate ist nicht zulässig.

Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20100511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, MUSS diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20100511173000).

4.2.9 sourcePatientId

Das sourcePatientId Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Im CDA wird die ID des Patienten in folgendem Element abgelegt:
   1. ClinicalDocument/recordTarget/patientRole/id
2. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens den folgenden zwei IDs des Patienten im CDA verpflichtend bzw. verpflichtend, wenn bekannt:
   1. id[1] … Lokale ID des Patienten vom einbringenden System
   2. d[2] … Österreichische Sozialversicherungsnummer (nur wenn bekannt)
      Achtung: Diese ID gelangt nicht in die Metadaten!

4.2.9.1 Spezifikation

sourcePatientId wird gemäß folgender Vorschrift zusammengesetzt:

concat(
ClinicalDocument/recordTarget/patientRole/id[1]/@extension, "^^^&",
ClinicalDocument/recordTarget/patientRole/id[1]/@root, "&ISO"
)
Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO

Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß [IHE ITI-TF3].

4.2.10 sourcePatientInfo

Das sourcePatientInfo Element beschreibt die demographischen Daten des Patienten. Im Fall eines CDA R2 Dokuments gilt grundsätzlich folgende Verknüpfung mit den CDA Header Elementen:

1. Laut Vorgabe der ELGA Gesundheitsdaten ist beim Patienten die Angabe der folgenden Elemente verpflichtend:
   1. Verpflichtend
      1. Lokale ID des Patienten aus dem System (id[1])
      2. Patientenname (name)
      3. Geschlecht (administrativeGender)
      4. Geburtsdatum (birthTime)
   2. Verpflichtend wenn bekannt
      1. Sozialversicherungsnummer des Patienten (id[2])
         Achtung: Diese ID gelangt nicht in die Metadaten!
      2. Adresse (addr)
         1. Beliebige Granularität

In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig. Von einer Speicherung in der Registry wird daher abgeraten.

4.2.10.1 Spezifikation (empfohlene Variante)

sourcePatientInfo wird gemäß folgender Vorschrift zusammengesetzt:

$patientRole = ClinicalDocument/recordTarget/patientRole

$id = concat( $patientRole/id[1]/@extension, "^^^&amp;", $patientRole/id[1]/@root, "&amp;ISO" ) Bsp: 4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO

$name = ""

$birthtime = ""

$gender = ""

$addr = ""

<rim:Slot name="sourcePatientInfo">
  <rim:ValueList>
    <rim:Value>PID-3|$id </rim:Value>
    <rim:Value>PID-5|$name </rim:Value>
    <rim:Value>PID-7|$birthtime </rim:Value>
    <rim:Value>PID-8|$gender </rim:Value>
    <rim:Value>PID-11|$addr </rim:Value>
  </rim:ValueList>
</rim:Slot>

4.2.10.2 Optionale Spezifikation (mit demografischen Patientendaten)

sourcePatientInfo wird gemäß folgender Vorschrift zusammengesetzt:

$patientRole = ClinicalDocument/recordTarget/patientRole

$id = concat(
$patientRole/id[1]/@extension, "^^^&",
$patientRole/id[1]/@root, "&ISO"
)
Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO


$name = concat(
$patientRole/patient/name/family,"^",
$patientRole/patient/name/given[1],"^",
$patientRole/patient/name/given[2],"^",
$patientRole/patient/name/suffix,"^",
$patientRole/patient/name/prefix[@qualifier="AC"]
)
Bsp: Mustermann^Herbert^^^Ing.

$birthtime = $patientRole/patient/birthtime/@value
Bsp: 19650120

$gender = $patientRole/patient/administrativeGenderCode/@code
Bsp: M

$addr = concat(
$patientRole/addr/streetAddressLine,"^^",
$patientRole/addr/city,"^",
$patientRole/addr/state,"^",
$patientRole/addr/postalCode,"^",
$patientRole/addr/country
)
… oder …
$addr = concat(
concat($patientRole/addr/streetName," ",$patientRole/addr/houseNumber),"^^",
$patientRole/addr/city,"^",
$patientRole/addr/state,"^",
$patientRole/addr/postalCode,"^",
$patientRole/addr/country
)
Bsp: Mustergasse 11^^Wien^W^1230^Austria
Bemerkung: Wenn die Adresse nicht in der erforderlichen Granularität zur Verfügung steht, dann wird dieses Element (PID-11) nicht angegeben.

<rim:Slot name="sourcePatientInfo">
  <rim:ValueList>
    <rim:Value>PID-3|$id</rim:Value>
    <rim:Value>PID-5|$name</rim:Value>
    <rim:Value>PID-7|$birthtime</rim:Value>
    <rim:Value>PID-8|$gender</rim:Value>
    <rim:Value>PID-11|$addr</rim:Value>
  </rim:ValueList>
</rim:Slot>

4.2.11 title

Das title Element beschreibt den lesbaren Titel des Dokuments.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumententitels verpflichtend:
   1. ClinicalDocument/title

4.2.11.1 Spezifikation

title wird gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/title
Bsp: Entlassungsbrief der chirurgischen Abteilung

Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.

4.2.12 typeCode (und typeCodeDisplayName)

Das typeCode Element beschreibt den Dokumententyp, dem das Dokument angehört. Der Dokumententyp ist die Spezialisierung einer Dokumentenklasse, jeder Dokumententyp gehört zu genau einer Dokumentenklasse.

Unterscheidung typeCode/classCode:

typeCode	Dokumentenklasse in feiner Granularität (Spezialisierung).
classCode	Dokumentenklasse in grober Granularität. Siehe Kapitel classCode

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:
   1. ClinicalDocument/code
2. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentencodes ein verpflichtendes Element.
3. Ein Code-Element in CDA beinhaltet unter anderem die folgenden Attribute:
   1. @code … Codierter Wert der Dokumentenklasse
      1. Bsp: Code „11490-0“
   2. @displayName … Lesbarer Wert der Dokumentenklasse
      1. Bsp: „Discharge summarization note (physician)”
   3. @codeSystem … Codierter Wert des zugrundliegenden Codesystems
      1. Bsp: „2.16.840.1.113883.6.1“
4. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe dieser 3 Attribute des Elements code verpflichtend.

Zulässige Werte gemäß Value Set „ELGA_ Dokumentenklassen“.
Als typeCode MUSS das passende Element aus dem Lvl-Typ „1“ des Value Sets „ELGA_Dokumentenklassen“ angegeben werden, weitere Informationen finden sich in den ELGA CDA Implementierungsleitfäden.

4.2.12.1 Spezifikation

typeCode (und typeCodeDisplayName) wird gemäß folgender Vorschrift zusammengesetzt:

$code = ClinicalDocument/code/@code
$displayName = ClinicalDocument/code/@displayName
$codeSystem = ClinicalDocument/code/@codeSystem

<rim:Classification
  classificationScheme=
      "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
  classifiedObject="theDocument"
  nodeRepresentation="$code"
>
  <rim:Name>
    <rim:LocalizedString value="$displayName"/>
  </rim:Name>
  <rim:Slot name="codingScheme">
    <rim:ValueList>
      <rim:Value>urn:oid:$codeSystem</rim:Value>
    </rim:ValueList>
  </rim:Slot>
</rim:Classification>

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste “hl7-austria-Dokumentenklassen” OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

4.2.12.2 submissionSet.contentTypeCode

Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.

4.2.13 uniqueId

Das uniqueId Element beschreibt den global eindeutigen Identifier des Dokuments. Dieser Identifier wird entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer ID für das Dokument verpflichtend:
   1. ClinicalDocument/id

4.2.13.1 Spezifikation

uniqueId wird gemäß folgender Vorschrift zusammengesetzt:

Fall 1
Attribut ClinicalDocument/id/@extension ist nicht vorhanden

concat(ClinicalDocument/id/@root)
Bsp: 1.2.3.4.5.6.7.8.9

Fall 2
Attribut ClinicalDocument/id/@extension ist vorhanden

concat(
ClinicalDocument/id/@root, "^",
ClinicalDocument/id/@extension
)
Bsp: 1.2.3.4.5.6.7.8.9^0815

4.2.14 referenceIdList

Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommen.

Im Rahmen von ELGA ist die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten einzubringen. Weitere andere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.

Aus dem „Allgemeinen Implementierungsleitfaden“ [1]: „Die setId bezeichnet das Set von Dokumenten, die zu einer Reihe von Versionen gehören. Sie bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten).“

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Laut Vorgabe der ELGA Dokumenten Leitfäden ist die Angabe einer setId für das Dokument verpflichtend:
   1. ClinicalDocument/setId

4.2.14.1 Spezifikation

Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.

Dieser Datentyp ist in IHE_ITI_TF_Rev10.0_Vol3_FT_2013-09-27 in der Table 4.2.3.1.7-2: Data Types in folgender Weise spezifiziert:

Data Type	Source Standard	Encoding Specification
CX	HL7 V2.5 Identifier	This is an identifier. HL7 Identifier type CX consists of several components, but this specification restricts them to the use of two components, the Id Number, and the Assigning Authority (AA). The Assigning Authority identifies the "domain" over which the Id Number represents a unique entity. Furthermore, the AA is characterized by a Universal Id and Universal Id Type. In Document Sharing profiles, ISO Object Identifiers (see OID below) must be used as Universal Id. Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
CXi	HL7 V2 Identifier	This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components. CXi.1 shall be present and hold the identifier value. CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above. CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value. When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above. No other components shall be present.

ACHTUNG: Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.

Beispiel:

referenceIdList wird gemäß folgender Vorschrift zusammengesetzt:

<ClinicalDocument xmlns=„urn:hl7-org:v3“>
…
<id root="1.2.40.0.34.99.111.1.1" extension="BBBBBBBBBBBBBBBBBB"/>
…
<setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZZZZZ"/>
<versionNumber value="2"/> 
…
</ClinicalDocument>

concat(ClinicalDocument/setId/@extension, "^^^", ClinicalDocument/setId/@root, "^", "urn:elga:iti:xds:2014:ownDocument_setId", "^", homeCommunityId)

Bitte beachten Sie, dass sowohl die ClinicalDocument/setId/@root als auch die homeCommunityId in der Schreibweise „&“, OID-Wert, „&ISO“ anzugeben sind.

Aus dem Beispiel oben wird daher folgender CXi Wert erstellt:

"ZZZZZZZZZZZZZZZZZZZ^^^&amp;1.2.40.0.34.99.111.1.1&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"

Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.

Folgend ein weiteres Beispiel unter Verwendung einer UUID in ClinicalDocument/setId:

<ClinicalDocument xmlns=„urn:hl7-org:v3“>
…
<id root="1.2.40.0.34.99.111.1.1" extension="BBBBBBBBBBBBBBBBBB"/>
…
<setId root="2.25" extension="urn:uuid:19FEE6C3-6B35-4C5B-B1CC-2B5B4001AB2"/>
<versionNumber value="2"/> 
…
</ClinicalDocument>

Wiederum gilt die Vorgabe:

concat(ClinicalDocument/setId/@extension, "^^^", ClinicalDocument/setId/@root, "^", "urn:elga:iti:xds:2014:ownDocument_setId", "^", homeCommunityId)

Daher würde sich in diesem Fall folgender CXi Wert ergeben:

"urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"

4.2.15 intendedRecipient

Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der intendedRecipient notwendig. Derzeit wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.

Der intendedRecipient entfällt bei On-Demand Documents.

4.3 XDS Metadaten 2: explizit zu setzen (ELGA relevant)

4.3.1 availabilityStatus

Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Dokuments.

Mögliche Werte laut IHE sind:

• Approved
• Deprecated

Dieses Attribut ist im Zuge des Einbringens von neuen Dokumenten („Submission“) immer auf “Approved” gesetzt.

4.3.2 formatCode (und formatCodeDisplayName)

Das formatCode Element beschreibt das Format des Dokuments bezüglich seiner semantischen Interoperabilität. Es ermöglicht einem empfangenden System (Document Consumer Actor) die Identifizierung des für die Weiterverarbeitung zu erwartenden Dokumentenformats und somit die korrekte Darstellung und Verarbeitung des Dokuments.

Im CDA-Schema steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung, die Information lässt sich aber gegebenenfalls aus dem Element clinicalDocument.templateId ableiten.

4.3.2.1 Dokumente in ELGA Interoperabilitätsstufe „Basic“ und „Structured“

Die Angabe der ELGA-Interoperabilitäts-Stufe erfolgt durch den entsprechenden Formatcode (EIS_Basic) gemäß der in ELGA gültigen Formatcodes, beschrieben im Value Set „ELGA_FormatCode_VS“ (OID 1.2.40.0.34.10.61).

In den XDS-Metadaten wird nicht zwischen den EIS Basic“ und „Structured“ unterschieden, da sie sich hinsichtlich der technischen und semantischen Interoperabilität gleich verhalten.

Die Angabe des eingebetteten Dokuments ist zusätzlich notwendig, siehe 4.3.2.3.

4.3.2.2 Dokumente in ELGA Interoperabilitätsstufe „Enhanced“ und „Full Support“

Die Angabe erfolgt gemäß der Liste der in ELGA gültigen Formatcodes mit zusätzlicher Angabe der ELGA-Interoperabilitäts-Stufe (EIS „Enhanced“, …).

Zulässige Werte gemäß Value Set „ELGA_FormatCode_VS“.
(aus der Codeliste ELGA_FormatCode 1.2.40.0.34.5.37)

Beispiele:

• urn:elga:dissum:2011:EIS_Enhanced
  • Gemäß dem Implementierungsleitfaden „Ärztlicher Entlassungsbrief“ [2], im ELGA-Interoperabilitätsstufe „Enhanced“ (Mindest-Stufe für strukturierte Dokumentinhalte).
• urn:elga:lab:2011:EIS_FullSupport
  • Gemäß dem Implementierungsleitfaden „Laborbefund“ [4], im ELGA-Interoperabilitätsstufe „Full Support“..

4.3.2.3 Dokumente in ELGA Interoperabilitätsstufe „Basic“: Zusatz erforderlich

Folgt ein ELGA CDA Dokument einem Implementierungsleitfaden einer Fachdomäne in ELGA-Interoperabilitätsstufe „Basic“, so enthält dieses Dokument entweder unstrukturierten oder strukturierten Text gemäß CDA Level 1 oder ein eingebettetes Objekt (PDF, JPEG-Grafik, etc.).

Alle in ELGA-CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDF/A 1a (gemäß „ISO 19005-1:2005 Level A conformance“) entsprechen.

Bemerkung: Folgt das Dokument lediglich den Basisanforderungen im Allgemeinen Implementierungsleitfaden „CDA Dokumente im österreichischen Gesundheitswesen“ [1], so liegt das Dokument implizit immer in der ELGA Interoperabilitätsstufe „Basic“ vor.

Im Fall eines Dokuments in ELGA Interoperabilitätsstufe „Basic“ MUSS der formatCode ebenfalls das „Format“ des unstrukturierten/eingebetteten Inhalts beinhalten. Das Format MUSS mittels „:“ (Doppelpunkt) am Ende angefügt werden.

Zulässige Zusätze gemäß Value Set „ELGA_FormatCodeZusatz_VS“.

Beispiel:

• urn:elga:dissum:2015-v2.06:EIS_Basic:PDF
  

Gemäß dem Implementierungsleitfaden „Entlassungsbrief Ärztlich“ [2], im ELGA-Interoperabilitätslevel „Basic“/„Structured“, das eingebettete Objekt liegt als im PDF/A vor.

4.3.2.4 Zusatz bei selbst-definierten maschinenlesbaren Elementen (Dokumente in EIS „Enhanced“ oder „Full Support“)

Liegt ein CDA Dokument in ELGA Interoperabilitätsstufe „Enhanced“ oder „Full Support“ vor und enthält das Dokument zusätzliche selbst-definierte maschinenlesbare Elemente (CDA Level 3 oder „Entries“)', so ist dies durch den Zusatz eines Plus-Zeichens („+“) im Formatcode zu kennzeichnen.

Die Kennzeichnung von Dokumenten mit selbst-definierten maschinenlesbaren Elementen ist ein „+“ (Plus-Zeichen) am Ende des Formatcodes.

Beispiele:

• urn:elga:dissum-n:2015-v2.06:EIS_Enhanced+
• urn:elga:lab:2015-v2.06:EIS_FullSupport+

4.3.2.5 Bildungsregel für den formatCodeDisplayName

Der formatCodeDisplayName ist analog zum formatCode aus den displayNames der entsprechenden Value Sets zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels „:“ (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).

Beispiele:

• ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF
• ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+
• ELGA Laborbefund, EIS Full Support v2.06+

4.3.2.6 Spezifikation

formatCode (und formatCodeDisplayName) wird gemäß folgender Vorschrift zusammengesetzt:
$code = gemäß Liste der in ELGA gültigen FormatCodes
$displayName = gemäß Liste der in ELGA gültigen FormatCodes
$codeSystem = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37

<rim:Classification
  classificationScheme=
      "urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
  classifiedObject="theDocument"
  nodeRepresentation="$code"
>
  <rim:Name>
    <rim:LocalizedString value="$displayName"/>
  </rim:Name>
  <rim:Slot name="codingScheme">
    <rim:ValueList>
      <rim:Value>urn:oid:$codeSystem</rim:Value>
    </rim:ValueList>
  </rim:Slot>
</rim:Classification>

4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)

Das healthcareFacilityTypeCode Element beschreibt die Klassifizierung des GDA.

Es wird der Code aus dem CDA Header Element "healthCareFacility" gemäß folgender Spezifikation

übernommen:

4.3.3.1 Spezifikation

healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName) wird gemäß folgender Vorschrift zusammengesetzt:

$code = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code

$displayName = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName

$codeSystem = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem

<rim:Classification
  classificationScheme=
      "urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
  classifiedObject="theDocument"
  nodeRepresentation="$code"
>
  <rim:Name>
    <rim:LocalizedString value="$displayName"/>
  </rim:Name>
  <rim:Slot name="codingScheme">
    <rim:ValueList>
      <rim:Value>urn:oid:$codeSystem</rim:Value>
    </rim:ValueList>
  </rim:Slot>
</rim:Classification>

4.3.4 mimeType

Das mimeType Element beschreibt den „Internet Media Type“ des Dokuments gemäß dem „Multipurpose Internet Mail Extensions“ (MIME) Standard. Der Standard wird beschrieben in RFC 2045¹⁶ bis RFC 2049¹⁷.

Im Fall von CDA R2 Dokumenten ist der Mime Type laut IHE immer fix "text/xml".

4.3.4.1 Spezifikation

mimeType wird gemäß folgender Vorschrift gespeichert.

Folgende Mime-Types sind für Dokumente zugelassen:
CDA R2: text/xml
DICOM/KOS: application/dicom

<rim:ExtrinsicObject mimeType="text/xml"
	id="urn:uuid:<entryUUID>" 
	objectType=
		"urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
>

4.3.5 parentDocumentId, parentDocumentRelationship

Das parentDocumentId Element verweist auf das Dokument, zu dem das eingebrachte Dokument in einer bestimmten Relation steht.

Das parentDocumentRelationship Element beschreibt den Typ der Relation (Versionierung, Transformation).

Da nicht alle lokalen und temporären Versionen eines Dokuments veröffentlicht werden müssen, können die tatsächlichen und technischen Dokumentenverweise in XDS nicht über die parentDocumentId erfasst werden, sondern über Association-Objekte.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

1. Im CDA werden die Informationen über Dokumente, die mit dem eingebrachten Dokumenten in einer bestimmten Relation stehen, in folgendem Element abgelegt:
   1. ClinicalDocument/relatedDocument
2. Der Typ der Relation MUSS verpflichtend in folgendem Attribut angegeben werden:
   1. ClinicalDocument/relatedDocument/@typeCode
   2. Folgende Relationen sind in ELGA erlaubt (siehe „Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente“ [1]):
      1. Versionierung (RPLC)
3. Das zugrundeliegende Dokument (auf welches die Art der Relation wirkt), wird in folgendem Element angegeben:
   1. ClinicalDocument/relatedDocument/parentDocument

¹⁶ http://tools.ietf.org/html/rfc2045
¹⁷ http://tools.ietf.org/html/rfc2049

4.3.5.1 Spezifikation

parentDocumentId MUSS mit folgenden Elementen in CDA übereinstimmen:

concat(
ClinicalDocument/relatedDocument/parentDocument/id/@root,"^",
ClinicalDocument/relatedDocument/parentDocument/id/@extension
)

parentDocumentRelationship MUSS mit folgenden Elementen in CDA übereinstimmen:

ClinicalDocument/relatedDocument/@typeCode

4.3.6 practiceSettingCode (und practiceSettingCodeDisplayName)

Das practiceSettingCode Element beschreibt die fachliche Zuordnung des Dokumentes. Es SOLL den Fachbereich wiedergeben, dem der Inhalt des Dokuments am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung.

Im CDA-Schema steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.

Zulässige Werte gemäß Value Set „ELGA_PracticeSetting_VS“.

4.3.6.1 Spezifikation

practiceSettingCode (und practiceSettingCodeDisplayName) wird gemäß folgender Vorschrift zusammengesetzt:

$code = Code aus ELGA_PracticeSetting
$displayName = Klartext des angegebenen Codes (displayName)
$codeSystem = OID des Codesystems (1.2.40.0.34.5.12)

<rim:Classification
  classificationScheme=
      "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
  classifiedObject="theDocument"
  nodeRepresentation="$code"
>
  <rim:Name>
    <rim:LocalizedString value="$displayName"/>
  </rim:Name>
  <rim:Slot name="codingScheme">
    <rim:ValueList>
      <rim:Value>urn:oid:$codeSystem</rim:Value>
    </rim:ValueList>
  </rim:Slot>
</rim:Classification>

4.3.7 objectType

Das objectType Element gibt den Typ des Dokuments wieder, entweder ein „stabiles Dokument“ (stable document, SD) oder ein „On-demand Dokument“ (on-demand document, ODD). Der Datentyp ist eine UUID.

Zulässige Werte:
urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 (Stable Document)
urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248 (On-Demand Document)

4.4 ELGA-spezifische Erweiterungen der XDS-Metadaten

Die folgenden Daten entsprechen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information.

4.4.1 elgaFlag

Das elgaFlag dient zur Kennzeichnung eines Dokuments als „ELGA-Dokument“¹⁸. Ein XDS Source des ELGA-Bereiches sendet eine „XDS.b Provide and Register Transaktion [ITI-41]“, eine „XDS.b Register Document Transaktion [ITI-42]“ oder eine „XDS Update Document [ITI-57]“ an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut „elgaFlag“ entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. „elgaFlag“ kann folgende Werte annehmen:

• "true" oder
• "false"

4.4.1.1 Spezifikation

  <rim:Slot name="urn:elga-bes:elgaFlag">
    <rim:ValueList>
      <rim:Value>true</rim:Value>
    </rim:ValueList>
  </rim:Slot>

¹⁸ Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.

4.4.2 elgaHash

Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine „XDS.b Provide and Register Transaktion [ITI-41]“, eine „XDS.b Register Document Transaktion [ITI-42]“ oder eine „XDS Update Document [ITI-57]“ an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot „ELGA-Hash“ gespeichert.

Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.

4.4.2.1 Spezifikation

  <rim:Slot name="urn:elga-bes:elgaHash">
    <rim:ValueList>
      <rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>
    </rim:ValueList>
  </rim:Slot>

5 Anhänge

5.1 Referenzen

[1]	ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente.
	ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.1.6], http://www.elga.gv.at
[2]	ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Ärztlicher Entlassungsbrief.
	ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.2.6], http://www.elga.gv.at
[3]	ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Entlassungsbrief Pflege. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.3.6], http://www.elga.gv.at
	ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente.
	ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.1.6], http://www.elga.gv.at
[4]	ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Laborbefund.
	ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.4.6], http://www.elga.gv.at
[5]	ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Befund bildgebende Diagnostik.
	ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.5.6], http://www.elga.gv.at
[6]	ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: e-Medikation.
	ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.8.6], http://www.elga.gv.at
[7]	ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2:
	Pflegesituationsbericht (2.06) [OID 1.2.40.0.34.7.12.6], http://www.elga.gv.at
[8]	ELGA GmbH (2015) Organisationshandbuch.
	ELGA-Bereiche und Krankenanstalten (2.2.1) [OID 1.2.40.0.34.3.1.2.1.32], http://www.elga.gv.at

5.2 Revisionsliste

Vers.	Datum	Änderungsgrund
0.05	16.05.2011	Ergebnisse aus dem technischen Online-Meeting
2.00 Beta	12.08.2011	Erster „Release candidate“ des Dokuments für internen Review innerhalb der Arbeitsgruppe.
2.00 rc1	30.08.2011	Redaktionelle Überarbeitung.
2.00 FWGD	10.10.2011	Fertigstellung des „Final Working Group Draft“. Veröffentlicht für öffentlichen Review.
2.01	11.06.2012	Fertigstellung der gültigen Version 2.01 „Final“. Abgrenzung des Geltungsbereiches (XDS­Do­cu­ment­Entry), Überarbeitung „Practice­Setting­Code“, Hinweis zu OID eingefügt (1.2.3), Überarbeitung der „parent­Document­Relationship“, Typos ausgebessert
2.01	21.12.2012	Layout-Anpassung
2.01a	07.03-2013	Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16: "dieses Dokuments“ eingefügt; 363: displayNameOf($code), „Of“ gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch „2“-> „Enhanced“ etc.) Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt Allgemein: Typos ausgebessert
2.02	12.08.2013	2.3.2 Präzisierung der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessert.
2.02	12.08.2013	2.3.2.3 PDF/A-1a-Vorschrift hinzugefügt
2.02	13.08.2013	Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF/A-1a-
2.02	17.09.2013	Typos, Formatierung und Seitenumbrüche ausgebessert
2.02a	06.02.2014	Beispiele in Tabelle 3 korrigiert
2.03	26.02.2014	Definition von ReferenceIdList eingefügt
2.03	03.03.2014	Definition von intendedRecipient eingefügt
2.03	03.03.2014	Änderungen in Tabelle 3: LegalAuthenticator – von [R] auf [R2] geändert IntendedRecipient – von "-" auf [O] geändert, für Verwendung mit XDW vorgesehen ReferenceIdList hinzugefügt Den Namen des Value Sets von „ELGA-PracticeSettingCode“ auf „ELGA-PracticeSettingCode-vs“ geändert
2.03.	03.03.2014	Anhang gelöscht: 3.1. IHE ITI-TF3, Kapitel 4.1.7 „Document Definition Metadata“ 3.2. IHE PCC-TF2, Kapitel 4.1.1 „XDSDocumentEntry Metadata“ 3.3. IHE XDS Data Types
2.03	03.03.2014	Korrekturen: ITI Version einheitlich geändert auf “(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)“. 1.1.3 Hinweis auf Terminologieserver hinzugefügt Tabelle 3 angepasst: EntryUUID Beschreibung geändert patientId Beschreibung geändert
2.03	06.03.2014	Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId
2.03	21.03.2014	Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt
2.03	26.03.2014	Kapitel 1.4. Korrektur von Dokumentverweisen
2.03a	28.03.2014	Kapitel 2.1 Korrektur von Fußnotennummern
2.03a	28.03.2014	Kapitel 2.2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000
2.03b	1.7.2014	Den Namen des Value Sets von „ELGA-PracticeSetting Code-vs“ auf „ELGA_Practicesetting_VS“ korrigiert
2.03b	11.07.2014	2.3.2.5 OID in der Spezifikation ergänzt
2.03b	11.07.2014	2.3.6 OID in der Spezifikation ergänzt
2.03b	05.08.2014	2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert
2.03b	06.08.2014	2.1 Überblickstabelle: ParentDocumentId und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]
2.03b	06.08.2014	Referenzen auf CDA Implementierungsleitfäden aktualisiert
Version 2.05
2.05	03.11.2014	EntryUUID als „ELGA-Relevant“ klassifiziert. Darstellung der Übersichtstabelle geändert
2.05	03.11.2014	2.2.15 TypeCode: ClassificationScheme im Beispiel korrigiert von "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" (falsch) auf "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" (richtig)
2.05	19.11.2014	2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht
2.05	19.11.2014	2.2.2. authorPerson: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.
2.05	19.11.2014	2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden
2.05	19.11.2014	2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software
2.05	24.11.2014	2.2.1.1. Spezifikation von authorInstitution: Fall entfernt, in dem die ID des GDA unbekannt ist. Die OID des GDA ist für ELGA-CDA [M]
2.05	26.11.2014	2.4 ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und ELGA-Flag. Auch in 2.1 entsprechend angegeben.
2.05	12.03.2014	Seite 2-3: Absätze „Verbindlichkeit“, „Hinweise zur Verwendung“ und „Erarbeitung des Implementierungsleitfadens“ hinzugefügt.
Version 2.06
2.06	19.05.2015	1.2.2. Codesysteme und Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.
2.06	13.10.2015	1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch
2.06	13.10.2015	1.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.
2.06	07.10.2015	1.4.3. Kapitel „Metadaten aus „On-Demand Documents“ (ODD)“ eingefügt
2.06	10.09.2015	2.1 Tabelle 3: Beschreibung der entryUUID ergänzt
2.06	07.10.2015	2.1 Tabelle 3: Spalte „Optionalität IHE“ gelöscht, Spalte zur Definition von On-Demand-Documents eingefügt. objectType hinzugefügt patientid als E1 „ELGA relevant“ deklariert (war E2)
2.06	30.10.2015	2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt wird, falls mehrere ID-Elemente angegeben sind.
2.06	19.05.2015	2.2.5. und 2.2.15: Typos verbessert
2.06	29.10.2015	2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt
2.06	21.07.2015	2.2.10. legalAuthenticator: Hinweis, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar ist.
2.06	08.10.2015	2.3.7 objectType hinzugefügt
Version 2.06.2 (Nebenversion) x …betrifft Implementierung (erste Spalte)
	01.08.2016	Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
	18.5.2016	1.2 Erklärung zur Verwendung von XDS Folder und SubmissionSet hinzugefügt.
	01.08.2016	2.1. Tabelle 3: Korrektur der Optionalität von eventCodeList auf [R2], wie im Text bei 2.2.8 angegeben
x	14.6.2016	creationTime, serviceStartTime, serviceStopTime: Präzisierung der Vorgaben für Datum/Zeit, sie MUSS immer entsprechen der Angabe in CDA entweder 8 oder 14-stellig angegeben werden.
	03.08.2016	2.2.5, 2.3.2.2, 2.3.2.5, 2.3.5, 2.3.5.1, 2.3.5.1, 2.1, 1.4, 2.2.7, 2.2.11, 2.2.15, 2.3.6, 1.4.1.2 Korrektur der Großschreibung bei normativen Vorgaben
	05.01.2017	2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.
	y	Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&"
	y	Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
	y	Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
	y	Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.
	y	Kapitel 4.3.3 "healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.