XDS-Metadaten (Version 3.0.1+20211001)

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche
[unmarkierte Version][geprüfte Version]
(Überblickstabelle der XDS-I Metadaten für DICOM KOS Objekte)
K
 
(388 dazwischenliegende Versionen von 6 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 
{{#seo:
 
{{#seo:
|title=XDS Metadaten 2020
+
|title=XDS Metadaten 3.0.1
 
|titlemode=append
 
|titlemode=append
 
|keywords= XDS Metadaten, Metadaten, XDS, CDA, CDA Dokumente
 
|keywords= XDS Metadaten, Metadaten, XDS, CDA, CDA Dokumente
 
|description=Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS).  
 
|description=Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS).  
 
}}
 
}}
{{#customtitle:XDS Metadaten 2020}}
+
{{#customtitle:XDS-Metadaten (Version 3.0.1+20211001)}}
{{Underconstruction}}
 
 
<!--
 
<!--
         Implementierungsleitfaden "XDS Metadaten 2020"
+
        {{Underconstruction}}
 +
-->
 +
<!--
 +
         Implementierungsleitfaden "XDS-Metadaten (Version 3)"
 
  -->
 
  -->
  
Zeile 40: Zeile 42:
  
 
{{Infobox Dokument
 
{{Infobox Dokument
|Group    = ELGA CDA Implementierungsleitfäden
+
|Group    = Implementierungsleitfaden XDS-Metadaten (XDSDocumentEntry)
|Title    = ELGA XDS Metadaten (XDSDocumentEntry)
+
|Title    = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA (Version 3)
|Subtitle  = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA [1.2.40.0.34.7.6.7]
+
|Subtitle  = Zur Anwendung im österreichischen Gesundheitswesen [1.2.40.0.34.7.6.9.3]
|Short    = XDS Metadaten  
+
|Short    = XDS-Metadaten  
 
|Namespace = elga-cdaxds-2.06.2
 
|Namespace = elga-cdaxds-2.06.2
 
|Type      = Implementierungsleitfaden
 
|Type      = Implementierungsleitfaden
|Version  = 3.0.0
+
|Version  = 3.0.1+20211001
 
|Submitted = ELGA GmbH
 
|Submitted = ELGA GmbH
|Date      = Februar 2021
+
|Date      = 01.10.2021
 
|Copyright = 2011-
 
|Copyright = 2011-
|Status    = Kommentierung
+
|Status    = Normativ
 
|Period    = n.a.
 
|Period    = n.a.
|OID      = 1.2.40.0.34.7.6.7
+
|OID      = 1.2.40.0.34.7.6.9.3
 
|Realm    = Austria
 
|Realm    = Austria
 
}}
 
}}
 +
 
{{TOC limit|4}}
 
{{TOC limit|4}}
 
<!--
 
<!--
Zeile 62: Zeile 65:
 
<!--
 
<!--
 
{{Infobox Contributors Begin}}
 
{{Infobox Contributors Begin}}
{{Contributor | Logo = Logo.jpg | Name = Abc | Location = Hürth }}
+
{{Contributor | Logo = Logo.jpg | Name = Abc | Location = Wien}}
 
{{Infobox Contributors End}}
 
{{Infobox Contributors End}}
 
  -->
 
  -->
Zeile 76: Zeile 79:
 
}
 
}
 
}}
 
}}
 
 
=Zusammenfassung=
 
=Zusammenfassung=
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
Dieses Dokument beschreibt die IHE XDS Metadaten (XDSDocumentEntry), die für die Registrierung von CDA Dokumenten in der ELGA Infrastruktur notwendig sind und wie sie aus den CDA Dokumenten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden XDS-Metadaten-Guide im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
+
Dieses Dokument beschreibt die IHE XDS Metadaten (XDSDocumentEntry), die für die Registrierung von Befunden (HL7 CDA) und Bilddaten (DICOM KOS) in der ELGA Infrastruktur notwendig sind und wie sie aus den zugrundeliegenden Informationsobjekten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden [https://wiki.hl7.at/index.php?title=ILF:XDS_Metadaten_Guide XDS-Metadaten-Guide] im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
 
{{EndYellowBox}}
 
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für elektronische Dokumente der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti IHE ITI]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref>.
+
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für die Registrierung elektronischer Dokumente in der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012)<ref name="GTelG">Gesundheitstelematikgesetz 2012 [https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20008120 https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20008120]</ref>. Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti https://www.ihe.net/resources/technical_frameworks/#iti]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref> sowie DICOM Key Object Selection Documents (in Folge KOS)<ref  name="DICOM">NEMA PS3 / ISO 12052, Digital Imaging and Communications in Medicine (DICOM®) Standard, National Electrical Manufacturers Association, Rosslyn, VA, USA. Unter ständiger Weiterentwicklung, die aktuelle Version ist frei verfügbar auf http://dicom.nema.org/).</ref>.
 
 
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.<br />
 
TODO: XDSi-Metadaten einfügen https://collab.dicom-austria.at/pages/viewpage.action?pageId=20709391&preview=/20709391/20709392/AnbindungBilddaten_Gesamtarchitektur.pdf
 
  
 
=Informationen über dieses Dokument=
 
=Informationen über dieses Dokument=
Zeile 124: Zeile 123:
 
Die Verwendung dieses Leitfadens für die Zwecke der Erstellung, des Verkaufs und des Betriebs von Computerprogrammen, sofern nicht anders angegeben oder sich die Standards auf andere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen, ist ausdrücklich genehmigt. <br />
 
Die Verwendung dieses Leitfadens für die Zwecke der Erstellung, des Verkaufs und des Betriebs von Computerprogrammen, sofern nicht anders angegeben oder sich die Standards auf andere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen, ist ausdrücklich genehmigt. <br />
  
Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> . <br />
+
Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> .  
 
+
<!-- Seitenumbruch -->
 
+
<p style="page-break-before: always"></p>
 
===Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")===
 
===Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")===
 
<div style="border: thin #77c123 solid;width:100%; margin-left: 10px">
 
<div style="border: thin #77c123 solid;width:100%; margin-left: 10px">
Zeile 147: Zeile 146:
 
Die Verbindlichkeit und die Umsetzungsfrist von Leitfäden sind im Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.  
 
Die Verbindlichkeit und die Umsetzungsfrist von Leitfäden sind im Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.  
  
Ein Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten („Mandatory“ (M), „Required“ (R) und „Fixed“ (F)), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.  
+
Ein Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf [http://www.gesundheit.gv.at www.gesundheit.gv.at] zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten ("Mandatory" [M], "Required" [R] und "Fixed" [F]), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.  
  
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.
+
Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit österreichischem und europäischem Recht, insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz, Gesundheitstelematikgesetz 2012, DSGVO) 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.
  
 
Die Einhaltung der gesetzlichen Bestimmungen liegt im Verantwortungsbereich der Ersteller der CDA-Dokumente.
 
Die Einhaltung der gesetzlichen Bestimmungen liegt im Verantwortungsbereich der Ersteller der CDA-Dokumente.
  
 
==Verwendete Grundlagen und Bezug zu anderen Standards==
 
==Verwendete Grundlagen und Bezug zu anderen Standards==
Grundlage dieses Implementierungsleitfadens ist der internationale Standard IHE ITI Cross-enterprise Document Sharing <ref name="IHE ITI"></ref> von Integrating the Healthcare Enterprise (IHE)<ref name="IHE">Integrating the Healthcare Enterprise (IHE) International, Incorporated [http://www.ihe.net]</ref>
+
Grundlage dieses Implementierungsleitfadens ist der internationale Standard IHE ITI Cross-enterprise Document Sharing <ref name="IHE ITI"></ref> von Integrating the Healthcare Enterprise (IHE)<ref name="IHE">Integrating the Healthcare Enterprise (IHE) International, Incorporated [http://www.ihe.net http://www.ihe.net]</ref>.
  
Weiters bezieht sich dieser Leitfaden auf den internationalen Standard "HL7® Clinical Document Architecture, Release 2.0" (CDA ®)<ref name="CDA"></ref> , für die das Copyright © von Health Level Seven International<ref name="HL7">Health Level Seven International [http://www.hl7.org www.hl7.org]</ref> gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert<ref name="ISO CDA">ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical Document Architecture, Release 2 [https://www.iso.org/standard/44429.html]</ref>. CDA definiert die Struktur und Semantik von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und Patienten. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen.  
+
Weiters bezieht sich dieser Leitfaden auf den internationalen Standard "HL7® Clinical Document Architecture, Release 2.0" (CDA ®)<ref name="CDA"></ref>, für die das Copyright © von Health Level Seven International<ref name="HL7">Health Level Seven International [http://www.hl7.org www.hl7.org]</ref> gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert<ref name="ISO CDA">ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical Document Architecture, Release 2 [https://www.iso.org/standard/44429.html https://www.iso.org/standard/44429.html]</ref>. CDA definiert die Struktur und Semantik von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und Patienten. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen.  
Die Dokumentmetadaten für CDA Dokumente im Österreichischen Gesundheitswesen werden grundsätzlich vom "Allgemeinen CDA Implementierungsleitfaden" <ref name="ALF">Allgemeiner Implementierungsleitfaden für CDA Dokumente [ILF:Allgemeiner_Implementierungsleitfaden_2020]</ref> definiert.
+
Die Dokumentmetadaten für CDA Dokumente im Österreichischen Gesundheitswesen werden grundsätzlich vom "Allgemeinen CDA Implementierungsleitfaden"<ref name="ALF">Allgemeiner Implementierungsleitfaden für CDA Dokumente [https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_(Version_3) https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_(Version_3)]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://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 HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden. 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.
 
{{BeginILFBox}}
 
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020]'''.
+
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens Version 3]''' und gilt entsprechend für alle CDA-Dokumente, die auf Basis des Leitfadens erstellt werden.
 
{{EndILFBox}}
 
{{EndILFBox}}
  
 
==Wichtige unterstützende Materialien==
 
==Wichtige unterstützende Materialien==
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
Auf der Website TODO: [[ILF:Ambulanzbefund_Guide|Ambulanzbefund Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
+
Auf der Website: [[ILF:XDS_Metadaten_Guide|XDS Metadaten Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
 
* die PDF-Version dieses Leitfadens
 
* die PDF-Version dieses Leitfadens
* Beispieldokumente
 
* Schematron-Prüfregeln
 
* Design-Beispiele
 
 
{{EndYellowBox}}
 
{{EndYellowBox}}
 
Gemeinsam mit diesem Leitfaden werden auf der Website der ELGA GmbH ([http://www.elga.gv.at/CDA Website der ELGA GmbH]) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:
 
Gemeinsam mit diesem Leitfaden werden auf der Website der ELGA GmbH ([http://www.elga.gv.at/CDA Website der ELGA GmbH]) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:
  
 +
*ELGA-Gesamtarchitektur<ref name="ELGA-Gesamtarchitektur">ELGA-Gesamtarchitektur 2.30a [http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>
 
*Beispieldokumente
 
*Beispieldokumente
 
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
 
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
Zeile 180: Zeile 177:
 
*Hinweise für die zu verwendenden Terminologien
 
*Hinweise für die zu verwendenden Terminologien
 
*Leitfaden zur richtigen Verwendung von Terminologien
 
*Leitfaden zur richtigen Verwendung von Terminologien
 
 
 
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}
 
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}
<br />
 
  
 
==Bedienungshinweise==
 
==Bedienungshinweise==
===Farbliche Hervorhebungen und Hinweise===
+
===Farbliche Hervorhebungen===
 
''<u>Themenbezogene Hinweise zur besonderen Beachtung:</u>''
 
''<u>Themenbezogene Hinweise zur besonderen Beachtung:</u>''
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
'''Hinweis:'''<br />Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden
+
'''<Hinweis>'''<br/>authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
 
{{EndYellowBox}}
 
{{EndYellowBox}}
''<u>Hinweis auf anderen Implementierungsleitfaden:</u>''
+
''<u>Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):</u>''
{{BeginILFBox}}
 
'''Verweis'''<br />Verweis auf den Allgemeinen Leitfaden:…
 
{{EndILFBox}}
 
''<u>Themenbezogenes CDA Beispiel-Fragment im XML Format:</u>''
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
 
<BEISPIEL>
 
<BEISPIEL>
 
<languageCode code="de-AT" />
 
<languageCode code="de-AT" />
 
</pre>
 
</pre>
 +
''<u>Verweis auf ELGA Value Set:</u>''
 +
{{BeginILFBox}}
 +
'''<Verweis>'''<br/>Zulässige Werte gemäß Value Set '''"ELGA_FormatCode".'''
 +
{{EndILFBox}}
 +
  
 
<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">
 
<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">
Zeile 214: Zeile 209:
 
</div></div>
 
</div></div>
  
<!-- Seitenumbruch -->
+
 
<p style="page-break-before: always"></p>
 
<!-- Tatsächlicher Inhalt -->
 
  
  
Zeile 222: Zeile 215:
  
 
=Harmonisierung=
 
=Harmonisierung=
'''Erarbeitung des Implementierungsleitfadens'''<br/>
+
'''Erarbeitung des Implementierungsleitfadens'''<br />
 
Dieser Implementierungsleitfaden entstand in Zusammenarbeit der nachfolgend genannten Personen:
 
Dieser Implementierungsleitfaden entstand in Zusammenarbeit der nachfolgend genannten Personen:
  
 
{| class="wikitable"  
 
{| class="wikitable"  
 
|-  
 
|-  
! style="text-align:left" colspan="3"| Autoren
+
! colspan="2" style="text-align:left" |Autoren
 +
|-
 +
! style="text-align:left" width="10%" |Organisation|| style="text-align:left" width="60%" |Person<sup>1</sup>
 +
|- style="background:#FFEBAD"
 +
| colspan="2" style="text-align:left" |Herausgeber, Projektleiter, CDA-Koordinator
 +
|-
 +
|ELGA GmbH||Stefan Sabutsch
 +
|- style="background:#FFEBAD"
 +
| colspan="2" style="text-align:left" |Autoren
 +
|-
 +
|CodeWerk Software Services and Development GmbH||Jürgen Brandstätter
 +
|-
 +
|DICOM Austria
 +
|Emmanuel Helm
 +
|-
 +
|DICOM Austria
 +
|Silvia Winkler
 +
|-
 +
|ELGA GmbH, HL7 Austria||Stefan Sabutsch
 +
|-
 +
|ELGA GmbH||Oliver Kuttin
 +
|-
 +
|ELGA GmbH
 +
|Stefan Repas
 
|-  
 
|-  
! style="text-align:left" width="10%" | Kürzel  ||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person<sup>1</sup>
+
|Wiener Krankenanstaltenverbund||Konrad Hölzl
|-  style="background:#FFEBAD"
 
| style="text-align:left"  colspan="3" |  Herausgeber, Projektleiter, CDA-Koordinator
 
|- style="background:#FFFFFF"
 
| SSA  || ELGA GmbH || Stefan Sabutsch
 
|-  style="background:#FFEBAD"
 
| style="text-align:left"  colspan="3" | Autoren
 
|- style="background:#FFFFFF"
 
| JB|| CodeWerk Software Services and Development GmbH|| Jürgen Brandstätter
 
|- style="background:#FFFFFF"
 
| SSA|| ELGA GmbH, HL7 Austria||Stefan Sabutsch
 
|- style="background:#FFFFFF"
 
| OKU|| ELGA GmbH|| Oliver Kuttin
 
|- style="background:#FFFFFF"
 
| KHO|| Wiener Krankenanstaltenverbund|| Konrad Hölzl
 
 
|}
 
|}
  
 
<sup>1</sup> Namen ohne Titel
 
<sup>1</sup> Namen ohne Titel
 
 
<!--Einleitung-->
 
<!--Einleitung-->
  
<p style="page-break-before: always"></p>
 
 
=Einleitung=
 
=Einleitung=
 
==Intention und Abgrenzung ==
 
==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.   
+
Dieses Dokument beschreibt den dokumentspezifischen Teil der Metadaten für die '''Registrierung von CDA-Dokumenten in ELGA''' über IHE XDS, unter dem Aspekt der Ableitung von XDS Metadaten aus CDA Dokumenten und der Etablierung von einheitlichen Vokabularen.   
 
 
Eine IHE XDS Registry verwaltet Dokumente und macht diese zufänglich. Sie erlaubt die Suche und das Filtern nach den Dokumenten über die Metadaten der Dokumente (Metadaten sind Daten, die andere Daten definieren und beschreiben). Werden wie für ELGA mehrere Registries gemeinsam genutzt, müssen die Metadaten übergreifend harmonisiert werden und Metadatenstandards bereitgestellt werden: Wertebereiche, Abhängigkeiten, Zuständigkeit, Abbildungsregeln, Versionierung und Policies.
 
  
Für die Registrierung von Bilddaten über XDS-I wird eine eigene Spezifikation veröffentlicht.
+
Eine IHE XDS Registry verwaltet Dokumente und macht diese zugänglich. Sie erlaubt die Suche und das Filtern nach den Dokumenten über die Metadaten der Dokumente (Metadaten sind Daten, die andere Daten definieren und beschreiben). Werden, wie für ELGA, mehrere Registries gemeinsam genutzt, müssen die Metadaten übergreifend harmonisiert werden und Metadatenstandards bereitgestellt werden: Wertebereiche, Abhängigkeiten, Zuständigkeit, Abbildungsregeln, Versionierung und Policies.
  
 
Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.
 
Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.
  
 
==Gegenstand dieses Dokuments==
 
==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten<ref name="ALF"></ref> in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. 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:
+
Dieses Dokument definiert die Metadaten beim Einbringen von Dokumenten in Form von Befunden<ref name="ALF"></ref> oder Bilddaten in die ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten (Metadaten der XDSDocumentEntry Objekte)
+
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumente (Metadaten der XDSDocumentEntry Objekte): ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 12.0 (22.4.2016) Final Text''<ref name="ITITF3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 12.0 (2016) [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf], zuletzt besucht am 25.01.2021</ref>
** ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 (16.9.2020) Final Text''<ref name="IHE ITI TF-3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 17.0 (2020), zuletzt besucht am 25.01.2021</ref>
+
 
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 Spezifikation wurde im Zusammenhang mit dem Allgemeinen Implementierungsleitfaden<ref name="ALF"></ref> und den „ELGA CDA Implementierungsleitfäden“ erstellt.  
+
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 Spezifikation wurde im Zusammenhang mit dem "Allgemeinen Implementierungsleitfaden"<ref name="ALF"></ref>, den "ELGA CDA Implementierungsleitfäden" und dem Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch<ref name="KOS-Leitfaden">DICOM Austria: Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch [https://collab.dicom-austria.at/pages/viewpage.action?pageId=27033635 DICOM Austria KOS Leitfaden], zuletzt besucht am 19.02.2021</ref> erstellt.  
  
 
===XDS Folder===
 
===XDS Folder===
 
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
 
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
 
===XDS Submission Sets===
 
===XDS Submission Sets===
Eine weitere Profilierung des XDS SubmissionSets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.  
+
Mit Ausnahme der Kapitel "5.1.12.2 submissionSet.contentTypeCode" und "6.1.12.2 submissionSet.contentTypeCode" wird keine weitere Profilierung des XDS Submission Sets gegenüber dem XDS Standard in ELGA vorgenommen.  
  
 +
Etwaige, Service-spezifische, Vorgaben auf Schnittstellen-Ebene sind in den entsprechenden Schnittstellenspezifikationen (u.a. Schnittstellen Berechtigungssystem, Schnittstellenspezifikation zur Anbindung des elektronischen Impfpasses) angeführt und im Rahmen konkreter System-Anbindungen zu berücksichtigen.
  
 
==Hinweise zur Verwendung des Dokuments==
 
==Hinweise zur Verwendung des Dokuments==
===Farbliche Hervorhebungen===
 
''<u>Themenbezogene Hinweise zur besonderen Beachtung:</u>''
 
{{BeginYellowBox}}
 
'''<Hinweis>'''<br/>authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
 
{{EndYellowBox}}
 
''<u>Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):</u>''
 
<pre class="ilfbox_code">
 
<BEISPIEL>
 
<languageCode code="de-AT" />
 
</pre>
 
''<u>Verweis auf ELGA Value Set:</u>''
 
{{BeginILFBox}}
 
'''<Verweis>'''<br/>Zulässige Werte gemäß Value Set '''„ELGA_FormatCode“.'''
 
{{EndILFBox}}
 
 
 
===Codesysteme und Value Sets===
 
===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.
+
Die in diesem Dokument erwähnten Codesysteme bzw. Value Sets werden am 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.
 
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.
  
 
===OID ===
 
===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/).
+
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/).
  
 
==Allgemeines zu Dokumenten in ELGA==
 
==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.  
+
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-Implementierungsleitfä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.  
+
Die Vorgaben für die Erstellung der CDA-Dokumente sind in den "ELGA CDA-Implementierungsleitfäden" ersichtlich. 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.  
  
 
===Dokumentlebenszyklus und XDS-Transaktionen===
 
===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:  
+
ELGA unterstützt die im folgenden aufgezählten Aktionen (in Klammer die entsprechende ITI-Transaktion). Alle Transaktionen werden in den Protokollierungssystemen aufgezeichnet:  
  
 
====Bereitstellen [ITI-41] und Veröffentlichen [ITI-42]====
 
====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.
+
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.
  
====Ersetzen eines Dokuments durch eine neue Version („Updaten“) [ITI-41]====
+
====Ersetzen eines Dokuments durch eine neue Version ("Updaten") [ITI-41]====
 
Änderungen eines für ELGA bereitgestellten Dokumentes sind NICHT ERLAUBT.  
 
Ä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)).
+
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. Hierbei MUSS die SetId der referenceIdList in den XDS-Metadaten zum neuen Dokument der der Vorgängerversion entsprechen. Die XDS-Metadaten der Vorgängerversion des 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.
 
Beim Ersetzen von ELGA Dokumenten wird das ELGA Berechtigungssystem eventuell zugeordnete individuelle Zugriffsberechtigungen unabhängig von ihrer Anzahl auch auf die Nachfolgeversionen anwenden.
  
 
====Stornieren [ITI-57, XDS Metadata Update]====
 
====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.
+
Dokumente werden "storniert", indem der Dokumentstatus auf "deprecated" gesetzt wird und keine neue Dokumentenversion registriert wird.
 
 
====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].
 
  
 
===Größenbeschränkung ===
 
===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 [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1]]].
+
ELGA schreibt für die Größe der eingebrachten CDA eine Maximalgröße von 20 MB vor. Größere Dokumente sind abzulehnen. Es liegt generell 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 [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten |Allgemeiner Implementierungsleitfaden
 +
für ELGA CDA Dokumente, Kapitel 6.10]].
  
 
==Allgemeines zu XDS-Metadaten==
 
==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.
+
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
 
Die Metadaten eines Dokuments (XDSDocumentEntry) in einem IHE XDS System beinhalten Informationen
Zeile 333: Zeile 315:
 
* über den GDA, welcher das Dokument erstellt hat
 
* über den GDA, welcher das Dokument erstellt hat
 
* über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).
 
* ü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).<ref name="IHE ITI TF-3"></ref>
+
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 TF-3)<ref name="ITITF3"/>.
  
 
Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.  
 
Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.  
Zeile 340: Zeile 322:
 
{{EndYellowBox}}
 
{{EndYellowBox}}
  
'''Hinweis:''' Sehen Sie auch die Vorschrift zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>
+
'''Hinweis:''' Siehe auch Vorschriften zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3<ref name="ITITF3"/>.
 
 
 
 
 
 
  
 
===Metadaten aus unstrukturierten Dokumenten===
 
===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.
+
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument oder binären Objekt 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 oder binäre Objekt korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden.
  
 
===Metadaten aus strukturierten Dokumenten (CDA)===
 
===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.
 
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 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 11.0, Volume 2, Kapitel XDSDocumentEntry Metadata beschrieben.<ref name="IHE ITI"></ref>
+
Die genaue Beschreibung der einzelnen XDS Metadaten Bindings sind im IHE "Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2, Kapitel XDSDocumentEntry Metadata beschrieben.<ref name="IHEPCC">IHE "Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2 [https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf]</ref>
  
===Metadaten aus „On-Demand Documents“ (ODD) ===
+
===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.  
+
Ü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 für On-Demand Documents findet sich IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>
+
Die genaue Beschreibung für On-Demand Documents findet sich IT Infrastructure Technical Framwork (ITI), Volume 3<ref name="ITITF3"/>.
  
 
===Metadaten aus Bilddaten (KOS)===
 
===Metadaten aus Bilddaten (KOS)===
TODO:
+
Bilddaten können über KOS-Objekte (Key Object Selection Document) referenziert und abgerufen werden. Die notwendigen Metadaten können in gewissem Maße aus diesen KOS-Objekten selbst automatisiert entnommen werden. Eine genaue Beschreibung für den Aufbau von KOS-Objekten findet sich im Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch.
  
 
===XDS Metadaten im Vergleich IHE vs. ELGA===
 
===XDS Metadaten im Vergleich IHE vs. ELGA===
Zeile 366: Zeile 345:
 
# Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
 
# Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
 
# Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)
 
# 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 im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können (XDS Document Source)'''
 
# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
 
# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
 
## '''ELGA relevante'''
 
## '''ELGA relevante'''
Zeile 372: Zeile 351:
 
Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).
 
Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).
  
=Überblickstabelle der XDS-I Metadaten für DICOM KOS Objekte=
+
==Überblickstabelle der XDS-I Metadaten für DICOM KOS Objekte==
  
 
Die folgende Tabelle gibt einen Überblick über alle XDS-I Metadaten-Elemente. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in IHE bzw. ELGA für das Einbringen von DICOM KOS Objekten, sowie die Quelle aus der die Informationen stammen.
 
Die folgende Tabelle gibt einen Überblick über alle XDS-I Metadaten-Elemente. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in IHE bzw. ELGA für das Einbringen von DICOM KOS Objekten, sowie die Quelle aus der die Informationen stammen.
Zeile 378: Zeile 357:
 
In der Tabelle 3 werden die XDS-I Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität) angegeben.  
 
In der Tabelle 3 werden die XDS-I Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität) angegeben.  
  
<br />''Tabelle 1: Legende zur Spalte „Quelle“ der folgenden Tabelle''
+
<br />''Tabelle 1: Legende zur Spalte "Quelle" der folgenden Tabelle''
  
 
{| class="wikitable" width="100%"
 
{| class="wikitable" width="100%"
Zeile 394: Zeile 373:
 
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
 
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
 
|}
 
|}
''Tabelle 2: Legende zur Spalte „Optionalität“ der folgenden Tabelle ''
+
 
 +
 
 +
''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''
  
 
{| class="wikitable" width="100%"
 
{| class="wikitable" width="100%"
Zeile 400: Zeile 381:
 
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
 
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
 
|- style="background:CBD7F1"
 
|- style="background:CBD7F1"
|R||Verpflichtend („Required”)
+
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
 +
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R]  ''("required")''.
 
|- style="background:white"
 
|- style="background:white"
|R2||Verpflichtend wenn bekannt („Required if Known“)
+
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2]  ''("required if known")''.
 
|- style="background:white"
 
|- style="background:white"
 
|O||Optional
 
|O||Optional
 
|- style="background:white"
 
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
+
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
 
|}
 
|}
 +
 +
 
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
 
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
 
{| class="wikitable"
 
{| class="wikitable"
| colspan="2" rowspan="2" |'''Metadaten Element'''
+
| colspan="2" |'''Metadaten Element'''
 
|'''Optionalität'''
 
|'''Optionalität'''
| rowspan="2" |'''Beschreibung'''
+
|'''Quelle'''
| rowspan="2" |'''Que-'''
+
|'''Beschreibung'''
 
 
'''lle'''
 
|-
 
|'''ELGA'''
 
 
|-
 
|-
 
| colspan="2" |'''author''' (besteht  aus den folgenden Komponenten)
 
| colspan="2" |'''author''' (besteht  aus den folgenden Komponenten)
|'''R'''
+
|'''M [1..1]'''
|Die Person, welche das Dokument verfasst hat
 
 
|<nowiki>-</nowiki>
 
|<nowiki>-</nowiki>
 +
|Die Person oder das Gerät, welche(s) das Dokument verfasst hat
 
|-
 
|-
 
| rowspan="4" |
 
| rowspan="4" |
 
|authorInstitution
 
|authorInstitution
|'''R'''
+
|'''M [1..1]'''
|ID der Organisation der die Person angehört (OID aus  dem GDA-Index)
+
|E1/K
|A/K
+
|ID der Organisation, der die Person angehört (OID aus  dem GDA-Index)
 
|-
 
|-
 
|authorPerson
 
|authorPerson
|'''R2'''
+
|'''R [0..1]'''
|Daten der Person.
+
|K
 +
|Daten der Person
  
 
(Name, ID, etc.)
 
(Name, ID, etc.)
|K
 
 
|-
 
|-
 
|authorRole
 
|authorRole
|'''R2'''
+
|'''R [0..1]'''
 +
|K
 
|Rolle der Person
 
|Rolle der Person
|K
 
 
|-
 
|-
 
|authorSpeciality
 
|authorSpeciality
|'''R2'''
+
|'''R [0..1]'''
 +
|E1/K
 
|Fachrichtung der Person
 
|Fachrichtung der Person
|A/K
 
 
|-
 
|-
 
| colspan="2" |'''classCode'''
 
| colspan="2" |'''classCode'''
|'''R'''
+
|'''M [1..1]'''
 +
|A
 
|Dokumenten/Objektklasse (Oberklasse)
 
|Dokumenten/Objektklasse (Oberklasse)
  
z.B.: 55113-5 „KOSObjekte“
+
z.B.: 55113-5 "Key images Document Radiology"
|A
 
 
|-
 
|-
 
| colspan="2" |'''confidentialityCode'''
 
| colspan="2" |'''confidentialityCode'''
|'''R'''
+
|'''M [1..1]'''
|Vertraulichkeitscode. Fester Wert „N“
 
 
|A
 
|A
 +
|Vertraulichkeitscode. Fester Wert "N"
 
|-
 
|-
 
| colspan="2" |'''creationTime'''
 
| colspan="2" |'''creationTime'''
|'''R'''
+
|'''M [1..1]'''
|Zeitpunkt der Dokumentenerstellung
 
 
|K
 
|K
 +
|Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes
 
|-
 
|-
 
| colspan="2" |'''eventCodeList'''
 
| colspan="2" |'''eventCodeList'''
|'''R'''
+
|'''M [1..*]'''
 +
|A/K
 
|Liste von Codes von Gesundheitsdienstleistungen
 
|Liste von Codes von Gesundheitsdienstleistungen
|A/K
 
 
|-
 
|-
| colspan="2" |'''eventCodeDisplayNameList'''
+
|
|'''R2'''
+
|'''eventCodeDisplayName'''
|Liste von Gesundheitsdienstleistungen
+
|'''M [1..1]'''
 
|A/K
 
|A/K
 +
|Bezeichnung von Gesundheitsdienstleistungen nach APPC
 
|-
 
|-
 
| colspan="2" |'''intendedRecipient'''
 
| colspan="2" |'''intendedRecipient'''
|'''NP'''
+
|'''NP [0..0]'''
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.
 
 
| -
 
| -
 +
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
 
|-
 
|-
 
| colspan="2" |'''languageCode'''
 
| colspan="2" |'''languageCode'''
|'''R'''
+
|'''M [1..1]'''
|Sprachcode. Fester Wert „de-AT“
 
 
|A
 
|A
 +
|Sprachcode. Fester Wert "de-AT"
 
|-
 
|-
 
| colspan="2" |'''legalAuthenticator'''
 
| colspan="2" |'''legalAuthenticator'''
|'''X'''
+
|'''NP [0..0]'''
 +
| -
 
|Rechtlicher Unterzeichner
 
|Rechtlicher Unterzeichner
| -
 
 
|-
 
|-
 
| colspan="2" |'''serviceStartTime'''
 
| colspan="2" |'''serviceStartTime'''
|'''R'''
+
|'''M [1..1]'''
 +
|K
 
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
 
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|K
 
 
|-
 
|-
 
| colspan="2" |'''serviceStopTime'''
 
| colspan="2" |'''serviceStopTime'''
|'''NP'''
+
|'''NP [0..0]'''
 +
| -
 
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
 
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
| -
 
 
|-
 
|-
 
| colspan="2" |'''sourcePatientId'''
 
| colspan="2" |'''sourcePatientId'''
|'''R'''
+
|'''M [1..1]'''
|Patienten ID im Informationssystem des GDA. z.B.: im RIS
 
 
|K
 
|K
 +
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
 
|-
 
|-
 
| colspan="2" |'''sourcePatientInfo'''
 
| colspan="2" |'''sourcePatientInfo'''
|'''R'''
+
|'''NP [0..0]'''
|Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im RIS)
+
| -
|K
+
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
 
|-
 
|-
| colspan="2" |'''Title'''
+
| colspan="2" |'''title'''
|'''R'''
+
|'''M [1..1]'''
 +
|A/K
 
|Titel des Dokuments
 
|Titel des Dokuments
|A/K
 
 
|-
 
|-
 
| colspan="2" |'''typeCode'''
 
| colspan="2" |'''typeCode'''
|'''R'''
+
|'''M [1..1]'''
 +
|A
 
|Objekttyp (Unterklasse)
 
|Objekttyp (Unterklasse)
  
 
codierter Wert
 
codierter Wert
|A
 
 
|-
 
|-
 
| colspan="2" |'''uniqueId'''
 
| colspan="2" |'''uniqueId'''
|'''R'''
+
|'''M [1..1]'''
|n    Global eindeutige ID des Objektes.
+
|K
 +
|Global eindeutige ID des Objektes
  
 
z.B. SOP Instance UID
 
z.B. SOP Instance UID
|K
 
 
|-
 
|-
 
| colspan="2" |'''referenceIdList'''
 
| colspan="2" |'''referenceIdList'''
|'''R'''
+
|'''M [1..*]'''
 +
|K/E1
 
|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist  in dem Data Typ CXi codiert
 
|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist  in dem Data Typ CXi codiert
|K
 
 
|-
 
|-
| colspan="5" |''Explizit zu setzende Metadaten''
+
| colspan="5" |'''''Explizit zu setzende Metadaten'''''
 
|-
 
|-
 
| colspan="2" |'''availabilityStatus'''
 
| colspan="2" |'''availabilityStatus'''
|'''R'''
+
|'''M [1..1]'''
 +
|E1
 
|Gültigkeit des Objektes
 
|Gültigkeit des Objektes
|E1
 
 
|-
 
|-
 
| colspan="2" |'''formatCode'''
 
| colspan="2" |'''formatCode'''
|'''R'''
+
|'''M [1..1]'''
 +
|E1
 
|Format des Objektes
 
|Format des Objektes
|E1
 
 
|-
 
|-
 
| colspan="2" |'''healthcareFacilityTypeCode'''
 
| colspan="2" |'''healthcareFacilityTypeCode'''
|'''R'''
+
|'''M [1..1]'''
 +
|E1
 
|Klassifizierung des GDA
 
|Klassifizierung des GDA
|E1
 
 
|-
 
|-
 
| colspan="2" |'''mimeType'''
 
| colspan="2" |'''mimeType'''
|'''R'''
+
|'''M [1..1]'''
 +
|E1
 
|Mime Type des Dokuments
 
|Mime Type des Dokuments
  
Fester Wert für KOS: „application/dicom“
+
Fester Wert für KOS: "application/dicom"
|E1
 
 
|-
 
|-
 
| colspan="2" |'''parentDocumentId'''
 
| colspan="2" |'''parentDocumentId'''
|'''O'''
+
|'''O [0..1]'''
 +
|E1
 
|Verweis auf ein referenziertes Objekt
 
|Verweis auf ein referenziertes Objekt
|E1
 
 
|-
 
|-
 
| colspan="2" |'''parentDocumentRelationship'''
 
| colspan="2" |'''parentDocumentRelationship'''
|'''O'''
+
|'''O [0..1]'''
 +
|E1
 
|Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC,  XFRM
 
|Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC,  XFRM
|E1
 
 
|-
 
|-
 
| colspan="2" |'''practiceSettingCode'''
 
| colspan="2" |'''practiceSettingCode'''
|'''R'''
+
|'''M [1..1]'''
 +
|E1
 
|Fachliche Zuordnung des Dokuments
 
|Fachliche Zuordnung des Dokuments
|E1
 
 
|-
 
|-
 
| colspan="2" |'''entryUUID'''
 
| colspan="2" |'''entryUUID'''
|'''R'''
+
|'''M [1..1]'''
 +
|E1
 
|UUID des Metadaten-Records des Dokuments(XDS  DocumentEntry)
 
|UUID des Metadaten-Records des Dokuments(XDS  DocumentEntry)
|E1
 
 
|-
 
|-
 
| colspan="2" |'''objectType'''
 
| colspan="2" |'''objectType'''
|'''R'''
+
|'''M [1..1]'''
|Typ des DocumentEntries.
+
|E1
 +
|Typ des DocumentEntries
  
Fester Wert „SD“
+
Fester Wert "SD"
|E1
 
 
|-
 
|-
 
| colspan="2" |'''comments'''
 
| colspan="2" |'''comments'''
|'''O'''
+
|'''O [0..1]'''
 +
|K
 
|Kommentar zum Dokument/Objekt
 
|Kommentar zum Dokument/Objekt
|K
 
 
|-
 
|-
 
| colspan="2" |'''patientId'''
 
| colspan="2" |'''patientId'''
|'''R'''
+
|'''M [1..1]'''
 +
|E1
 
|Patienten-ID  in der XDS Affinity Domain
 
|Patienten-ID  in der XDS Affinity Domain
|E1
 
 
|-
 
|-
 
| colspan="5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
 
| colspan="5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
 
|-
 
|-
 
| colspan="2" |'''hash'''
 
| colspan="2" |'''hash'''
|'''R'''
+
|'''M [1..1]'''
|Hash Wert des Dokuments. Wird vom Repository befüllt.
 
 
|A
 
|A
 +
|Hash Wert des Dokuments. Wird vom Repository befüllt
 
|-
 
|-
 
| colspan="2" |'''homeCommunityId'''
 
| colspan="2" |'''homeCommunityId'''
|'''R'''
+
|'''M [1..1]'''
|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
 
|A
 +
|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.
 
|-
 
|-
 
| colspan="2" |'''repositoryUniqueId'''
 
| colspan="2" |'''repositoryUniqueId'''
|'''R'''
+
|'''M [1..1]'''
 +
|A
 
|Die eindeutige Identifikation (OID) des Document Repositories, in  welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
 
|Die eindeutige Identifikation (OID) des Document Repositories, in  welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
|A
 
 
|-
 
|-
 
| colspan="2" |'''size'''
 
| colspan="2" |'''size'''
|'''R'''
+
|'''M [1..1]'''
 +
|A
 
|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository  befüllt.
 
|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository  befüllt.
 
<br />
 
<br />
|A
 
 
|-
 
|-
 
| colspan="2" |'''URI'''
 
| colspan="2" |'''URI'''
|<nowiki>-</nowiki>[[#%20ftn1|'<nowiki/>'''''[1]'''''']]
+
|'''NP [0..0]'''[[#%20ftn1|<nowiki/>]][[#%20ftn1|<nowiki/>]]
 +
|A
 
|Wird in XDS-I nicht verwendet
 
|Wird in XDS-I nicht verwendet
|A
+
|-
 
|-
 
|-
 
| colspan="5" |'''''Vom  ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
 
| colspan="5" |'''''Vom  ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
 
|-
 
|-
 
| colspan="2" |'''elgaFlag'''
 
| colspan="2" |'''elgaFlag'''
|'''R'''
+
|'''M [1..1]'''
|Kennzeichnet ein Dokument als „ELGA-Dokument“
 
 
|B
 
|B
 +
|Kennzeichnet ein Dokument als "ELGA-Dokument"
 
|-
 
|-
 
| colspan="2" |'''elgaHash'''
 
| colspan="2" |'''elgaHash'''
|'''R'''
+
|'''M [1..1]'''
 +
|B
 
|Prüfkennzeichen für Integrität und Authentizität des  XDS-Metadatensatzes
 
|Prüfkennzeichen für Integrität und Authentizität des  XDS-Metadatensatzes
|B
 
 
|}
 
|}
[[#%20ftn1|<nowiki/>]]
+
<br />[[#%20ftn1|<nowiki/>]]
[[#%20ftnref1|[1]]] Dieses Element wird von XDS-I nicht verwendet und ist nur der Vollständigkeit halber angegeben.
+
 
  
 
<br />
 
<br />
<p style="page-break-before: always"></p>
 
 
<p style="page-break-before: always"></p>
 
<p style="page-break-before: always"></p>
  
=Überblickstabelle der XDS Metadaten für HL7 CDA Objekte=
+
==Überblickstabelle der XDS Metadaten für HL7 CDA Objekte==
 
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.
 
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.  
+
In der Tabelle 6 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.  
 
 
TODO: urn:ihe:iti:xds:2015:encounterId als referenceIdList Eintrag ergänzen?
 
  
 +
''Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle''
 
{| class="wikitable" width="100%"
 
{| class="wikitable" width="100%"
 
|- style="background:#CBD7F1"
 
|- style="background:#CBD7F1"
Zeile 662: Zeile 642:
 
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
 
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
 
|}
 
|}
''Tabelle 1: Legende zur Spalte „Quelle“ der folgenden Tabelle''
+
 
 +
 
 +
''Tabelle 5: Legende zur Spalte "Optionalität" der folgenden Tabelle ''
  
 
{| class="wikitable" width="100%"
 
{| class="wikitable" width="100%"
Zeile 668: Zeile 650:
 
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
 
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
 
|- style="background:CBD7F1"
 
|- style="background:CBD7F1"
|R||Verpflichtend („Required”)
+
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
 +
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R]  ''("required")''.
 
|- style="background:white"
 
|- style="background:white"
|R2||Verpflichtend wenn bekannt („Required if Known“)
+
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2]  ''("required if known")''.
 
|- style="background:white"
 
|- style="background:white"
 
|O||Optional
 
|O||Optional
 
|- style="background:white"
 
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
+
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
 
|}
 
|}
''Tabelle 2: Legende zur Spalte „Optionalität“ der folgenden Tabelle ''
 
  
 +
 +
''Tabelle 6: Überblick XDS Metadaten und deren Quellen (alphabetisch)''
 
{| class="wikitable" width="100%"
 
{| class="wikitable" width="100%"
 
|- style="background:#CBD7F1"
 
|- style="background:#CBD7F1"
| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''|| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''|| rowspan="2" style="text-align:left" width="45%" |'''Beschreibung '''|| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
+
| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''
 +
| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''
 +
| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
 +
| rowspan="2" style="text-align:left" |'''Beschreibung '''
 
|- style="background:#CBD7F1"
 
|- style="background:#CBD7F1"
|'''SD<sup>9</sup>'''||'''OD<sup>10</sup>'''
+
|'''SD'''<sup>9</sup>||'''ODD'''<sup>10</sup>
 
|- style="background:#CBD7F1"
 
|- style="background:#CBD7F1"
 
| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''
 
| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''R'''||'''R'''||Die Person, welche das Dokument verfasst hat||-
+
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''M [1..1]'''||'''M [1..1]'''
 +
|C||Die Person, welche das Dokument verfasst hat
 
|- style="background:white"
 
|- style="background:white"
| ||authorInstitution||'''R'''||'''R'''||ID der Organisation der die Person angehört. (OID aus dem GDA-Index)||C
+
| ||authorInstitution||'''M [1..1]'''||'''M [1..1]'''
 +
|C||ID und Name der Organisation (Kurzbezeichnung), der die Person angehört, wie im GDA-Index angegeben.
 
|- style="background:white"
 
|- style="background:white"
| ||authorPerson||'''R'''||'''R'''||Daten der Person. (Name, ID, etc.)||C
+
| ||authorPerson||'''M [1..1]'''||'''M [1..1]'''
 +
|C||Daten der Person (Name, ID, etc.)
 
|- style="background:white"
 
|- style="background:white"
| ||authorRole||'''R2'''||'''X'''||Rolle der Person||C
+
| ||authorRole||'''R [0..1]'''||'''NP [0..0]'''
 +
|C||Rolle der Person
 
|- style="background:white"
 
|- style="background:white"
| ||authorSpeciality||'''R2'''||'''X'''||Fachrichtung der Person||C
+
| ||authorSpeciality||'''R [0..1]'''||'''NP [0..0]'''
 +
|C||Fachrichtung der Person
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''classCode'''||'''R'''||'''R'''||Dokumentenklasse (Oberklasse)<br />z.B.: 18842-5 „Entlassungsbrief“||C
+
| colspan="2" |'''classCode'''||'''M [1..1]'''||'''M [1..1]'''
 +
|C||Dokumentenklasse (Oberklasse)<br />z.B.: 18842-5 "Entlassungsbrief"
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''R'''||'''X'''||Vertraulichkeitscode des Dokuments||C
+
| colspan="2" |'''confidentialityCode'''||'''M [1..1]'''||'''NP [0..0]'''
 +
|C||Vertraulichkeitscode des Dokuments
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''creationTime'''||'''R'''||'''R'''||Zeitpunkt der Dokumentenerstellung||C
+
| colspan="2" |'''creationTime'''||'''M [1..1]'''||'''NP [0..0]'''
 +
|C||Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R2'''||'''R2'''||Liste von Gesundheitsdienstleistungen||C
+
| colspan="2" |'''eventCodeList'''||'''R [0..*]'''||'''R [0..*]'''
 +
|C||Liste von Gesundheitsdienstleistungen
 
|-
 
|-
 
| colspan="2" |'''formatCode'''
 
| colspan="2" |'''formatCode'''
|'''R'''
+
|'''M [1..1]'''
|'''R'''
+
|'''M [1..1]'''
 +
|C
 
|Format des Dokumenteninhalts
 
|Format des Dokumenteninhalts
|C
 
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O'''||'''X'''||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C
+
| colspan="2" |'''intendedRecipient'''||'''O [0..1]'''||'''NP [0..0]'''
 +
|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''languageCode'''||'''R'''||'''R'''||Sprachcode des Dokuments<br />z.B.: "de-AT"||C
+
| colspan="2" |'''languageCode'''||'''M [1..1]'''||'''M [1..1]'''
 +
|C||Sprachcode des Dokuments<br />z.B.: "de-AT"
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R2'''||'''X'''||Rechtlicher Unterzeichner des Dokuments||C
+
| colspan="2" |'''legalAuthenticator'''||'''R [0..1]'''||'''NP [0..0]'''
 +
|C||Rechtlicher Unterzeichner des Dokuments
 
|-
 
|-
 
| colspan="2" |'''practiceSettingCode'''
 
| colspan="2" |'''practiceSettingCode'''
|'''R'''
+
|'''M [1..1]'''
|'''R'''
+
|'''M [1..1]'''
 +
|C
 
|Fachliche Zuordnung des Dokuments
 
|Fachliche Zuordnung des Dokuments
|C
 
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R2'''||'''O'''||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C
+
| colspan="2" |'''serviceStartTime'''||'''R [0..1]'''||'''O [0..1]'''
 +
|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R2'''||'''O'''||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung||C
+
| colspan="2" |'''serviceStopTime'''||'''R [0..1]'''||'''O [0..1]'''
 +
|C||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''R'''||'''R'''||Patienten ID im Informationssystem des GDA. z.B.: im KIS des KH||C
+
| colspan="2" |'''sourcePatientId'''||'''M [1..1]'''||'''M [1..1]'''
 +
|C||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''X'''||'''X'''||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C
+
| colspan="2" |'''sourcePatientInfo'''||'''NP [0..0]'''||'''NP [0..0]'''
 +
|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''Title'''||'''R'''||'''R'''||Titel des Dokuments||C
+
| colspan="2" |'''Title'''||'''M [1..1]'''||'''M [1..1]'''
 +
|C||Titel des Dokuments
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''typeCode'''<sup>11</sup>||'''R'''||'''R'''||Dokumententyp (Unterklasse) <br />codierter Wert, z.B.: 11490-0, „Entlassungsbrief aus stationärer Behandlung (Arzt)“||C
+
| colspan="2" |'''typeCode'''<sup>11</sup>||'''M [1..1]'''||'''M [1..1]'''
 +
|C||Dokumententyp (Unterklasse) <br />codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''R'''||'''R'''||Global eindeutige ID des Dokuments||C
+
| colspan="2" |'''uniqueId'''||'''M [1..1]'''||'''M [1..1]'''
 +
|C||Global eindeutige ID des Dokuments
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''R'''||'''O'''||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert||C
+
| colspan="2" |'''referenceIdList'''||'''M [1..1]'''||'''O [0..1]'''
 +
|C||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''R'''||'''R'''||Klassifizierung des GDA
+
| colspan="2" |'''healthcareFacilityTypeCode'''||'''M [1..1]'''||'''M [1..1]'''
|C
+
|C||Klassifizierung des GDA
  
 
|- style="background:white"
 
|- style="background:white"
 
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
 
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''availabilityStatus'''||'''R'''||'''R'''||Gültigkeit des Dokuments||E1
+
| colspan="2" |'''availabilityStatus'''||'''M [1..1]'''||'''M [1..1]'''
 +
|E1||Gültigkeit des Dokuments
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''mimeType'''||'''R'''||'''R'''||Mime Type des Dokuments<br />z.B.: „text/xml“ für CDA||E1
+
| colspan="2" |'''mimeType'''||'''M [1..1]'''||'''M [1..1]'''
 +
|E1||Mime Type des Dokuments<br />z.B.: "text/xml" für CDA
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''parentDocumentId'''<sup>12</sup>||'''O'''||'''O'''||Verweis auf ein referenziertes Dokument||E1
+
| colspan="2" |'''parentDocumentId'''<sup>12</sup>||'''O [0..1]'''||'''O [0..1]'''
 +
|E1||Verweis auf ein referenziertes Dokument
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''<sup>13</sup>||'''O'''||'''O'''||Typ der Relation zu dem referenzierten Dokument.<br />z.B.: RPLC, XFRM||E1
+
| colspan="2" |'''parentDocumentRelationship'''<sup>13</sup>||'''O [0..1]'''||'''O [0..1]'''
 +
|E1||Typ der Relation zu dem referenzierten Dokument.<br />z.B.: RPLC, XFRM
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''entryUUID'''||'''R'''||'''R'''||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)||E1
+
| colspan="2" |'''entryUUID'''||'''M [1..1]'''||'''M [1..1]'''
 +
|E1||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''objectType'''||'''R'''||'''R'''||Typ des DocumentEntries (SD oder ODD)||E1
+
| colspan="2" |'''objectType'''||'''M [1..1]'''||'''M [1..1]'''
 +
|E1||Typ des DocumentEntries (SD oder ODD)
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''comments'''||'''O'''||'''O'''||Kommentar zum Dokument||E2
+
| colspan="2" |'''comments'''||'''O [0..1]'''||'''O [0..1]'''
 +
|E2||Kommentar zum Dokument
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''patientId'''||'''R'''||'''R'''||Patienten-ID in der XDS Affinity Domain||E1
+
| colspan="2" |'''patientId'''||'''M [1..1]'''||'''M [1..1]'''
 +
|E1||Patienten-ID in der XDS Affinity Domain
  
 
|- style="background:white"
 
|- style="background:white"
 
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
 
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''hash'''||'''R'''||'''X'''||Hash Wert des Dokuments. Wird vom Repository befüllt.||A
+
| colspan="2" |'''hash'''||'''M [1..1]'''||'''NP [0..0]'''
 +
|A||Hash Wert des Dokuments. Wird vom Repository befüllt.
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''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
+
| colspan="2" |'''homeCommunityId'''||'''M [1..1]'''||'''M [1..1]'''
 +
|A||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.
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''repositoryUniqueId '''||'''R'''||'''R'''||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.||A
+
| colspan="2" |'''repositoryUniqueId '''||'''M [1..1]'''||'''M [1..1]'''
 +
|A||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''size'''||'''R'''||'''X'''||Größe des Dokuments in Bytes. Wird vom Repository befüllt.||A
+
| colspan="2" |'''size'''||'''M [1..1]'''||'''NP [0..0]'''
 +
|A||Größe des Dokuments in Bytes. Wird vom Repository befüllt.
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''URI'''<sup>14</sup>||'''-'''||'''-'''||<span style="color:red;">'''Wird in XDS nicht verwendet'''</span>||A
+
| colspan="2" |'''URI'''||'''NP [0..0]'''||'''NP [0..0]'''
 +
|A||'''Wird in XDS nicht verwendet'''
 
|- style="background:white"
 
|- style="background:white"
 
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
 
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''elgaFlag'''||'''R'''||'''R'''||Kennzeichnet ein Dokument als „ELGA-Dokument“||B
+
| colspan="2" |'''elgaFlag'''||'''M [1..1]'''||'''M [1..1]'''
 +
|B||Kennzeichnet ein Dokument als "ELGA-Dokument"
 
|- style="background:white"
 
|- style="background:white"
| colspan="2" |'''elgaHash'''||'''R'''||'''R'''||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B
+
| colspan="2" |'''elgaHash'''||'''M [1..1]'''||'''M [1..1]'''
 +
|B||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes
 
|}
 
|}
''Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)''
 
  
  
<sup>9</sup> SD: „Stable Document“: Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht.<br />
+
<sup>9</sup> SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht.<br />
<sup>10</sup> OD: „On-demand Document“: Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird. <br />
+
<sup>10</sup> ODD: "On-demand Document": Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird. <br />
<sup>11</sup> Der Inhalt des typeCodes soll mit dem contentTypeCode des SubmissionSets übereinstimmen.<br />
+
<sup>11</sup> Der Inhalt des typeCodes soll mit dem contentTypeCode des Submission Sets übereinstimmen.<br />
<sup>12</sup> MUSS vorhanden sein, wenn eine  „parentDocumentRelationship“ existiert. <br />
+
<sup>12</sup> MUSS vorhanden sein, wenn eine  "parentDocumentRelationship" existiert. <br />
<sup>13</sup> MUSS gemeinsam mit einer „parentDocumentId“ angegeben sein.<br />
+
<sup>13</sup> MUSS gemeinsam mit einer "parentDocumentId" angegeben sein.<br />
<sup>14</sup> Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.
 
<p style="page-break-before: always"></p>
 
  
 
=XDS-I Metadaten für DICOM KOS Objekte=
 
=XDS-I Metadaten für DICOM KOS Objekte=
==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==
+
Die folgenden Kapitel spezifizieren die XDS-I Metadaten von DICOM KOS-Objekten für deren Verwendung in ELGA. Nicht weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt<ref name="ITITF3"/>.
TODO: Tabellarische Übersicht
+
 
 +
Die folgende Tabelle gibt einen Überblick jener XDS-I Metadaten-Elemente, die direkt aus dem DICOM KOS bzw. der zugrundeliegenden DICOM Study abgeleitet werden können. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in ELGA für das Einbringen von DICOM KOS Objekten, sowie die Quelle aus der die Informationen stammen.
 +
 
 +
''Tabelle 7: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet''
 +
{| class="wikitable" width="100%"
 +
|- style="background:#CBD7F1"
 +
| colspan="2" |'''XDS-I Metadaten Element'''
 +
|'''Opt.'''
 +
|'''Attribut in'''
  
===author===
+
'''der Studie'''
Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
+
|'''Attribut'''
  
<br />
+
'''im KOS'''
====authorInstitution====
+
|'''Beschreibung'''
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Dokument oder Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name“, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.
+
|- style="background:white"
 +
| colspan="2" |author
 +
|M [1..1]
 +
| colspan="3" |
 +
|- style="background:white"
 +
| rowspan="6" |
 +
|author.authorInstitution
 +
|M [1..1]
 +
|(0008,0080)
 +
|(0008,0080)
 +
|Identifiziert die Institution, in deren Gültigkeitsbereich die  Studie erzeugt wurde.
  
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
+
ELGA schreibt vor, hier sowohl die Kurzbezeichnung als auch die OID der Institution aus dem GDA-Index anzugeben.
  
#Die ''authorInstitution'' benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden kann
+
Zur Ermittlung des Namens kann das DICOM Tag (0008,0080) herangezogen werden.
#*''id'' OID der Organisation aus dem GDA-Index (muss ermittelt werden)
 
#*''name'' (0008,0080), Institution Name, Name der Organisation als String,
 
{{BeginYellowBox}}
 
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
 
  
'''Achtung:''' Das DICOM-Tag (0008,0080), Institution Name, ist vom Type 3 (optional) (General Equipment Module).  
+
'''Achtung:''' Dieses  Attribut ist Type 3 (optional) (General Equipment Module).
  
 
'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
 
'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
 +
|- style="background:white"
 +
| colspan="5" |Die Person, welche die Studie durchführt, ist als author anzugeben:
 +
|- style="background:white"
 +
|author.authorPerson
 +
|R [0..1]
 +
|(0008,1052)
 +
|
 +
|Performing Physicians Identification Sequence
  
{{EndYellowBox}}
+
Code und weitere Daten aus dem ersten Item in der Sequence
  
=====Spezifikation=====
+
'''Achtung''': Die Identifikationsdaten der durchführenden Ärzte  können in verschiedenen Serien der Studie unterschiedlich sein. Bei der  Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird,  die die maßgeblichen Teile der Studie verantwortet.
 +
|- style="background:white"
 +
|
 +
|
 +
|'''Alternativ:'''
  
'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
(0008,1050)
 +
|
 +
|Performing Physicians Name
  
 +
Enthält dieses Attribut mehrere Namen, so ist der erste Name zu  wählen.
  
<span>$name</span> … Name der Organisation, die die Studie erstellt hat
+
'''Achtung:'''  Die Namen der durchführenden Ärzte können in verschiedenen Serien der Studie  unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass  die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
 +
|- style="background:white"
 +
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann,  soll das Gerät als author angegeben werden:
 +
|- style="background:white"
 +
|author.authorPerson
 +
|R [0..1]
 +
|(0008,0060) + (0008,0070) +  (0008,1090)
 +
|
 +
|Modality Code + Manufacturer +  Manufacturer's Model Name
  
<span>$id ... OID der Organisation aus dem GDA-Index</span>
+
'''Achtung:'''  Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist  Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte  Gerät als Metadatum verwendet wird.
 +
|- style="background:white"
 +
| colspan="2" |creationTime
 +
|M [1..1]
 +
|(0008,0020) + (0008,0030)
 +
|(0008,0020) + (0008,0030)
 +
|Study Date + Study Time
  
concat(<br />
+
Für den Fall, dass Study Date und Study Time nicht zur  Verfügung stehen, ist es zulässig, den Erstellungszeitpunkt des KOS ((0008,0023)  contentDate + (0008,0033) contentTime) als creationTime zu verwenden.
<span>$</span>name,"^^^^^^^^^",<br />
+
|- style="background:white"
<span>$</span>id<br />
+
| colspan="2" |eventCodeList
)<br />
+
|M [1..*]
<pre class="ilfbox_code">
+
|
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
+
|
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
+
|Enthält eine Liste von Codes von Gesundheitsdienstleistungen nach APPC
    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&amp;amp;ISO</Value>
 
        </ValueList>
 
    </Slot>   
 
</Classification>
 
</pre>
 
  
 +
siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten<nowiki/>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</ref>
 +
|- style="background:white"
 +
|
 +
|eventCodeList<br />DisplayNameList
 +
|M [1..1]
 +
|
 +
|
 +
|Enthält den Display Name des APPC
  
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß [IHE ITI-TF3].
+
siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom" />
====authorPerson====
+
|- style="background:white"
Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche die Bilddaten inhaltlich erstellt hat.
+
| colspan="2" |serviceStartTime
 +
|M [1..1]
 +
|(0008,0020) + (0008,0030)
 +
|(0008,0020) + (0008,0030)
 +
|Study Date und Study Time
 +
|- style="background:white"
 +
| colspan="2" |sourcePatientId
 +
|M [1..1]
 +
|(0010,0020)
 +
|(0010,0020)
 +
|Die Patient ID im eigenen Informationssystem
 +
|- style="background:white"
 +
| colspan="2" |sourcePatientInfo
 +
|M [1..1]
 +
|(0010,0020)
  
Im Fall eines DICOM Objektes gilt eine Verknüpfung mit folgenden (optionalen) DICOM Attributen:
+
(0010,0010)
  
#Die Person kann aus den DICOM Attributen der Studie abgleitet werden
+
(0010,0030)
#*Identifikator: Code aus Attribut „Performing Physicians Identification Sequence“, (0008,1052), Datentyp SQ[[#%20ftn1|[1]]], wenn vorhanden
 
#*Name: Attribut „Performing Physicians Name“, (0008,1050), Datentyp PN (entspricht den ersten 5 Feldern von HL7 V2 Datenyp XPN. Maximum 64 Zeichen pro component group, ohne zusätzliche ideographische und phonetische Zeichen). Wenn mehrere Namen vorhanden sind, ist der erste zu übernehmen.
 
#*Root: OID-Unterknoten für Personen (entsprechend der Organisations-OID aus dem GDA-Index) ----[[#%20ftnref1|[1]]] Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence
 
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den DICOM Attribut Modality der Studie abgleitet werden
 
#*Modalität[[#%20ftn1|[2]]]: Attribut „Modality“, (0008,0060)
 
#*Hersteller: Attribut „Manufacturer“, (0008,0070)
 
#*Modellname: Attribut „ Manufacturer's Model Name“, (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</nowiki>
 
  
 +
(0010,0040)
 +
|(0010,0020)
  
{{BeginYellowBox}}
+
(0010,0010)
  
'''Achtung:''' Die Identifikationsdaten und Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
+
(0010,0030)
  
'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
+
(0010,0040)
{{EndYellowBox}}
+
|Die ELGA Vorgabe empfiehlt, Name, Geburtstag und Geschlecht  NICHT anzugeben.
 +
|- style="background:white"
 +
| colspan="2" |title
 +
|M [1..1]
 +
|(0008,0060) + (0008,1030)
 +
|
 +
|Der relevante Modality Code der Studie oder alle Modality Codes  der Studie und die Study Description.
  
=====Spezifikation für Personen=====
+
Alternativ darf anstatt der Study Description der DisplayName  des APPC verwendet werden.
  
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
'''Anmerkung:'''
  
$id = Code #1 aus (0008,1052) Performing Physicians Identification Sequence
+
Für den Fall, dass alle Objekte einer Studie mittels IOCM  storniert wurden, enthält diese Studie nur noch die Rejection Note. Der  Modality Code ist in diesem Fall "KO".
 +
<br />
 +
|- style="background:white"
 +
| colspan="2" |uniqueId
 +
|M [1..1]
 +
|
 +
|(0008,0018)
 +
|Die SOP Instance UID des KOS
 +
|- style="background:white"
 +
| colspan="2" |referenceIdList
 +
|M [1..1]
 +
|
 +
|
 +
|Die referenceIdList enthält mindestens die beiden folgenden  Attribute und darüber hinaus noch weitere Elemente
 +
|- style="background:white"
 +
| rowspan="2" |
 +
|value mit CXi.5 =<br />"<nowiki>urn:elga:iti:xds:2014: OwnDocument_setId</nowiki>"
 +
|M [1..1]
 +
|(0020,000D) oder ein  vergleichbares Attribut
 +
|(0020,000D) oder ein  vergleichbares Attribut
 +
|Die setId zur Klammerung aller Versionen eines KOS
  
$person = (0008,1050) Performing Physicians Name
+
Diese kann von jedem Bereich frei gewählt werden, sie ist mit dem Datentyp '''<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>''' anzugeben.
  
$root = OID-Knoten für den Personenidentifikator
+
Eine mögliche Wahl der setId ist die Study Instance UID. Die geeignete Wahl der setId hängt auch vom implementierten Stornoworkflow ab, siehe KOS Leitfaden (Kapitel 8.2.2.)<ref name="KOS-Leitfaden" />
 +
|- style="background:white"
 +
|value mit CXi.5 = <br />"<nowiki>urn:ihe:iti:xds:2013: accession</nowiki>"
 +
|R [0..1]
 +
|(0008,0050) oder ein vergleichbares Attribut wie z.B.
  
 +
(0040,1001) Requested Procedure ID
 +
<br />
 +
|(0008,0050)
 +
<br />
 +
|Die ID, die zur Verlinkung mit dem Befund heranzuziehen ist.
  
concat(<br />
+
Diese ist mit dem Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' anzugeben.
<span> $id</span>,"^",<br />
 
<span> $person</span>,"^",<br />
 
<span> $</span>root,"&amp;amp;ISO"<br />
 
)<br />
 
<pre class="ilfbox_code">
 
<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^MusterDoc^&amp;amp;1.2.40.0.34.99.4613.3.3&amp;amp;ISO
 
            </Value>
 
        </ValueList>
 
    </Slot>  
 
</Classification></pre>
 
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
 
=====Spezifikation für Software und Geräte=====
 
  
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
'''Achtung:'''  
  
$Modality = Modality (0008,0060)
+
Welche ID dazu geeignet ist, die Verlinkung mit dem zugehörigen Befund herzustellen, ist vom jeweils implementierten Workflow abhängig.
  
$Manufacturer = Manufacturer (0008,0070)
+
Gemäß dem Integrationsprofil IHE RAD Scheduled Workflow dient dazu die  Accession Number, die im DICOM Attribut (0008,0050) enthalten ist.
  
$ManufacturersModelName = Manufacturer's Model Name (0008,1090)
+
Weicht der lokale radiologische Workflow vom IHE Profil ab, kann es  erforderlich sein, ein anderes DICOM Attribut für die Verlinkung heranzuziehen.
  
 +
Unabhängig von der Wahl des DICOM Attributs ist aber in  jedem Fall der Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' zu verwenden.
 +
|- style="background:white"
 +
| colspan="2" |comments
 +
|O [0..1]
 +
|(0008,1030)
 +
|(0008,1030)
 +
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
 +
|}
  
concat(
+
==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==
  
"^",
 
  
$Modality,"^",
+
===author===
 +
Die Person oder Maschine, die das Dokument erstellt hat. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
 +
====authorInstitution====
 +
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.
  
$Manufacturer,"^",
+
Die ''authorInstitution'' benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden können. Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird.<br /> Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" →  "Wien AKH" bzw "Wien AKH - Augenambulanz"<br />Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.
  
$ManufacturersModelName
+
*''oid'': OID der Organisation aus dem GDA-Index (muss ermittelt werden)
 +
*''name'': (0008,0080), Institution Name, Name der Organisation als String,
 +
{{BeginYellowBox}}
 +
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.<br>
 +
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden. <br>
  
)<br /><pre class="ilfbox_code">
+
'''Achtung:''' Das DICOM-Tag (0008,0080), Institution Name, ist vom Type 3 (optional) (General Equipment Module).
<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>^CT^Geräthersteller^Gerätename</Value>
 
        </ValueList>
 
    </Slot>
 
</Classification></pre>
 
  
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
+
'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
 +
{{EndYellowBox}}
  
====authorRole====
+
=====Spezifikation=====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der Dokumentation innehatte.
 
  
Dieser Leitfaden beschreibt keine Einschränkungen für die Verwendung.
+
'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
Beispiel:
+
<span>$name</span> … Name der Organisation, die die Studie erstellt hat
  
*„Radiologie“
+
<span>$oid ... OID der Organisation aus dem GDA-Index</span>
*„Modalität“
 
  
====authorSpeciality====
+
concat(<br />
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.
+
<span>$</span>name,"^^^^^^^^^",<br />
 
+
<span>$</span>oid,"&amp;amp;ISO"<br />
Beispiel:
+
)<br />
 
 
*„Facharzt für Radiologie“
 
*„Facharzt für Nuklearmedizin“
 
 
 
======Spezifikation======
 
 
 
'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
 
 
 
Bsp: Fachärztin/Facharzt für Radiologie<br />
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
 
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
 
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
 
     classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
 
     classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
 
     id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
 
     id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
     <Slot name="authorSpeciality">
+
     <Slot name="authorInstitution">
 
         <ValueList>
 
         <ValueList>
             <Value>Fachärztin/Facharzt für Radiologie</Value>
+
             <Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;amp;ISO
 +
            </Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>     
 
     </Slot>     
 
</Classification>
 
</Classification>
 
</pre>
 
</pre>
{{BeginYellowBox}}
 
Wenn eine Person als Autor vorhanden ist, MUSS der Wert einem DisplayName aus dem Value Set „ELGA_AuthorSpeciality“ entsprechen.
 
  
Im Fall von Geräten oder Software als Autor MUSS das Element leer bleiben.
+
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.
  
{{EndYellowBox}}
+
====authorPerson====
===classCode (und classCodeDisplayName)===
+
Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche die Bilddaten inhaltlich erstellt hat.
Das ''classCode'' Element klassifiziert (grobe Granularität) das registrierte Objekt und ist relevant für das Berechti-gungssystem.
 
  
Unterscheidung classCode/typeCode:
+
Im Fall eines DICOM Objektes gilt eine Verknüpfung mit folgenden (optionalen) DICOM Attributen:
{| class="wikitable"
 
|- style="background:white"
 
|'''''classCode'''''
 
|'''''Dokumentenklasse in grober Granularität'''''
 
|- style="background:white"
 
|''typeCode''
 
|Dokumentenklasse  in feiner Granularität.<br />  Siehe  Kapitel [[ILF:XDS Metadaten 2020#typeCode_.28und_typeCodeDisplayName.29|4.2.15]]
 
|}
 
  
====Spezifikation====
+
#Die Person kann aus den DICOM Attributen der Studie abgeleitet werden
 +
#*Identifikator: Code aus Attribut "Performing Physicians Identification Sequence", (0008,1052), Datentyp SQ, wenn vorhanden. Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence.
 +
#*Name: Attribut "Performing Physicians Name", (0008,1050), Datentyp PN (entspricht den ersten 5 Feldern von HL7 V2 Datentyp XPN. Maximum 64 Zeichen pro component group, ohne zusätzliche ideographische und phonetische Zeichen). Wenn mehrere Namen vorhanden sind, ist der erste zu übernehmen.
 +
#*Root: OID-Unterknoten für Personen (entsprechend der Organisations-OID aus dem GDA-Index)
 +
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den folgenden DICOM Attributen abgleitet werden
 +
#*Modalität: Attribut "Modality", (0008,0060), erlaubte Werte siehe DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality <ref name="DICOMModality">DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality  http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</ref>
 +
#*Hersteller: Attribut "Manufacturer", (0008,0070)
 +
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090)
  
'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br />
+
{{BeginYellowBox}}
 +
'''Achtung:''' Die Identifikationsdaten und Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
  
Es wird ein fester Wert gesetzt:  55113-5 „Key images Document Radiology“ (LOINC: 2.16.840.1.113883.6.1)
+
'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
 +
{{EndYellowBox}}
  
$code = "55113-5"<br />$displayName = "Key images Document Radiology"<br />$codeSystem = "2.16.840.1.113883.6.1"<br />
+
=====Spezifikation für Personen=====
<pre class="ilfbox_code">
 
<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>
 
</pre>
 
  
 +
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
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).
 
  
[https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen Direktlink]
+
1.Fall: Bei der lokalen ID handelt es sich um KEINE OID:
  
===confidentialityCode===
+
$id = Code #1 aus (0008,1052) Performing Physicians Identification Sequence
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.
 
  
Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf Dokumente aus-schließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt, bzw. fix auf „normal“ (N) gesetzt.
+
$person = (0008,1050) Performing Physicians Name
  
Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich. Es wird der Vertraulichkeitscode gemäß folgender Spezifikation übernommen:
+
$root = OID-Knoten für den Personenidentifikator
  
Zulässige Werte gemäß Value Set „[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]“.
+
concat(<br />
 
+
<span> $id</span>,"^",<br />
====Spezifikation====
+
<span> $person</span>,"^",<br />
 +
<span> $</span>root,"&amp;amp;ISO"<br />
 +
)<br />
 +
<pre class="ilfbox_code">
 +
<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>11375^Musterdoc^Josef^Maria^Msc^DIDr^^^&amp;amp;1.2.40.0.34.99.4613.3.3&amp;amp;ISO
 +
          </Value>
 +
        </ValueList>
 +
    </Slot>   
 +
</Classification></pre>
  
confidentialityCode wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
 
  
$code = "N"<br />$displayName = "normal"<br />$codeSystem = "2.16.840.1.113883.5.25"
+
2. Fall: Bei der lokalen ID handelt es sich um eine OID:
  
<br />
+
concat(<br />
 
+
<span> $id</span>,"^",<br />
<pre class="ilfbox_code">
+
<span> $person</span><br />
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
+
)<br /><pre class="ilfbox_code">
     classifiedObject="theDocument" nodeRepresentation="N">
+
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
    <Name>
+
     classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
        <LocalizedString value="normal"/>
+
    id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
    </Name>
+
     <Slot name="authorPerson">
     <Slot name="codingScheme">
 
 
         <ValueList>
 
         <ValueList>
             <Value>urn:oid:2.16.840.1.113883.5.25</Value>
+
             <Value>2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value>
 
         </ValueList>
 
         </ValueList>
     </Slot>
+
     </Slot>  
 
</Classification></pre>
 
</Classification></pre>
 +
Dies folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf die XCN Komponenten wie in IHE RAD TF-2 Rev.19 2020<ref name="IHERADTF2">IHE Radiology (RAD) Technical Framework Volume 2x Rev.19, 2020 [https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf]</ref>, "Table 4.68.4.1.2.3-3: XCN Data type mapping" vorgegeben.
  
===creationTime===
+
=====Spezifikation für Software und Geräte=====
Das creationTime Element beschreibt den Zeitpunkt der Erstellung des registrieren Doku-ments oder Objektes. Es soll die Zeit angegeben werden, die diese Erstellungszeit am besten beschreibt:
 
  
#Erstellungsdatum der Studie (aus dem KOS Objekt oder der DICOM Studie):
+
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
#*Study Date (0008,0020)
 
#*Study Time (0008,0030)
 
#Sollten das zuvor genannte Attribut nicht verfügbar sein, muss alternativ das Erstellungsdatum des KOS Objektes verwendet werden:
 
#*Content Date (0008,0023)
 
#*Content Time (0008,0033)
 
  
Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From ''UTC''[[#%20ftn1|[3]]] berücksichtigt werden, falls angegeben:
+
$Modality = Modality (0008,0060)
  
*Timezone Offset From UTC (0008,0201)
+
$Manufacturer = Manufacturer (0008,0070)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
 
*#YYYYMMDD
 
*#YYYYMMDDhhmmss
 
  
[[#%20ftnref1|[3]]] <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</nowiki>
+
$ManufacturersModelName = Manufacturer's Model Name (0008,1090)
====Spezifikation====
 
  
'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />
 
  
$date = (0008,0020) Study Date – oder (0008,0023) Content Date
+
concat(
  
$time = (0008,0030) Study Time - oder (0008,0033) Content Time +(0008,0201) Timezone Offset from UTC
+
"^",
  
 +
$Modality,"^",
  
concat(
+
$Manufacturer,"^",
  
@date,
+
$ManufacturersModelName
  
@time
+
)<br /><pre class="ilfbox_code">
 +
<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>^CT^Geräthersteller^Gerätename</Value>
 +
        </ValueList>
 +
    </Slot>
 +
</Classification></pre>
  
)
+
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.
<br /><pre class="ilfbox_code">
+
 
<ExtrinsicObject mimeType="text/xml"
+
====authorRole====
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
+
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objekt Erzeugung innehatte.
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
+
 
    id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
+
Dieser Leitfaden beschreibt keine Einschränkungen für die Verwendung.
    <Slot name="creationTime">
+
 
        <ValueList>
+
Beispiel:
            <Value>20100511134500</Value>
 
        </ValueList>
 
    </Slot>
 
</ExtrinsicObject>
 
</pre>
 
  
{{BeginYellowBox}}
+
*"Radiologie"
Das Datum MUSS immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 20160518 in 20160518000000).
+
*"Modalität"
  
In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher MUSS eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß [IHE ITI-TF3].{{EndYellowBox}}
+
====authorSpeciality====
 +
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das KOS-Objekt verfasst hat.
  
===eventCodeList (und eventCodeListDisplayName)===
+
Beispiel:
Dieses Element enthält eine Liste der erbrachten Gesundheitsdienstleistungen, die das registrierte Dokument oder Objekt beschreibt. Im Fall von Bilddaten findet der APPC Anwendung. (Die korrekte Verwendung von APPC in DICOM Objekten wird im entsprechenden Leitfaden der DICOM Austria spezifiziert: „Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten“.[[# ftn4|[4]]]) 
 
Es können mehrere APPC bzw. Events (und displayNames) angegeben werden. Sind mehrere Events vorhanden, muss die Reihenfolge der Events und zugehörigen displayNames gleich sein.
 
----[[# ftnref4|[4]]] DICOM Austria: „Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten“, 22.01.2020,  <nowiki>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</nowiki> (zuletzt besucht am 12.3.2020)
 
  
====Spezifikation====
+
*"Facharzt für Radiologie"
 +
*"Facharzt für Nuklearmedizin"
  
'''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />
+
=====Spezifikation=====
  
Für jedes documentationOf Element 1..n:<br />
+
'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
<span>$code </span>= APPC code (alle Achsen) z.B. "2.4.0.5-3-3"<br />
+
Bsp: Fachärztin/Facharzt für Radiologie<br />
<span>$displayName</span> = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule"<br />
 
<span>$codeSystem</span> = OID des Codesystems APPC: 1.2.40.0.34.5.38<br />
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<Classification
+
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
    classificationScheme=
+
     classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
+
     id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
     classifiedObject="theDocument"
+
     <Slot name="authorSpeciality">
     nodeRepresentation="$code">
 
     <Slot name="codingScheme">
 
 
         <ValueList>
 
         <ValueList>
             <Value>urn:oid:$codeSystem</Value>
+
             <Value>Fachärztin/Facharzt für Radiologie</Value>
 
         </ValueList>
 
         </ValueList>
     </Slot>
+
     </Slot>  
    <Name>
 
        <LocalizedString value="$displayName"/>
 
    </Name>
 
 
</Classification>
 
</Classification>
 
</pre>
 
</pre>
 +
{{BeginYellowBox}}
 +
Wenn eine Person als Autor vorhanden ist, '''MUSS''' der Wert einem DisplayName aus dem Value Set "ELGA_AuthorSpeciality" entsprechen.
 +
 +
Im Fall von Geräten oder Software als Autor '''MUSS''' das Element leer bleiben.
  
===languageCode===
+
{{EndYellowBox}}
Das ''languageCode'' Element beschreibt den Sprachcode in dem ein Dokument oder Objekt verfasst bzw. beschlagwortet ist. Derzeit wird ein fester Wert vorgeschrieben: '''de-AT'''
 
====Spezifikation====
 
  
'''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
===classCode (und classCodeDisplayName)===
 +
Das ''classCode'' Element klassifiziert (grobe Granularität) das registrierte Objekt und ist relevant für das Berechtigungssystem.
  
Fester Wert "de-AT"
+
Unterscheidung classCode/typeCode:
<pre class="ilfbox_code">
+
{| class="wikitable"
<ExtrinsicObject mimeType="text/xml"
+
|- style="background:white"
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
+
|'''''classCode'''''
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
+
|'''''Objektklasse in grober Granularität'''''
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
+
|- style="background:white"
     <Slot name="languageCode">
+
|''typeCode''
 +
|Objektklasse  in feiner Granularität.<br />  Siehe  Kapitel [[ILF:XDS Metadaten (Version 3)#typeCode_.28und_typeCodeDisplayName.29|typeCode]]
 +
|}
 +
 
 +
====Spezifikation====
 +
 
 +
'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br />
 +
 
 +
Es wird ein fester Wert gesetzt:  55113-5 "Key images Document Radiology" (LOINC: 2.16.840.1.113883.6.1)
 +
 
 +
$code = "55113-5"<br />$displayName = "Key images Document Radiology"<br />$codeSystem = "2.16.840.1.113883.6.1"<br />
 +
<pre class="ilfbox_code">
 +
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
 +
     classifiedObject="theDocument" nodeRepresentation="$code">
 +
     <Name>
 +
        <LocalizedString value="$displayName"/>
 +
    </Name>
 +
     <Slot name="codingScheme">
 
         <ValueList>
 
         <ValueList>
             <Value>de-AT</Value>
+
             <Value>urn:oid:$codeSystem</Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>
 
     </Slot>
</ExtrinsicObject>
+
</Classification>
 
</pre>
 
</pre>
  
===legalAuthenticator===
+
===confidentialityCode===
Dieses Element darf für XDS-I nicht verwendet werden [NP].  
+
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.
  
===serviceStartTime / serviceStopTime===
+
Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf KOS-Objekte ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt, bzw. fix auf "normal" (N) gesetzt.  
Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts bzw. der Untersuchung. Für KOS-Objekte kann die ''serviceStartTime'' aus dem Objekt gemappt werden:
 
  
#Das Erstellungsdatum des DICOM Objektes aus den Attributen des KOS Objektes:
+
Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich. Es wird der Vertraulichkeitscode gemäß folgender Spezifikation übernommen:
#*Study Date (0008,0020)
 
#*Study Time (0008,0030)
 
#Alle Zeiten müssen in XDS in UTC konvertiert werden, daher sollte Timezone Offset From UTC berücksichtigt werden, falls angegeben:
 
#*Timezone Offset From UTC (0008,0201)
 
  
Für die serviceStopTime steht kein Mapping zur Verfügung und wird daher nicht angegeben [NP].
+
Zulässige Werte gemäß Value Set "ELGA_Confidentiality" <ref name="ConfVS">Value Set "ELGA_Confidentiality" https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality</ref>.
  
 
====Spezifikation====
 
====Spezifikation====
  
'''serviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
confidentialityCode wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
concat(
+
$code = "N"<br />$displayName = "normal"<br />$codeSystem = "2.16.840.1.113883.5.25"
  
Study Date,
+
<pre class="ilfbox_code">
 
+
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
Study Time + Timezone Offset from UTC
+
     classifiedObject="theDocument" nodeRepresentation="N">
 
+
     <Name>
)
+
        <LocalizedString value="normal"/>
<br /><pre class="ilfbox_code">
+
    </Name>
<ExtrinsicObject mimeType="text/xml"
+
     <Slot name="codingScheme">
    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="serviceStartTime">
 
 
         <ValueList>
 
         <ValueList>
             <Value>20100511134500</Value>
+
             <Value>urn:oid:2.16.840.1.113883.5.25</Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>
 
     </Slot>
</ExtrinsicObject>
+
</Classification></pre>
</pre>
 
{{BeginYellowBox}}
 
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 20160518 in 20160518000000).
 
  
In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden!
+
===creationTime===
 +
Das creationTime Element beschreibt den Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes. Es soll die Zeit angegeben werden, die diese Erstellungszeit am besten beschreibt:
  
{{EndYellowBox}}
+
#Erstellungsdatum der Studie (aus dem KOS Objekt oder der DICOM Studie):
 +
#*Study Date (0008,0020)
 +
#*Study Time (0008,0030)
 +
#Sollte das zuvor genannte Attribut nicht verfügbar sein, muss alternativ das Erstellungsdatum des KOS Objektes verwendet werden:
 +
#*Content Date (0008,0023)
 +
#*Content Time (0008,0033)
  
===sourcePatientId===
+
Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From ''UTC''<ref>Timezone Offset From UTC http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</ref> berücksichtigt werden, falls angegeben:
Das ''sourcePatientId'' Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA.
 
  
Für ein Mapping aus KOS steht folgendes Attribut zur Verfügung:
+
*Timezone Offset From UTC (0008,0201)
 
+
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
(0010,0020) Patient ID (VR:LO, VM:1)
+
*#YYYYMMDD
 +
*#YYYYMMDDhhmmss
  
Eine OID zur Definition des Namensraumes des verwendeten Patientenidentifikators muss entsprechend vorhanden sein.
 
 
====Spezifikation====
 
====Spezifikation====
  
'''sourcePatientId''' wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />
  
$patientID = (0010,0020) Patient ID
+
$date = (0008,0020) Study Date oder (0008,0023) Content Date
  
$oid = OID des lokalen Patientenidentifikators
+
$time = (0008,0030) Study Time oder (0008,0033) Content Time und (0008,0201) Timezone Offset from UTC
  
  
 
concat(
 
concat(
  
$patientID,
+
$date,
  
"^^^&amp;amp;",
+
$time
  
$oid,
+
)<pre class="ilfbox_code">
 
 
"&amp;amp;ISO"
 
 
 
)
 
<pre class="ilfbox_code">
 
 
<ExtrinsicObject mimeType="text/xml"
 
<ExtrinsicObject mimeType="text/xml"
 
     objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
 
     objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
 
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
 
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
 
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
 
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
     <Slot name="sourcePatientId">
+
     <Slot name="creationTime">
 
         <ValueList>
 
         <ValueList>
<Value>4711^^^&amp;amp;1.2.3.4.5.6.7.8.9&amp;amp;ISO</Value>
+
            <Value>20100511134500</Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>
 
     </Slot>
 
</ExtrinsicObject>
 
</ExtrinsicObject>
 
</pre>
 
</pre>
Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß [IHE ITI-TF3].
 
 
===sourcePatientInfo===
 
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel 3.2.12 sourcePatientId gemappt und verwendet[[#%20ftn1|[5]]].
 
----[[#%20ftnref1|[5]]] IHE RAD TF vol3 Vorgaben Table 4.68.4.1.2.3-1: XDS-I.b-specific Metadata Requirements
 
 
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
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. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
+
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).  
{{EndYellowBox}}
 
  
====Spezifikation (empfohlene Variante)====
+
In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.{{EndYellowBox}}
'''sourcePatientInfo''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
 
  
$id = concat(
+
===eventCodeList (und eventCodeListDisplayName)===
 +
Dieses Element enthält eine Liste der erbrachten Gesundheitsdienstleistungen, die das registrierte Dokument oder Objekt beschreibt. Im Fall von Bilddaten findet der APPC Anwendung. (Die korrekte Verwendung von APPC in DICOM Objekten wird im entsprechenden Leitfaden der DICOM Austria spezifiziert: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten"<ref name="KOS-Leitfaden"></ref>). 
 +
Es können mehrere APPC bzw. Events (und displayNames) angegeben werden. Sind mehrere Events vorhanden, muss die Reihenfolge der Events und zugehörigen displayNames gleich sein.
  
$patientID, "^^^&amp;amp;",
+
====Spezifikation====
  
$oid, "&amp;amp;ISO"
+
'''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />
  
)
+
Für jedes documentationOf Element [1..n]:<br />
  
Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO
+
<span>$code </span>= APPC code (alle Achsen) z.B. "2.4.0.5-3-3"<br />
 
+
<span>$displayName</span> = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule"<br />
$name = ""  
+
<span>$codeSystem</span> = OID des Codesystems APPC: 1.2.40.0.34.5.38<br />
 
+
<pre class="ilfbox_code">
$birthtime = ""  
+
<Classification
 
+
    classificationScheme=
$gender = ""
+
     "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
 
+
     classifiedObject="theDocument"
$addr = "" <pre class="ilfbox_code">
+
     nodeRepresentation="$code">
<ExtrinsicObject mimeType="text/xml"
+
     <Slot name="codingScheme">
     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="sourcePatientInfo">
 
 
         <ValueList>
 
         <ValueList>
<Value>PID-3|$id</Value>
+
            <Value>urn:oid:$codeSystem</Value>
<Value>PID-5|$name</Value>
 
<Value>PID-7|$birthtime</Value>
 
<Value>PID-8|$gender</Value>
 
<Value>PID-11|$addr</Value>
 
 
         </ValueList>
 
         </ValueList>
 
     </Slot>
 
     </Slot>
</ExtrinsicObject>
+
    <Name>
 +
        <LocalizedString value="$displayName"/>
 +
    </Name>
 +
</Classification>
 
</pre>
 
</pre>
===title===
 
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.
 
  
Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
+
===languageCode===
 
+
Das ''languageCode'' Element beschreibt den Sprachcode in dem ein Dokument oder Objekt verfasst bzw. beschlagwortet ist. Derzeit wird ein fester Wert vorgeschrieben: '''de-AT'''
#Wenn die Informationen aus der Studie verfügbar sind: Study Description
 
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
 
#*(0008,1030) Study Description, Datentyp LO
 
#Wenn mehrere Modailty Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
 
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. („CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule“
 
 
 
{{BeginYellowBox}}
 
 
 
'''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall “KO”.
 
{{EndYellowBox}}<br />
 
 
====Spezifikation====
 
====Spezifikation====
  
'''title''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:
+
'''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
concat(
+
Fester Wert "de-AT"
 
+
<pre class="ilfbox_code">
Modality,
 
 
 
" ",
 
 
 
Study Description
 
 
 
)<pre class="ilfbox_code">
 
 
<ExtrinsicObject mimeType="text/xml"
 
<ExtrinsicObject mimeType="text/xml"
 
     objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
 
     objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
 
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
 
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
 
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
 
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
     <Name>
+
     <Slot name="languageCode">
         <LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" />
+
         <ValueList>
     </Name>
+
            <Value>de-AT</Value>
 +
        </ValueList>
 +
     </Slot>
 
</ExtrinsicObject>
 
</ExtrinsicObject>
 
</pre>
 
</pre>
{{BeginYellowBox}}
 
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
 
{{EndYellowBox}}
 
  
===typeCode (und typeCodeDisplayName)===
+
===legalAuthenticator===
Das ''typeCode'' Element beschreibt den Objekttyp, dem das KOS Objekt angehört. Der Objekttyp ist die Spezialisierung einer Objektklasse, jeder Objekttyp gehört zu genau einer Objektklasse.
+
Dieses Element darf für XDS-I nicht verwendet werden [NP].
 +
 
 +
===serviceStartTime / serviceStopTime===
 +
Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts bzw. der Untersuchung. Für KOS-Objekte kann die ''serviceStartTime'' aus dem Objekt gemappt werden:
 +
 
 +
#Das Erstellungsdatum der Studie (aus dem KOS Objekt oder bevorzugt der DICOM Studie):
 +
#*Study Date (0008,0020)
 +
#*Study Time (0008,0030)
 +
#Alle Zeiten müssen in XDS in UTC konvertiert werden, daher sollte Timezone Offset From UTC berücksichtigt werden, falls angegeben:
 +
#*Timezone Offset From UTC (0008,0201)
  
Unterscheidung typeCode/classCode:
+
Für die serviceStopTime steht kein Mapping zur Verfügung und wird daher nicht angegeben [NP].
{| class="wikitable"
 
|- style="background:white"
 
|'''typeCode'''
 
|'''Objektklasse in feiner Granularität (Spezialisierung).'''
 
|- style="background:white"
 
|classCode
 
|Objektklasse  in grober Granularität.<br />  Siehe Kapitel [[ILF:XDS Metadaten 2020#classCode_.28und_classCodeDisplayName.29|classCode]]
 
|}
 
  
 
====Spezifikation====
 
====Spezifikation====
 +
'''serviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
'''typeCode (und typeCodeDisplayName)''' wird  wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:
+
concat(
  
Es wird ein fester Wert gesetzt:  '''55113-5''' „Key images Document Radiology“
+
Study Date,
  
<span> $code</span> = "55113-5"<br /><span> $displayName</span> = "Key images Document Radiology"<br /><span> $codeSystem</span> = "2.16.840.1.113883.6.1"<br />
+
Study Time + Timezone Offset from UTC
 +
 
 +
)
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<Classification
+
<ExtrinsicObject mimeType="text/xml"
     classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
+
     objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
     classifiedObject="KeyImageObject"
+
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
     nodeRepresentation="$code">
+
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
    <Name>
+
     <Slot name="serviceStartTime">
        <LocalizedString value="$displayName"/>
 
    </Name>
 
     <Slot name="codingScheme">
 
 
         <ValueList>
 
         <ValueList>
             <Value>urn:oid:$codeSystem</Value>
+
             <Value>20100511134500</Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>
 
     </Slot>
</Classification>
+
</ExtrinsicObject>
 
</pre>
 
</pre>
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
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).
+
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).
 +
 
 +
In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden!
 
{{EndYellowBox}}
 
{{EndYellowBox}}
  
====submissionSet.contentTypeCode====
+
===sourcePatientId===
Der contentTypeCode  des SubmissionSets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.
+
Das ''sourcePatientId'' Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA.
  
$code = "55113-5"
+
Für ein Mapping aus KOS steht folgendes Attribut zur Verfügung:
  
$displayName = "Key images Document Radiology"
+
(0010,0020) Patient ID (VR:LO, VM:1)
  
$codeSystem = "2.16.840.1.113883.6.1"<pre class="ilfbox_code">
+
Eine OID zur Definition des Namensraumes des verwendeten Patientenidentifikators muss entsprechend vorhanden sein.
<RegistryPackage
+
====Spezifikation====
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
+
 
    <Classification
+
'''sourcePatientId''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
        classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
 
        classifiedObject="KeyImageObject"
 
        nodeRepresentation="$code">
 
        <Name>
 
            <LocalizedString value="$displayName"/>
 
        </Name>
 
        <Slot name="codingScheme">
 
            <ValueList>
 
                <Value>urn:oid:$codeSystem</Value>
 
            </ValueList>
 
        </Slot>
 
    </Classification>
 
</RegistryPackage>
 
</pre>Jeder Container darf dementsprechend nur 1 Dokument enthalten.
 
  
===uniqueId===
+
$patientID = (0010,0020) Patient ID
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 KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
+
$oid = OID des lokalen Patientenidentifikators
  
(0008,0018) SOP Instance UID (VR:UI, VM:1)
 
====Spezifikation====
 
  
uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:<br />
+
concat(
  
$value = (0008,0018) SOP Instance UID
+
$patientID,
  
<br />
+
"^^^&amp;amp;",
  
<pre class="ilfbox_code">
+
$oid,
<ExternalIdentifier
 
registryObject="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"
 
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
 
value="$value">
 
    <Name>
 
        <LocalizedString value="XDSDocumentEntry.uniqueId"/>
 
    </Name>
 
</ExternalIdentifier></pre>
 
  
===referenceIdList===
+
"&amp;amp;ISO"
Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Für Bilddaten sind zwei unterschiedliche Einträge in referenceIdList notwendig:
 
  
#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId)
+
)
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number)
 
  
'''Weitere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.'''
+
<pre class="ilfbox_code">
 +
<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="sourcePatientId">
 +
        <ValueList>
 +
            <Value>4711^^^&amp;amp;1.2.3.4.5.6.7.8.9&amp;amp;ISO</Value>
 +
        </ValueList>
 +
    </Slot>
 +
</ExtrinsicObject>
 +
</pre>
 +
Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.
  
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
+
===sourcePatientInfo===
 +
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.
 +
{{BeginYellowBox}}
 +
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. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
 +
{{EndYellowBox}}
  
Dieser Datentyp ist in IHE ITI Data Types in folgender Weise spezifiziert:<ref name="IHE ITI TF-3"></ref>
+
===title===
 +
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.
  
{| class="wikitable" width="100%"
+
Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
!Data Type||Source Standard||Encoding Specification
+
 
|-
+
#Wenn die Informationen aus der Studie verfügbar sind: Study Description
|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.<br />
+
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
Therefore, Universal Id Type is always ISO. The required format is: <br />IdNumber^^^&OIDofAA&ISO<br />No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above.<br />An explicit example is:<br />543797436^^^&1.2.840.113619.6.197&ISO<br />Note that the '&' character must be properly encoded in the XML content.
+
#*(0008,1030) Study Description, Datentyp LO
|-
+
#Wenn mehrere Modality Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
|'''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.'''
+
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. ("CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule")
*'''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.'''
 
|}
 
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
 
+
'''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
'''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..
 
 
{{EndYellowBox}}
 
{{EndYellowBox}}
 +
====Spezifikation====
  
====Versionierung bzw. Versionsklammer (ownDocument_setId)====
+
'''title''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:
Um eine eindeutige Identifikation aller registrierten Versionen eines Dokuments (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Es kann ein beliebiger Identifikator verwendet werden, solange er die Anforderung erfüllt, alle registrierten Versionen eines Dokuments mit derselben ID eindeutig zu kennzeichnen. Als Best Practice für KOS wird die Verwendung von ''StudyInstanceUID'' vorgeschlagen.
 
  
=====Spezifikation=====
+
concat(
ownDocument-SetId wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
 
  
Für KOS Objekte kann die ''StudyInstanceUID'' (0020,000D) als SetId verwendet werden.
+
Modality,
  
$id = (0020,000D) VR=UI Study Instance UID, z.B. 1.2.40.0.34.99.111.1.1
+
" ",
  
$homeCommunityId = OID des lokalen ELGA-Bereiches z.B. 1.2.40.0.34.99.999
+
Study Description
  
 +
)<pre class="ilfbox_code">
 +
<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">
 +
    <Name>
 +
        <LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" />
 +
    </Name>
 +
</ExtrinsicObject>
 +
</pre>
 +
{{BeginYellowBox}}
 +
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
 +
{{EndYellowBox}}
  
concat
+
===typeCode (und typeCodeDisplayName)===
 
+
Das ''typeCode'' Element beschreibt den Objekttyp, dem das KOS Objekt angehört. Der Objekttyp ist die Spezialisierung einer Objektklasse, jeder Objekttyp gehört zu genau einer Objektklasse.
(
 
 
 
$id, "^^^^",
 
 
 
"urn:elga:iti:xds:2014:ownDocument_setId", "^",  
 
  
"&amp;amp;",
+
Unterscheidung typeCode/classCode:
 +
{| class="wikitable"
 +
|- style="background:white"
 +
|'''typeCode'''
 +
|'''Objektklasse in feiner Granularität (Spezialisierung).'''
 +
|- style="background:white"
 +
|classCode
 +
|Objektklasse  in grober Granularität.<br />  Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29|classCode]]
 +
|}
  
$homeCommunityId, "&amp;amp;ISO"
+
====Spezifikation====
  
)
+
'''typeCode (und typeCodeDisplayName)''' wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:
  
 +
Es wird ein fester Wert gesetzt:  '''55113-5''' "Key images Document Radiology"
  
Wie oben angeführt wird folgender CXi Wert erstellt:
+
<span> $code</span> = "55113-5"<br /><span> $displayName</span> = "Key images Document Radiology"<br /><span> $codeSystem</span> = "2.16.840.1.113883.6.1"<br />
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
+
<Classification
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
+
    classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
+
    classifiedObject="KeyImageObject"
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
+
    nodeRepresentation="$code">
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
+
    <Name>
        <ValueList>         <Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^amp;1.2.40.0.34.99.999
+
        <LocalizedString value="$displayName"/>
<nowiki>&</nowiki>amp;amp;ISO</Value>
+
    </Name>
        </ValueList>
+
    <Slot name="codingScheme">
    </Slot>
+
        <ValueList>
</ExtrinsicObject>
+
            <Value>urn:oid:$codeSystem</Value>
</pre>  
+
        </ValueList>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.
+
    </Slot>
 +
</Classification>
 +
</pre>
  
====Referenz zwischen Dokument und Studie ('''Accession Number''')====
+
====submissionSet.contentTypeCode====
Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (''acquisition, store'') als auch bei der Befundschreibung (''report'') verfügbar ist. Dies trifft auf die Accession Number zu (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).
+
Der contentTypeCode  des Submission Sets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.
  
=====Spezifikation=====
+
$code = "55113-5"
Bei der Registrierung von KOS Objekten MUSS eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden. 
 
  
Für Befunde der Bildgebenden Diagnostik (diagnostic image report) kann die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
+
$displayName = "Key images Document Radiology"
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
 
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
 
  
 +
$codeSystem = "2.16.840.1.113883.6.1"<pre class="ilfbox_code">
 +
<RegistryPackage
 +
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
 +
    <Classification
 +
        classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
 +
        classifiedObject="KeyImageObject"
 +
        nodeRepresentation="$code">
 +
        <Name>
 +
            <LocalizedString value="$displayName"/>
 +
        </Name>
 +
        <Slot name="codingScheme">
 +
            <ValueList>
 +
                <Value>urn:oid:$codeSystem</Value>
 +
            </ValueList>
 +
        </Slot>
 +
    </Classification>
 +
</RegistryPackage>
 +
</pre>Jeder Container darf dementsprechend nur 1 Objekt enthalten.
  
$id = Accession Number z.B. 20201111
+
===uniqueId===
 
+
Das ''uniqueId'' Element beschreibt den global eindeutigen Identifier des Objektes. Dieser Identifier wird vom Document Source Actor erzeugt.
$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1
 
 
 
concat
 
  
(
+
Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
  
$id, "^^^", "&amp;amp;"
+
(0008,0018) SOP Instance UID (VR:UI, VM:1)
 +
====Spezifikation====
  
$root,  "&amp;amp;ISO", "^",
+
uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:
  
"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
+
$value = (0008,0018) SOP Instance UID
  
)
+
<pre class="ilfbox_code">
<br /><pre class="ilfbox_code">
+
<ExternalIdentifier
<ExtrinsicObject mimeType="text/xml"
+
registryObject="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
+
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
+
value="$value">
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
+
    <Name>
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
+
         <LocalizedString value="XDSDocumentEntry.uniqueId"/>
        <ValueList>        <Value>20201111^^^amp;1.2.40.0.34.99.999
+
    </Name>
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
+
</ExternalIdentifier></pre>
        </ValueList>
 
    </Slot>
 
</ExtrinsicObject>
 
</pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 “Linking Report to Set of DICOM Instances”
 
  
====Weitere Einträge der referenceIDList====
+
===referenceIdList===
Über die bereits genannten Einträge hinaus sind weitere Einträge in der referenceIdList erlaubt:
+
Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:  
  
*'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki>  In diesem Fall wird im CXI-Wert auch „Issuing Authority“ weggelassen, weil die ID weltweit eindeutig ist.
+
#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId, M [1..1])
*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki>
+
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number, R [0..1])
 +
#Verlinkung zwischen DICOM KOS-Objekten und einer Aufenthaltszahl (encounterId, O [0..1])
  
Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<pre class="ilfbox_code">
+
'''Weitere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.'''
<ExtrinsicObject mimeType="text/xml"
 
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
 
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
 
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
 
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
 
        <ValueList>
 
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^amp;1.2.40.0.34.99.999
 
<nowiki>&</nowiki>amp;amp;ISO</Value>
 
<Value>20201111^^^amp;1.2.40.0.34.99.999
 
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
 
<Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value>
 
<Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>
 
        </ValueList>
 
    </Slot>
 
</ExtrinsicObject>
 
</pre><br />
 
===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 XDS-I.
+
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
  
===comments===
+
Dieser Datentyp ist in IHE ITI Data Types in folgender Weise spezifiziert:<ref name="ITITF3"/>
Das ''comments'' Element enthält Kommentare zum Objekt. Die Verwendung ist in ELGA optional (wird in einigen Implementierungen nicht angezeigt, z.B. ELGA Bürgerportal)
+
<!-- Seitenumbruch -->
 +
<p style="page-break-before: always"></p>
 +
{| class="wikitable" width="100%"
 +
!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.<br />
 +
Therefore, Universal Id Type is always ISO. The required format is: <br />IdNumber^^^&OIDofAA&ISO<br />No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above.<br />An explicit example is:<br />543797436^^^&1.2.840.113619.6.197&ISO<br />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.
  
Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
+
*CXi.1 shall be present and hold the identifier value.
(0008,1030) Study Description (VR:LO, VM:1)
+
*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.
 +
|}
 +
{{BeginYellowBox}}
  
====Spezifikation====
+
'''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.
Comments wird gemäß folgender Vorschrift zusammengesetzt:     
+
{{EndYellowBox}}
$comment = (0008,1030) Study Description<pre class="ilfbox_code">
 
<ExtrinsicObject mimeType="text/xml"
 
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
 
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
 
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
 
    <Description">
 
        <LocalizedString value = "$comment"/>
 
    </Description>
 
</ExtrinsicObject>
 
</pre><br />
 
  
==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
+
====Versionierung bzw. Versionsklammer (ownDocument_setId)====
===availabilityStatus===
+
Um eine eindeutige Identifikation aller registrierten Versionen eines Objektes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Es kann ein beliebiger Identifikator verwendet werden, solange er die Anforderung erfüllt, alle registrierten Versionen eines KOS-Objektes mit derselben ID eindeutig zu kennzeichnen. Als Best Practice für KOS wird die Verwendung von ''StudyInstanceUID'' vorgeschlagen.
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Objektes.
 
  
Mögliche Werte laut IHE sind:
+
=====Spezifikation=====
 +
ownDocument-SetId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
*Approved
+
Für KOS Objekte kann die ''StudyInstanceUID'' (0020,000D) als SetId verwendet werden.
*Deprecated
+
 
 +
$id = (0020,000D) VR=UI Study Instance UID, z.B. 1.2.40.0.34.99.111.1.1
 +
 
 +
$homeCommunityId = OID des lokalen ELGA-Bereiches. Diese MUSS [1..1],  unabhängig vom für $id gewählten Identifier, angeführt sein, z.B. 1.2.40.0.34.99.999
 +
 
 +
 
 +
concat
 +
 
 +
(
 +
 
 +
$id, "^^^^",
  
Dieses Attribut wird im Zuge des Einbringens von neuen Objekten („Submission“) durch die empfangende XDS Registry immer auf “'''Approved'''” gesetzt.
+
"<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>", "^",
  
availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.
+
"&amp;amp;",  
  
<pre class="ilfbox_code">
+
$homeCommunityId, "&amp;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"/>
 
</pre>
 
  
===formatCode (und formatCodeDisplayName)===
+
)
Das ''formatCode'' Element beschreibt das Format des registrierten Objekts. 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.
 
  
====Spezifikation====
 
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
 
  
<br />
+
Wie oben angeführt wird folgender CXi Wert für <Value> erstellt:
<span>$code</span> = "1.2.840.10008.5.1.4.1.1.88.59"<br />
 
<span>$displayName</span> = "Key Object Selection Document"<br />
 
<span>$codeSystem</span> = "1.2.840.10008.2.6.1"
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<Classification
+
<ExtrinsicObject mimeType="text/xml"
    classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
+
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
+
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
+
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
    nodeRepresentation="$code">
+
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
    <Name>
+
        <ValueList>        
        <LocalizedString value="$displayName"/>
+
            <Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
    </Name>
+
        </ValueList>
    <Slot name="codingScheme">
+
    </Slot>
        <ValueList>
+
</ExtrinsicObject>
            <Value>urn:oid:$codeSystem</Value>
+
</pre>  
        </ValueList>
+
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.
    </Slot>
 
</Classification>
 
</pre>
 
  
===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
+
====Referenz zwischen Dokument und Studie (Accession Number)====
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA, z.B.
+
Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (''acquisition, store'') als auch bei der Befundschreibung (''report'') verfügbar ist. Dies trifft auf die Accession Number zu (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).
  
*158 „Fachärztin/Facharzt“
+
=====Spezifikation=====
*304 „Allgemeine Krankenanstalt“
+
Bei der Registrierung von KOS Objekten SOLL eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden. Diese dient als Basis für die Verlinkung mit einem Befund der bildgebenden Diagnostik (diagnostic image report). Wird in der ReferenceIdList der XDS-I Metadaten keine Accession Number angeführt, ist eine Verlinkung nicht möglich.
 +
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
  
Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).
+
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
{{BeginYellowBox}}
 
  
Zulässige Werte gemäß Value Set „[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]“.
+
$id = Accession Number z.B. 20201111
{{EndYellowBox}}
 
  
====Spezifikation====
+
$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1
  
'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
+
concat
  
<span>$code </span>= Klassifizierung des GDA (Code)
+
(
  
<span>$displayName </span>= Klartext des angegebenen Codes
+
$id, "^^^", "&amp;amp;"
  
<span>$codeSystem </span>= OID der ausgebenden Stelle
+
$root, "&amp;amp;ISO", "^",
   
 
<pre class="ilfbox_code">
 
<Classification
 
    classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
 
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
 
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
 
    nodeRepresentation="$code">
 
    <Name>
 
        <LocalizedString value="$displayName"/>
 
    </Name>
 
    <Slot name="codingScheme">
 
        <ValueList>
 
            <Value>urn:oid:$codeSystem</Value>
 
        </ValueList>
 
    </Slot>
 
</Classification>
 
</pre>
 
  
===mimeType===
+
"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
Das ''mimeType'' Element beschreibt den „Internet Media Type“ des Dokuments gemäß dem „Multipurpose Internet Mail Extensions“ (MIME) Standard. Der Standard wird beschrieben in [https://tools.ietf.org/html/rfc2045 <nowiki>RFC 2045[6]</nowiki>] und RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>
 
  
Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".
+
)<pre class="ilfbox_code">
 
+
<ExtrinsicObject mimeType="text/xml"
[6] <nowiki>http://tools.ietf.org/html/rfc2045</nowiki>
+
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
 +
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
 +
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
 +
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
 +
        <ValueList>       
 +
            <Value>20201111^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
 +
        </ValueList>
 +
    </Slot>
 +
</ExtrinsicObject>
 +
</pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"
  
[7] <nowiki>http://tools.ietf.org/html/rfc2049</nowiki>
+
====Referenz zwischen Aufenthaltszahl und Studie (encounterId)====
 +
Durch encounterId wird die Verlinkung sämtlicher Bilddaten (DICOM KOS-Objekte), die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-I Metadaten unterstützt. Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird.
  
====Spezifikation====
+
=====Spezifikation=====
 +
Bei der Registrierung von KOS Objekten KANN eine encounterId in den XDS-I Metadaten in der ReferenceIdList angegeben werden. 
  
'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.
+
encounterId wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
Folgende Mime-Types sind für DICOM KOS Objekte zugelassen:
 
  
*application/dicom<br />
+
$id = Aufenthaltszahl z.B. Az123456
<pre class="ilfbox_code">
 
<ExtrinsicObject
 
            id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
 
            mimeType="application/dicom"
 
            objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
 
            status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>
 
</pre>
 
===practiceSettingCode (und practiceSettingCodeDisplayName)===
 
Das ''practiceSettingCode'' Element beschreibt die fachliche Zuordnung des Objektes. Es soll den Fachbereich wiedergeben, dem der Inhalt des Objektes am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung, z.B.:
 
  
*F044 „Radiologie“
+
$root = OID der Liste der Aufenthaltszahlen der Organisation, z.B. 1.2.40.0.34.99.4613.3.4
*F052 „Unfallchirurgie“
 
  
Im KOS-Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
+
concat
  
{{BeginYellowBox}}
+
(
  
Zulässige Werte gemäß Value Set „[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_PracticeSetting_VS ELGA_PracticeSetting_VS]“.
+
$id, "^^^", "&amp;amp;"
{{EndYellowBox}}
 
  
====Spezifikation====
+
$root,  "&amp;amp;ISO", "^",
  
'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classificationgemäß folgender Vorschrift zusammengesetzt:
+
"<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"
  
<span>$code</span> = Code aus Value Set ELGA_PracticeSetting<br /><span>$displayName</span> = Klartext des angegebenen Codes (displayName)<br /><span>$codeSystem</span> = OID des Codesystems (1.2.40.0.34.5.12)<br />
+
)<pre class="ilfbox_code">
<pre class="ilfbox_code">
+
<ExtrinsicObject mimeType="text/xml"
<Classification
+
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
    classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
+
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
+
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
+
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
    nodeRepresentation="$code">
+
        <ValueList>        
    <Name>
+
            <Value>Az123456^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.4613.3.4<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>
        <LocalizedString value="$displayName"/>
+
            </Value>
    </Name>
+
        </ValueList>
    <Slot name="codingScheme">
+
    </Slot>
        <ValueList>
+
</ExtrinsicObject>
            <Value>urn:oid:$codeSystem</Value>
 
        </ValueList>
 
    </Slot>
 
</Classification>
 
 
</pre>
 
</pre>
  
===objectType===
+
====Weitere Einträge der referenceIDList====
Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen „stabiles Dokument“ (stable document, SD) und „On-demand Dokument“ (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.
+
Über die bereits genannten Einträge hinaus sind weitere Einträge in der referenceIdList erlaubt:
  
Für KOS Objekte wird der fixe Wert "[[urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be]]" für "Stable Document" vorgegeben:
+
*'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki>.  In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.
<pre class="ilfbox_code">
+
*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki>
<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"/>
 
</pre>
 
  
==ELGA-spezifische Erweiterungen der XDS-Metadaten==
+
Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<pre class="ilfbox_code">
Die folgenden Daten entsprechen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information.  
+
<ExtrinsicObject mimeType="text/xml"
 +
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
 +
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
 +
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
 +
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
 +
        <ValueList>             
 +
            <Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId
 +
</nowiki>^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
 +
            <Value>20201111^^^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
 +
            <Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value>
 +
            <Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>
 +
        </ValueList>
 +
    </Slot>
 +
</ExtrinsicObject>
 +
</pre>
  
===elgaFlag===
+
===intendedRecipient===
Das elgaFlag dient zur Kennzeichnung eines Dokuments als „ELGA-Dokument“<sup>18</sup>. 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:
+
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.
 
 
*"true"    oder
 
*"false"
 
  
====Spezifikation====
+
Der intendedRecipient entfällt bei der Registrierung von KOS Objekten via XDS-I.
 
 
<pre class="ilfbox_code">
 
<Slot name="urn:elga-bes:elgaFlag">
 
    <ValueList>
 
        <Value>true</Value>
 
    </ValueList>
 
</Slot>
 
</pre>
 
  
 +
===comments===
 +
Das ''comments'' Element enthält Kommentare zum Objekt. Die Verwendung ist in ELGA optional (wird in einigen Implementierungen nicht angezeigt, z.B. ELGA Bürgerportal)
  
 +
Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
 +
(0008,1030) Study Description (VR:LO, VM:1)
  
<sup>18</sup> 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.
+
====Spezifikation====
 +
Comments wird gemäß folgender Vorschrift zusammengesetzt:     
 +
$comment = (0008,1030) Study Description<pre class="ilfbox_code">
 +
<ExtrinsicObject mimeType="text/xml"
 +
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
 +
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
 +
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
 +
    <Description">
 +
        <LocalizedString value = "$comment"/>
 +
    </Description>
 +
</ExtrinsicObject>
 +
</pre><br />
  
===elgaHash===
+
==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
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.
+
===availabilityStatus===
 +
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Objektes.
  
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.
+
Mögliche Werte laut IHE sind:
  
====Spezifikation====
+
*Approved
<pre class="ilfbox_code">
+
*Deprecated
  <rim:Slot name="urn:elga-bes:elgaHash">
 
    <rim:ValueList>
 
      <rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>
 
    </rim:ValueList>
 
  </rim:Slot>
 
</pre>
 
  
 +
Dieses Attribut wird im Zuge des Einbringens von neuen Objekten ("Submission") durch die empfangende XDS Registry immer auf "'''Approved'''" gesetzt.
  
 +
availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.
  
 +
<pre class="ilfbox_code">
 +
<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"/>
 +
</pre>
  
<!--Anhänge-->
+
===formatCode (und formatCodeDisplayName)===
<references />
+
Das ''formatCode'' Element beschreibt das Format des registrierten Objekts. Es ermöglicht einem empfangenden System (''Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Objektformats und somit die korrekte Darstellung und Verarbeitung.
 
 
=XDS Metadaten für CDA Dokumente=
 
==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==
 
  
===author===
+
====Spezifikation====
Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
+
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
  
CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen.
+
<br />
 
+
<span>$code</span> = "1.2.840.10008.5.1.4.1.1.88.59"<br />
 
+
<span>$displayName</span> = "Key Object Selection Document"<br />
====authorInstitution====
+
<span>$codeSystem</span> = "1.2.840.10008.2.6.1"
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurde.
+
<pre class="ilfbox_code">
 
+
<Classification
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
+
    classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
# Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört grundsätzlich in folgendem Element abgelegt:
+
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
## ClinicalDocument/author/assignedAuthor/representedOrganization
+
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
# Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:
+
    nodeRepresentation="$code">
## '''id'''[1] … ID der Organisation mit den folgenden Attributen:
+
    <Name>
### @root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)
+
        <LocalizedString value="$displayName"/>
### @extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)
+
    </Name>
## '''name''' … Name der Organisation als String<br /> 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.<br /> Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" →  "Wien AKH" bzw "Wien AKH - Augenambulanz"  
+
    <Slot name="codingScheme">
 
+
        <ValueList>
# GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente „GDA Index“ mit einer eindeutigen OID ausgestattet.
+
            <Value>urn:oid:$codeSystem</Value>
# Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
+
        </ValueList>
{{BeginYellowBox}}
+
    </Slot>
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
+
</Classification>
{{EndYellowBox}}
+
</pre>
  
 +
===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
 +
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA, z.B.
  
=====Spezifikation=====
+
*158 "Fachärztin/Facharzt"
 +
*300 "Allgemeine Krankenanstalt"
  
'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).
 +
{{BeginYellowBox}}
 +
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]".
 +
{{EndYellowBox}}
  
 +
====Spezifikation====
  
<span >$inst</span> … ClinicalDocument/author/assignedAuthor/representedOrganization
+
'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
  
 +
<span>$code </span>= Klassifizierung des GDA (Code)
  
* Fall 1:<br/>
+
<span>$displayName </span>= Klartext des angegebenen Codes
Element $inst/id[1] ist vorhanden<br/>
 
Attribut $inst/id[1]/@root ist vorhanden<br/>
 
Attribut $inst/id[1]/@extension ist nicht vorhanden<br/>
 
  
concat(<br/>
+
<span>$codeSystem </span>= OID der ausgebenden Stelle
<span>$inst</span>/name,"^^^^^^^^^",<br/>
+
<span>$inst</span>/id[1]/@root<br/>
 
)<br/>
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
+
<Classification
 +
    classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
 
     classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
 
     classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
     id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
+
     id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
     <Slot name="authorInstitution">
+
    nodeRepresentation="$code">
 +
    <Name>
 +
        <LocalizedString value="$displayName"/>
 +
    </Name>
 +
     <Slot name="codingScheme">
 
         <ValueList>
 
         <ValueList>
             <Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;amp;ISO</Value>
+
             <Value>urn:oid:$codeSystem</Value>
 
         </ValueList>
 
         </ValueList>
     </Slot>  
+
     </Slot>
 
</Classification>
 
</Classification>
 
</pre>
 
</pre>
  
 +
===mimeType===
 +
Das ''mimeType'' Element beschreibt den "Internet Media Type" des Objektes gemäß dem "Multipurpose Internet Mail Extensions" (MIME) Standard. Der Standard wird beschrieben in RFC 2045<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref> und RFC 2049<ref name="RFC2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>.
  
*Fall 2:<br/>
+
Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".
Element $inst/id[1] ist vorhanden<br/>
 
Attribut $inst/id[1]/@root ist vorhanden<br/>
 
Attribut $inst/id[1]/@extension ist vorhanden<br/>
 
  
concat(<br/>
+
====Spezifikation====
<span >$inst</span>/name,"^^^^^&",<br/>
 
<span >$inst</span>/id[1]/@root,"&ISO^^^^"<br/>
 
<span >$inst</span>/id[1]/@extension<br/>
 
)<br/>
 
<pre class="ilfbox_code">
 
<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&amp;amp;ISO^^^^45</Value>
 
        </ValueList>
 
    </Slot>   
 
</Classification>
 
</pre>
 
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß [IHE ITI-TF3].
 
  
====authorPerson====
+
'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, welches das DocumentEntry repräsentiert.
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:
+
Folgende Mime-Types sind für DICOM KOS Objekte zugelassen:
# Laut Festlegung wird der Autor im Header-Element „author“ abgelegt:
 
## ClinicalDocument/author/assignedAuthor
 
# Der Autor (Person)
 
## Ein Personenelement enthält unter anderem die folgenden Unterelemente:
 
### id … ID der Person mit den folgenden Attributen:
 
#### @root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
 
#### @extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
 
### assignedPerson
 
#### Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
 
##### name
 
# Gerät oder Software als Autor
 
## Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:
 
### assignedAuthoringDevice
 
#### Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software
 
##### manufacturerModelName
 
#### Enthält ein Element mit dem Namen des Geräts oder der Software
 
##### softwareName
 
  
=====Spezifikation für Personen=====
+
*application/dicom<br />
 
 
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
 
 
 
<span > $person</span> = ClinicalDocument/author/assignedAuthor
 
 
 
concat(<br/>
 
<span > $person</span>/id/@extension,"^",<br/>
 
<span > $person</span>/assignedPerson/name/family,"^",<br/>
 
<span > $person</span>/assignedPerson/name/given[1],"^",<br/>
 
<span > $person</span>/assignedPerson/name/given[2],"^",<br/>
 
<span > $person</span>/assignedPerson/name/suffix,"^",<br/>
 
<span > $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;amp;",<br/>
 
<span > $person</span>/id/@root,"&amp;amp;ISO"<br/>
 
)<br/>
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
+
<ExtrinsicObject
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
+
            id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
+
            mimeType="application/dicom"
    <Slot name="authorPerson">
+
            objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
        <ValueList>
+
            status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>
            <Value>2323^Hummel^Frank^^^^^^&amp;amp;1.2.40.0.34.99.4613.3.3&amp;amp;ISO
+
</pre>
            </Value>
+
 
        </ValueList>
+
===practiceSettingCode (und practiceSettingCodeDisplayName)===
    </Slot>   
+
Das ''practiceSettingCode'' Element beschreibt die fachliche Zuordnung des Objektes. Es soll den Fachbereich wiedergeben, dem der Inhalt des Objektes am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung, z.B.:
</Classification></pre>
+
 
 +
*F044 "Radiologie"
 +
*F052 "Unfallchirurgie"
 +
 
 +
Im KOS-Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.
+
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_PracticeSetting_VS ELGA_PracticeSetting_VS]".
 
{{EndYellowBox}}
 
{{EndYellowBox}}
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
 
  
=====Spezifikation für Software und Geräte=====
+
====Spezifikation====
 
 
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
 
  
<span > $person</span> = ClinicalDocument/author/assignedAuthor
+
'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
  
concat(<br/>
+
<span>$code</span> = Code aus Value Set ELGA_PracticeSetting<br /><span>$displayName</span> = Klartext des angegebenen Codes (displayName)<br /><span>$codeSystem</span> = OID des Codesystems (1.2.40.0.34.5.12)<br />
"^",<br/>
 
<span > $person</span>/assignedAuthoringDevice/manufacturerModelName,"^",<br/>
 
<span > $person</span>/assignedAuthoringDevice/softwareName<br/>
 
)<br/>
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
+
<Classification
 +
    classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
 
     classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
 
     classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
     id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
+
     id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
     <Slot name="authorPerson">
+
    nodeRepresentation="$code">
 +
    <Name>
 +
        <LocalizedString value="$displayName"/>
 +
    </Name>
 +
     <Slot name="codingScheme">
 
         <ValueList>
 
         <ValueList>
             <Value>^Good Health System^Best Health Software Application</Value>
+
             <Value>urn:oid:$codeSystem</Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>
 
     </Slot>
</Classification></pre>
+
</Classification>
 +
</pre>
 +
 
 +
===objectType===
 +
Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "stabiles Dokument" (stable document, SD) und "On-demand Dokument" (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.
 +
 
 +
Für KOS Objekte wird der fixe Wert "<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" für "Stable Document" vorgegeben:
 +
<pre class="ilfbox_code">
 +
<ExtrinsicObject mimeType="application/dicom"
 +
    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"/>
 +
</pre>
  
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
+
==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.  
  
====authorRole====
+
===elgaFlag===
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.
+
Das elgaFlag dient zur Kennzeichnung eines Objektes als "ELGA-Objekt"<sup>18</sup>. 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:
  
Beispiel:
+
*"true"    oder
* „Diensthabender Oberarzt“
+
*"false"
* „Verantwortlicher diensthabender Arzt für die Dokumenterstellung“
 
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
 
# Laut Festlegung wird die „Rolle“ der Person, welche das Dokument inhaltlich erstellt hat im Element functionCode des Autors abgelegt:
 
## ''ClinicalDocument/author/functionCode''
 
# Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R2]'''''.
 
# Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.
 
  
=====Spezifikation=====
+
<sup>18</sup> Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Objekte auftreten, die NICHT für ELGA vorgesehen sind.
  
'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
====Spezifikation====
  
ClinicalDocument/author/functionCode/@displayName<br/>
+
<pre class="ilfbox_code">
<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
+
<Slot name="urn:elga-bes:elgaFlag">
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
+
     <ValueList>
    id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
+
         <Value>true</Value>
     <Slot name="authorRole">
+
    </ValueList>
         <ValueList>
+
</Slot>
            <Value>Diensthabender Oberarzt</Value>
 
        </ValueList>
 
    </Slot>   
 
</Classification>
 
 
</pre>
 
</pre>
{{BeginYellowBox}}
 
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer
 
{{EndYellowBox}}
 
  
====authorSpeciality====
+
===elgaHash===
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.
+
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.
  
Beispiel:
+
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.
* „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:
 
# Laut Festlegung wird die „Fachrichtung“ der Person, welche das Dokument inhaltlich erstellt hat im Element code des Autors abgelegt:
 
## ''ClinicalDocument/author/assignedAuthor/code''
 
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R2]'''''.
 
# Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.
 
  
======Spezifikation======
+
====Spezifikation====
 +
<pre class="ilfbox_code">
 +
  <rim:Slot name="urn:elga-bes:elgaHash">
 +
    <rim:ValueList>
 +
      <rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>
 +
    </rim:ValueList>
 +
  </rim:Slot>
 +
</pre>
  
'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
=XDS Metadaten für CDA Dokumente=
 +
Die folgenden Kapitel spezifizieren die XDS-Metadaten von HL7 CDA-Dokumenten für deren Verwendung in ELGA. Nicht angegebene Metadaten sind nicht weiter eingeschränkt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol. 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.<ref name="ITITF3"/>
  
ClinicalDocument/author/assignedAuthor/code/@displayName<br/>
+
==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==
 +
 
 +
===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.
 +
 
 +
====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:
 +
 
 +
#Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört, grundsätzlich in folgendem Element abgelegt:
 +
##ClinicalDocument/author/assignedAuthor/representedOrganization
 +
#Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:
 +
##'''id'''[1] … ID der Organisation mit den folgenden Attributen:
 +
###@root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)
 +
###@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)
 +
##'''name''' … Name der Organisation als String<br /> Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird.<br /> Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" →  "Wien AKH" bzw "Wien AKH - Augenambulanz"<br />Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.
 +
#GDA, in deren Gültigkeitsbereich Dokumente erstellt werden können, sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
 +
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
 +
{{BeginYellowBox}}
 +
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da es vom ELGA Berechtigungssystem bei Registrierung geprüft wird.<br>
 +
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden.
 +
{{EndYellowBox}}
 +
 
 +
=====Spezifikation=====
 +
 
 +
'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
 +
 
 +
<span>$inst</span> … ClinicalDocument/author/assignedAuthor/representedOrganization
 +
 
 +
 
 +
*Fall 1:<br />
 +
 
 +
Element $inst/id[1] ist vorhanden<br />
 +
Attribut $inst/id[1]/@root ist vorhanden<br />
 +
Attribut $inst/id[1]/@extension ist nicht vorhanden<br />
 +
 
 +
concat(<br />
 +
<span>$inst</span>/name,"^^^^^^^^^",<br />
 +
<span>$inst</span>/id[1]/@root,"&amp;amp;ISO"<br />
 +
)<br />
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
 
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
 
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
 
     classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
 
     classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
 
     id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
 
     id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
     <Slot name="authorSpeciality">
+
     <Slot name="authorInstitution">
 
         <ValueList>
 
         <ValueList>
             <Value>Anästhesiologie und Intensivmedizin</Value>
+
             <Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;amp;ISO</Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>     
 
     </Slot>     
 
</Classification>
 
</Classification>
 
</pre>
 
</pre>
{{BeginYellowBox}}
 
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer
 
{{EndYellowBox}}
 
  
===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:
+
*Fall 2:<br />
{| class="wikitable"
+
 
|- style="background:white"
+
Element $inst/id[1] ist vorhanden<br />
|'''''classCode'''''
+
Attribut $inst/id[1]/@root ist vorhanden<br />
|'''''Dokumentenklasse in grober Granularität'''''
+
Attribut $inst/id[1]/@extension ist vorhanden<br />
|- style="background:white"
 
|''typeCode''
 
|Dokumentenklasse  in feiner Granularität.<br /> Siehe  Kapitel [[ILF:XDS Metadaten 2020#typeCode_.28und_typeCodeDisplayName.29|4.2.15]]
 
|}
 
  
<br />
+
concat(<br />
 +
<span>$inst</span>/name,"^^^^^&",<br />
 +
<span>$inst</span>/id[1]/@root,"&ISO^^^^"<br />
 +
<span>$inst</span>/id[1]/@extension<br />
 +
)<br />
 +
<pre class="ilfbox_code">
 +
<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&amp;amp;ISO^^^^45</Value>
 +
        </ValueList>
 +
    </Slot>   
 +
</Classification>
 +
</pre>
 +
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.
  
====Spezifikation====
+
====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).
  
'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br />
+
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit CDA Header Elementen:
  
TODO: <span>translation/@displayName</span> ist im CDA optional, in XDS jedoch 1..1 M
+
#Laut Festlegung wird der Autor im Header-Element "author" abgelegt:
 +
##ClinicalDocument/author/assignedAuthor
 +
#Der Autor (Person)
 +
##Ein Personenelement enthält unter anderem die folgenden Unterelemente:
 +
###id … ID der Person mit den folgenden Attributen:
 +
####@root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
 +
####@extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
 +
###assignedPerson
 +
####Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
 +
#####name
 +
#Gerät oder Software als Autor
 +
##Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:
 +
###assignedAuthoringDevice
 +
####Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software
 +
#####manufacturerModelName
 +
####Enthält ein Element mit dem Namen des Geräts oder der Software
 +
#####softwareName
  
$code = ClinicalDocument/code/translation/@code<br />
+
=====Spezifikation für Personen=====
$displayName = ClinicalDocument/code/translation/@displayName<br />
+
 
$codeSystem = ClinicalDocument/code/translation/@codeSystem<br />
+
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
<pre class="ilfbox_code">
+
 
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
+
<span> $person</span> = ClinicalDocument/author/assignedAuthor
     classifiedObject="theDocument" nodeRepresentation="$code">
+
 
    <Name>
+
concat(<br />
        <LocalizedString value="$displayName"/>
+
<span> $person</span>/id/@extension,"^",<br />
    </Name>
+
<span> $person</span>/assignedPerson/name/family,"^",<br />
     <Slot name="codingScheme">
+
<span> $person</span>/assignedPerson/name/given[1],"^",<br />
 +
<span> $person</span>/assignedPerson/name/given[2],"^",<br />
 +
<span> $person</span>/assignedPerson/name/suffix,"^",<br />
 +
<span> $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;amp;",<br />
 +
<span> $person</span>/id/@root,"&amp;amp;ISO"<br />
 +
)<br />
 +
<pre class="ilfbox_code">
 +
<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>
 
         <ValueList>
             <Value>urn:oid:$codeSystem</Value>
+
             <Value>2323^Hummel^Frank^^^^^^&amp;amp;1.2.40.0.34.99.4613.3.3&amp;amp;ISO
 +
            </Value>
 
         </ValueList>
 
         </ValueList>
     </Slot>
+
     </Slot>  
</Classification>
+
</Classification></pre>
</pre>
+
{{BeginYellowBox}}
 +
Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.
 +
{{EndYellowBox}}
 +
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.
  
 +
=====Spezifikation für Software und Geräte=====
  
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).
+
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
===confidentialityCode===
+
<span> $person</span> = ClinicalDocument/author/assignedAuthor
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:
 
 
 
====Spezifikation====
 
 
 
confidentialityCode wird als ebRIM Slot gemäß folgendem Beispiel abgebildet:<br/>
 
  
 +
concat(<br />
 +
"^",<br />
 +
<span> $person</span>/assignedAuthoringDevice/manufacturerModelName,"^",<br />
 +
<span> $person</span>/assignedAuthoringDevice/softwareName<br />
 +
)<br />
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
+
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
     classifiedObject="theDocument" nodeRepresentation="N">
+
     classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    <Name>
+
    id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
        <LocalizedString value="normal"/>
+
     <Slot name="authorPerson">
    </Name>
 
     <Slot name="codingScheme">
 
 
         <ValueList>
 
         <ValueList>
             <Value>urn:oid:2.16.840.1.113883.5.25</Value>
+
             <Value>^Good Health System^Best Health Software Application</Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>
 
     </Slot>
 
</Classification></pre>
 
</Classification></pre>
  
===creationTime===
+
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.
Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.
+
 
 +
====authorRole====
 +
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.
  
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
+
Beispiel:
# Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:
 
## ClinicalDocument/effectiveTime
 
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
 
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.
 
# Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:
 
# @value … enthält das Datum in folgenden möglichen Formen
 
## YYYYMMDD
 
## YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
 
### Bsp: 20081224082015+0100
 
### Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
 
{{BeginYellowBox}}
 
CreationTime entfällt bei On-Demand Documents.
 
{{EndYellowBox}}
 
  
====Spezifikation====
+
*"Diensthabender Oberarzt"
 +
*"Verantwortlicher diensthabender Arzt für die Dokumenterstellung"
  
'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>
+
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
ClinicalDocument/effectiveTime/@value = "20200511193000+0200"
+
 
<pre class="ilfbox_code">
+
#Laut Festlegung wird die "Rolle" der Person, welche das Dokument inhaltlich erstellt hat, im Element functionCode des Autors abgelegt:
<ExtrinsicObject mimeType="text/xml"
+
##''ClinicalDocument/author/functionCode''
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
+
#Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
+
#Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
+
 
     <Slot name="creationTime">
+
=====Spezifikation=====
 +
 
 +
'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
 +
 
 +
ClinicalDocument/author/functionCode/@displayName<br />
 +
<pre class="ilfbox_code"><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>
 
         <ValueList>
             <Value>20200511173000</Value>
+
             <Value>Diensthabender Oberarzt</Value>
 
         </ValueList>
 
         </ValueList>
     </Slot>
+
     </Slot>  
</ExtrinsicObject>
+
</Classification>
 
</pre>
 
</pre>
 
Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß [IHE ITI-TF3].
 
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
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.
+
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
 
 
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).
 
 
{{EndYellowBox}}
 
{{EndYellowBox}}
  
===eventCodeList (und eventCodeListDisplayName)===
+
====authorSpeciality====
Im Fall eines Entlassungsbriefs beschreibt dieses Element die Liste der vollbrachten Gesundheitsdienstleistungen für den im Dokument dokumentierten Patientenkontakt.  
+
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.
  
Im allgemeinen Fall eines beliebigen CDA R2 Dokuments gilt grundsätzlich folgende Verknüpfung mit den CDA Header Elementen:
+
Beispiel:
# Im CDA wird die Liste der Service-Events wie folgt abgelegt:
+
 
## ClinicalDocument/documentationOf/serviceEvent
+
*"Facharzt für Gynäkologie"
# Mehrere dieser Service-Events können durch beliebig viele „documentationOf“ Elemente ausgedrückt werden.
+
*"Facharzt für interne Medizin"
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines Service-Events verpflichtend, wenn bekannt [R2].
+
 
# Ein serviceEvent Element in CDA beinhaltet unter anderem die folgenden Elemente:
+
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
## 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.
 
  
====Spezifikation====
+
#Laut Festlegung wird die "Fachrichtung" der Person, welche das Dokument inhaltlich erstellt hat, im Element code des Autors abgelegt:
 +
##''ClinicalDocument/author/assignedAuthor/code''
 +
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
 +
#Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.
  
'''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>
+
=====Spezifikation=====
  
Für jedes documentationOf Element 1..n:<br/>
+
'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
<span >$code </span>= ClinicalDocument/documentationOf[n]/serviceEvent/code/@code<br/>
+
ClinicalDocument/author/assignedAuthor/code/@displayName<br />
<span >$displayName</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName<br/>
 
<span >$codeSystem</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem<br/>
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<Classification
+
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
    classificationScheme=
+
     classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
+
     id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
     classifiedObject="theDocument"
+
     <Slot name="authorSpeciality">
     nodeRepresentation="$code">
 
     <Slot name="codingScheme">
 
 
         <ValueList>
 
         <ValueList>
             <Value>urn:oid:$codeSystem</Value>
+
             <Value>Anästhesiologie und Intensivmedizin</Value>
 
         </ValueList>
 
         </ValueList>
     </Slot>
+
     </Slot>  
    <Name>
 
        <LocalizedString value="$displayName"/>
 
    </Name>
 
 
</Classification>
 
</Classification>
 
</pre>
 
</pre>
 +
{{BeginYellowBox}}
 +
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
 +
{{EndYellowBox}}
  
====Spezielle Vorschriften laut IHE PCC====
+
===classCode (und classCodeDisplayName)===
Das PCC Profil definiert in Kapitel „Medical Document Bindings“ Spezialbehandlungen für gewissen Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC).
+
Das ''classCode'' Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.
  
Diese speziellen Vorschriften werden in ELGA '''nicht''' angewandt.
+
Unterscheidung classCode/typeCode:
 +
{| class="wikitable"
 +
|- style="background:white"
 +
|'''''classCode'''''
 +
|'''''Dokumentenklasse in grober Granularität'''''
 +
|- style="background:white"
 +
|''typeCode''
 +
|Dokumentenklasse  in feiner Granularität.<br />  Siehe  Kapitel [[ILF:XDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2|typeCode]]
 +
|}
  
===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:
 
 
====Spezifikation====
 
====Spezifikation====
  
'''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br />
  
ClinicalDocument/languageCode/@code = "de-AT"
+
$code = ClinicalDocument/code/translation/@code<br />
 +
$displayName = ClinicalDocument/code/translation/@displayName<br />
 +
$codeSystem = ClinicalDocument/code/translation/@codeSystem<br />
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
+
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
+
     classifiedObject="theDocument" nodeRepresentation="$code">
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
+
     <Name>
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
+
        <LocalizedString value="$displayName"/>
     <Slot name="languageCode">
+
    </Name>
 +
     <Slot name="codingScheme">
 
         <ValueList>
 
         <ValueList>
             <Value>de-AT</Value>
+
             <Value>urn:oid:$codeSystem</Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>
 
     </Slot>
</ExtrinsicObject>
+
</Classification>
 
</pre>
 
</pre>
  
===legalAuthenticator===
+
===confidentialityCode===
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“).  
+
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des Dokuments.
  
Für CDA R2 Dokumente gilt folgende Verknüpfung mit den CDA Header Elementen:
+
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.
# Laut Festlegung wird die Person, welche das Dokument vidiert hat, im Element „legalAuthenticator“ abgelegt:
+
## ClinicalDocument/legalAuthenticator/assignedEntity
+
Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich und wird fix auf "N" (normal) gesetzt.
{{BeginYellowBox}}
+
 
'''ACHTUNG:''' Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste Element (ClinicalDocument/LegalAuthenticator[1]) übernommen werden.
+
Es wird der Vertraulichkeitscode aus dem CDA Header Element gemäß folgender Spezifikation übernommen:
{{EndYellowBox}}
 
# Die vidierende Person
 
## Ein Personenelement in CDA beinhaltet unter anderem die folgenden Unterelemente:
 
### id … ID der Person mit den folgenden Attributen:
 
#### @root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
 
#### @extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
 
### assignedEntity
 
#### Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
 
##### Name
 
  
 
====Spezifikation====
 
====Spezifikation====
  
'''legalAuthenticator''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>
+
confidentialityCode wird als ebRIM Slot gemäß folgendem Beispiel abgebildet:<br />
 
 
<span > $person </span>= ClinicalDocument/legalAuthenticator/assignedEntity
 
 
 
  
concat(<br/>
 
<span > $person</span>/id/@extension,"^",<br/>
 
<span > $person</span>/assignedPerson/name/family,"^",<br/>
 
<span > $person</span>/assignedPerson/name/given[1],"^",<br/>
 
<span > $person</span>/assignedPerson/name/given[2],"^",<br/>
 
<span > $person</span>/assignedPerson/name/suffix,"^",<br/>
 
<span > $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;amp;",<br/>
 
<span > $person</span>/id/@root,"&amp;amp;ISO"<br/>
 
)<br/>
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
+
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
+
     classifiedObject="theDocument" nodeRepresentation="N">
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
+
     <Name>
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
+
        <LocalizedString value="normal"/>
     <Slot name="legalAuthenticator">
+
    </Name>
 +
     <Slot name="codingScheme">
 
         <ValueList>
 
         <ValueList>
             <Value>1234^Musterdoktor^Herbert^^^Dr.^^^&amp;amp;1.2.3.4.5.6.7.8.9&amp;amp;ISO</Value>
+
             <Value>urn:oid:2.16.840.1.113883.5.25</Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>
 
     </Slot>
</ExtrinsicObject>
+
</Classification></pre>
</pre>
 
Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
 
  
===serviceStartTime / serviceStopTime===
+
===creationTime===
Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts/Behandlung.  
+
Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden. Dieses Datum kann für die chronologische Sortierung der Befunde bei der Anzeige der Dokumentenliste verwendet werden.  
  
Laut ELGA Implementierungsleitfäden ist in ELGA CDA Dokumenten die Angabe von mindestens einer Gesundheitsdienstleistung (“documentationOf/serviceEvent“) verpflichtend, wenn bekannt '''''[R2]'''''.
+
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
  
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 CDA wird dieser Zeitpunkt wie folgt abgelegt:<br />ClinicalDocument/effectiveTime
 +
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe verpflichtend.
 +
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert.
 +
#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:<br />@value … enthält das Datum in folgenden möglichen Formen
 +
##YYYYMMDD
 +
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)<br />Bsp: 20081224082015+0100<br />Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
 +
# 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:
+
{{BeginYellowBox}}
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens einem Service-Event verpflichtend:
+
CreationTime entfällt bei On-Demand Documenten.
## ClinicalDocument/documentationOf/serviceEvent
+
{{EndYellowBox}}
# Das Element serviceEvent beinhaltet unter anderem die folgenden Unterelemente:
 
## effectiveTime gibt das Zeitintervall an, in dem die Gesundheitsdienstleistung durchgeführt wurde
 
## Laut Vorgabe der ELGA Gesundheitsdaten SOLL ein Zeitintervall (HL7 IVL_TS) in wie folgt angeordnet werden:
 
### low … enthält das Startdatum
 
### high … enthält das Endedatum
 
### 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.
+
Das Aktualisierungsdatum von Dokumenten (Update-Datum) kann über submissionTime (in XDS.submissionSet) erkannt werden.
  
 
====Spezifikation====
 
====Spezifikation====
  
'''serviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />
ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value = "20200511193000+0200"
+
ClinicalDocument/effectiveTime/@value = "20200511193000+0200"
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
 
<ExtrinsicObject mimeType="text/xml"
 
<ExtrinsicObject mimeType="text/xml"
Zeile 2.224: Zeile 2.265:
 
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
 
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
 
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
 
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
     <Slot name="serviceStartTime">
+
     <Slot name="creationTime">
 
         <ValueList>
 
         <ValueList>
 
             <Value>20200511173000</Value>
 
             <Value>20200511173000</Value>
Zeile 2.231: Zeile 2.272:
 
</ExtrinsicObject>
 
</ExtrinsicObject>
 
</pre>
 
</pre>
 +
 +
Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
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.
+
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).  
+
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).
 
{{EndYellowBox}}
 
{{EndYellowBox}}
  
 +
===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:
 +
 +
#Im CDA wird die Liste der ServiceEvents wie folgt abgelegt:
 +
##ClinicalDocument/documentationOf/serviceEvent
 +
#Mehrere dieser ServiceEvents können durch beliebig viele "documentationOf" Elemente ausgedrückt werden.
 +
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines ServiceEvents verpflichtend, wenn bekannt [R].
 +
#Ein ServiceEvent Element in CDA beinhaltet unter anderem die folgenden Elemente:
 +
##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 ServiceEvent eine Gesundheitsdienstleistung angegeben werden muss und welche Bedeutung dieses Element hat.
 +
 +
====Spezifikation====
  
 +
'''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />
  
 +
Für jedes documentationOf Element 1..n:<br />
  
'''serviceStopTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
<span>$code </span>= ClinicalDocument/documentationOf[n]/serviceEvent/code/@code<br />
ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value = "20200516133000+0200"
+
<span>$displayName</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName<br />
 +
<span>$codeSystem</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem<br />
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
+
<Classification
     objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
+
    classificationScheme=
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
+
     "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
+
     classifiedObject="theDocument"
     <Slot name="serviceStopTime">
+
     nodeRepresentation="$code">
 +
     <Slot name="codingScheme">
 
         <ValueList>
 
         <ValueList>
             <Value>20200516113000</Value>
+
             <Value>urn:oid:$codeSystem</Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>
 
     </Slot>
</ExtrinsicObject>
+
    <Name>
 +
        <LocalizedString value="$displayName"/>
 +
    </Name>
 +
</Classification>
 
</pre>
 
</pre>
{{BeginYellowBox}}
 
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. 20200516133000+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 20200516113000).
+
====Spezielle Vorschriften laut IHE PCC====
{{EndYellowBox}}
+
Das IHE Patient Care Coordination (PCC) Technical Framework vol. 2<ref name="IHEPCC"/> definiert in Kapitel "Medical Document Binding" Spezialbehandlungen für gewisse Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC).
  
===sourcePatientId===
+
Diese speziellen Vorschriften werden in ELGA '''nicht''' angewandt.
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:
 
# Im CDA wird die ID des Patienten in folgendem Element abgelegt:
 
## ClinicalDocument/recordTarget/patientRole/id
 
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens den folgenden zwei IDs des Patienten im CDA verpflichtend bzw. verpflichtend, wenn bekannt:
 
## id[1] … Lokale ID des Patienten vom einbringenden System
 
## d[2] … Österreichische Sozialversicherungsnummer (nur wenn bekannt)<br/><span style="color:red;">Achtung: Diese ID gelangt nicht in die Metadaten!</span>
 
  
 +
===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:
 
====Spezifikation====
 
====Spezifikation====
  
'''sourcePatientId''' wird gemäß folgender Vorschrift zusammengesetzt:
+
'''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
concat(
+
ClinicalDocument/languageCode/@code = "de-AT"
 
+
<pre class="ilfbox_code">
ClinicalDocument/recordTarget/patientRole/id[1]/@extension,
+
<ExtrinsicObject mimeType="text/xml"
 
+
     objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
"^^^&amp;amp;",
+
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
 
 
ClinicalDocument/recordTarget/patientRole/id[1]/@root,
 
 
 
"&amp;amp;ISO"
 
 
 
)
 
<pre class="ilfbox_code">
 
<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">
 
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
     <Slot name="sourcePatientId">
+
     <Slot name="languageCode">
 
         <ValueList>
 
         <ValueList>
<Value>4711^^^&amp;amp;1.2.3.4.5.6.7.8.9&amp;amp;ISO</Value>
+
            <Value>de-AT</Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>
 
     </Slot>
 
</ExtrinsicObject>
 
</ExtrinsicObject>
 
</pre>
 
</pre>
Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß [IHE ITI-TF3].
 
  
===sourcePatientInfo===
+
===legalAuthenticator===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.
+
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:
  
 +
#Laut Festlegung wird die Person, welche das Dokument vidiert hat, im Element "legalAuthenticator" abgelegt:
 +
##ClinicalDocument/legalAuthenticator/assignedEntity
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
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. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
+
'''ACHTUNG:''' Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste Element (ClinicalDocument/LegalAuthenticator[1]) übernommen werden.
 
{{EndYellowBox}}
 
{{EndYellowBox}}
  
===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:
+
Ein Personenelement in CDA beinhaltet unter anderem die folgenden Unterelemente
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumententitels verpflichtend:
+
 
## ClinicalDocument/title
+
#id … ID der Person mit den folgenden Attributen:
 +
##@root … Root OID des ID Pools, oder direkt die OID der Person (ohne @extension-Attribut)
 +
##@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
 +
#assignedEntity
 +
##Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
 +
###Name
 +
 
 
====Spezifikation====
 
====Spezifikation====
  
'''title''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:
+
'''legalAuthenticator''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />
 +
 
 +
<span> $person </span>= ClinicalDocument/legalAuthenticator/assignedEntity
 +
 
  
ClinicalDocument/title
+
concat(<br />
<pre class="ilfbox_code">
+
<span> $person</span>/id/@extension,"^",<br />
 +
<span> $person</span>/assignedPerson/name/family,"^",<br />
 +
<span> $person</span>/assignedPerson/name/given[1],"^",<br />
 +
<span> $person</span>/assignedPerson/name/given[2],"^",<br />
 +
<span> $person</span>/assignedPerson/name/suffix,"^",<br />
 +
<span> $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;amp;",<br />
 +
<span> $person</span>/id/@root,"&amp;amp;ISO"<br />
 +
)<br />
 +
<pre class="ilfbox_code">
 
<ExtrinsicObject mimeType="text/xml"
 
<ExtrinsicObject mimeType="text/xml"
 
     objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
 
     objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
 
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
 
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
 
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
 
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
     <Name>
+
     <Slot name="legalAuthenticator">
         <LocalizedString charset="UTF-8" value="Entlassungsbrief der chirurgischen Abteilung" xml:lang="de-AT" />
+
         <ValueList>
     </Name>
+
            <Value>1234^Musterdoktor^Herbert^^^Dr.^^^&amp;amp;1.2.3.4.5.6.7.8.9&amp;amp;ISO</Value>
 +
        </ValueList>
 +
     </Slot>
 
</ExtrinsicObject>
 
</ExtrinsicObject>
 
</pre>
 
</pre>
{{BeginYellowBox}}
+
Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
+
 
{{EndYellowBox}}
+
===serviceStartTime / serviceStopTime===
 +
Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts/Behandlung.  
  
===typeCode (und typeCodeDisplayName)===
+
Laut ELGA Implementierungsleitfäden ist in ELGA CDA Dokumenten die Angabe von mindestens einer Gesundheitsdienstleistung ("documentationOf/serviceEvent") verpflichtend, wenn bekannt '''''[R]'''''.  
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:
+
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.
{| class="wikitable"
 
|- style="background:white"
 
| '''typeCode'''
 
| '''Dokumentenklasse in feiner Granularität (Spezialisierung).'''
 
|- style="background:white"
 
| classCode
 
| Dokumentenklasse  in grober Granularität.<br/>  Siehe Kapitel [[ILF:XDS Metadaten 2020#classCode_.28und_classCodeDisplayName.29|classCode]]
 
|}
 
  
 
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
 
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:
+
 
## ClinicalDocument/code
+
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens einem ServiceEvent verpflichtend:
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentencodes ein verpflichtendes Element.
+
##ClinicalDocument/documentationOf/serviceEvent
# Ein Code-Element in CDA beinhaltet unter anderem die folgenden Attribute:
+
#Das Element ServiceEvent beinhaltet unter anderem die folgenden Unterelemente:
## @code … Codierter Wert der Dokumentenklasse
+
##effectiveTime gibt das Zeitintervall an, in dem die Gesundheitsdienstleistung durchgeführt wurde
### Bsp: Code „11490-0“
+
##Laut Vorgabe der ELGA Gesundheitsdaten SOLL ein Zeitintervall (HL7 IVL_TS) in wie folgt angeordnet werden:
## @displayName Lesbarer Wert der Dokumentenklasse
+
###low enthält das Startdatum
### Bsp:  „Discharge summarization note (physician)”
+
###high enthält das Endedatum
## @codeSystem Codierter Wert des zugrundliegenden Codesystems
+
###Andere im CDA möglichen Angaben (low/width, width/high, ...) sind nicht gestattet
### Bsp: „2.16.840.1.113883.6.1“
+
{{BeginYellowBox}}
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe dieser 3 Attribute des Elements code verpflichtend.
+
Es soll jeweils das erste '''serviceEvent''' für das Mapping verwendet werden.
 +
{{EndYellowBox}}
  
 
====Spezifikation====
 
====Spezifikation====
  
'''typeCode (und typeCodeDisplayName)''' wird  wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:
+
'''serviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
 
+
ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value = "20200511193000+0200"
<span > $code</span> = ClinicalDocument/code/@code<br/>
 
<span > $displayName</span> = ClinicalDocument/code/@displayName<br/>
 
<span > $codeSystem</span> = ClinicalDocument/code/@codeSystem<br/>
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<Classification
+
<ExtrinsicObject mimeType="text/xml"
     classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
+
     objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
     classifiedObject="theDocument"
+
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
     nodeRepresentation="$code">
+
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
    <Name>
+
     <Slot name="serviceStartTime">
        <LocalizedString value="$displayName"/>
 
    </Name>
 
     <Slot name="codingScheme">
 
 
         <ValueList>
 
         <ValueList>
             <Value>urn:oid:$codeSystem</Value>
+
             <Value>20200511173000</Value>
 
         </ValueList>
 
         </ValueList>
 
     </Slot>
 
     </Slot>
</Classification>
+
</ExtrinsicObject>
 
</pre>
 
</pre>
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
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).
+
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. 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).  
 
{{EndYellowBox}}
 
{{EndYellowBox}}
  
====submissionSet.contentTypeCode====
+
'''serviceStopTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
Der contentTypeCode  des SubmissionSets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.
+
ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value = "20200516133000+0200"
 
 
$code = ClinicalDocument/code/@code
 
 
 
$displayName = ClinicalDocument/code/@displayName
 
 
 
$codeSystem = ClinicalDocument/code/@codeSystem
 
 
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<RegistryPackage
+
<ExtrinsicObject mimeType="text/xml"
 +
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
 
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
 
     status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
     <Classification
+
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
        classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
+
    <Slot name="serviceStopTime">
        classifiedObject="theDocument"
+
        <ValueList>
        nodeRepresentation="$code">
+
            <Value>20200516113000</Value>
        <Name>
+
        </ValueList>
            <LocalizedString value="$displayName"/>
+
    </Slot>
        </Name>
+
</ExtrinsicObject>
        <Slot name="codingScheme">
 
            <ValueList>
 
                <Value>urn:oid:$codeSystem</Value>
 
            </ValueList>
 
        </Slot>
 
    </Classification>
 
</RegistryPackage>
 
 
</pre>
 
</pre>
 +
{{BeginYellowBox}}
 +
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. 20200516133000+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 20200516113000).
 +
{{EndYellowBox}}
  
===uniqueId===
+
===sourcePatientId===
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.
+
Das ''sourcePatientId'' Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA.
uniqueId wird als ebRIM
 
  
 
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
 
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer ID für das Dokument verpflichtend:
+
 
## ClinicalDocument/id
+
#Im CDA wird die ID des Patienten in folgendem Element abgelegt:
 +
##ClinicalDocument/recordTarget/patientRole/id
 +
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens den folgenden zwei IDs des Patienten im CDA verpflichtend bzw. verpflichtend, wenn bekannt:
 +
##id[1] … ID des Patienten vom einbringenden (lokalen) System
 +
##id[2] … Österreichische Sozialversicherungsnummer (nur wenn bekannt)<br /><span style="color:red;">Achtung: Diese ID gelangt nicht in die Metadaten!</span>
  
 
====Spezifikation====
 
====Spezifikation====
  
uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:<br/>
+
'''sourcePatientId''' wird gemäß folgender Vorschrift zusammengesetzt:
  
Fall 1<br/>
+
concat(
Attribut ClinicalDocument/id/@extension ist nicht vorhanden
 
  
$value = concat(ClinicalDocument/id/@root)
+
ClinicalDocument/recordTarget/patientRole/id[1]/@extension,
 +
 
 +
"^^^&amp;amp;",
 +
 
 +
ClinicalDocument/recordTarget/patientRole/id[1]/@root,
  
Fall 2<br/>
+
"&amp;amp;ISO"
Attribut ClinicalDocument/id/@extension ist vorhanden
 
  
$value = concat(
 
ClinicalDocument/id/@root, "^",
 
ClinicalDocument/id/@extension
 
 
)
 
)
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<ExternalIdentifier
+
<ExtrinsicObject mimeType="text/xml"
registryObject="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"
+
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
+
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
value="$value">
+
    id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
    <Name>
+
    <Slot name="sourcePatientId">
         <LocalizedString value="XDSDocumentEntry.uniqueId"/>
+
        <ValueList>
     </Name>
+
<Value>4711^^^&amp;amp;1.2.3.4.5.6.7.8.9&amp;amp;ISO</Value>
</ExternalIdentifier></pre>
+
         </ValueList>
 
+
     </Slot>
===referenceIdList===
+
</ExtrinsicObject>
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.
+
</pre>
 +
Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.
 +
{{BeginYellowBox}}
 +
Ein spezieller Leitfaden kann eine abweichende Mapping-Vorschrift definieren!
 +
{{EndYellowBox}}
  
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.  
+
===sourcePatientInfo===
 +
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.
 
{{BeginYellowBox}}
 
{{BeginYellowBox}}
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.
+
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. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
 
{{EndYellowBox}}
 
{{EndYellowBox}}
  
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).''
+
===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:
  
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
+
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumententitels verpflichtend:
# Laut Vorgabe der ELGA Dokumenten Leitfäden ist die Angabe einer setId für das Dokument verpflichtend:  
+
##ClinicalDocument/title
## ClinicalDocument/setId
 
  
 
====Spezifikation====
 
====Spezifikation====
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
 
  
Dieser Datentyp ist in IHE ITI Data Types in folgender Weise spezifiziert:<ref name="IHE ITI TF-3"></ref>
+
'''title''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:
  
{| class="wikitable" width="100%"
+
ClinicalDocument/title
!Data Type||Source Standard||Encoding Specification
+
<pre class="ilfbox_code">
|-
+
<ExtrinsicObject mimeType="text/xml"
|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.<br />
+
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
Therefore, Universal Id Type is always ISO. The required format is: <br />IdNumber^^^&OIDofAA&ISO<br />No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above.<br />An explicit example is:<br />543797436^^^&1.2.840.113619.6.197&ISO<br />Note that the '&' character must be properly encoded in the XML content.
+
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
|-
+
    id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
|'''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.'''
+
    <Name>
*'''CXi.1 shall be present and hold the identifier value.'''
+
        <LocalizedString charset="UTF-8" value="Entlassungsbrief der chirurgischen Abteilung" xml:lang="de-AT" />
*'''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.'''
+
    </Name>
*'''CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.'''
+
</ExtrinsicObject>
*'''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.'''
+
</pre>
*'''No other components shall be present.'''
+
{{BeginYellowBox}}
|}
+
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
 
+
{{EndYellowBox}}
 
 
'''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.
 
  
 +
===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.
  
referenceIdList wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
+
Unterscheidung typeCode/classCode:
 +
{| class="wikitable"
 +
|- style="background:white"
 +
|'''typeCode'''
 +
|'''Dokumentenklasse in feiner Granularität (Spezialisierung).'''
 +
|- style="background:white"
 +
|classCode
 +
|Dokumentenklasse  in grober Granularität.<br />  Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29_2|classCode]]
 +
|}
  
concat
+
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
  
(
+
#Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:
 
+
##ClinicalDocument/code
ClinicalDocument/setId/@extension, "^^^",
+
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentencodes ein verpflichtendes Element.
 
+
#Ein Code-Element in CDA beinhaltet unter anderem die folgenden Attribute:
ClinicalDocument/setId/@root, "^",
+
##@code … Codierter Wert der Dokumentenklasse
 
+
###Bsp:  Code "11490-0"
"urn:elga:iti:xds:2014:ownDocument_setId", "^",
+
##@displayName … Lesbarer Wert der Dokumentenklasse
 
+
###Bsp:  "Discharge summarization note (physician)"
homeCommunityId
+
##@codeSystem … Codierter Wert des zugrundliegenden Codesystems
 
+
###Bsp: "2.16.840.1.113883.6.1"
)
+
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe dieser 3 Attribute des Elements code verpflichtend.
 
 
Bitte beachten Sie, dass sowohl die ClinicalDocument/setId/@root als auch die homeCommunityId in der Schreibweise „&“, OID-Wert, „&ISO“ anzugeben sind.
 
  
 +
====Spezifikation====
  
Beispiel 1: setId/@root und setId/@extension sind im CDA strukturiert. In /@extension wird KEINE UUID angegeben.
+
'''typeCode (und typeCodeDisplayName)''' wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:
  
 +
<span> $code</span> = ClinicalDocument/code/@code<br />
 +
<span> $displayName</span> = ClinicalDocument/code/@displayName<br />
 +
<span> $codeSystem</span> = ClinicalDocument/code/@codeSystem<br />
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<ClinicalDocument xmlns="urn:hl7-org:v3">
+
<Classification
+
    classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
<setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZZZZZ"/>
+
    classifiedObject="theDocument"
<versionNumber value="2"/>  
+
    nodeRepresentation="$code">
+
    <Name>
</ClinicalDocument>
+
        <LocalizedString value="$displayName"/>
 +
    </Name>
 +
    <Slot name="codingScheme">
 +
        <ValueList>
 +
            <Value>urn:oid:$codeSystem</Value>
 +
        </ValueList>
 +
    </Slot>
 +
</Classification>
 
</pre>
 
</pre>
  
Wie oben angeführt wird folgender CXi Wert erstellt:
+
====submissionSet.contentTypeCode====
<pre class="ilfbox_code">
+
Der contentTypeCode des Submission Sets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.
<ExtrinsicObject mimeType="text/xml"
+
 
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
+
$code = ClinicalDocument/code/@code
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
 
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
 
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
 
        <ValueList>        <Value>ZZZZZZZZZZZZZZZZZZZ^^^&amp;amp;amp;1.2.40.0.34.99.111.1.1
 
  <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>
 
^&amp;amp;amp;1.2.40.0.34.99.999&amp;amp;amp;ISO</Value>
 
        </ValueList>
 
    </Slot>
 
</ExtrinsicObject>
 
</pre>
 
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.
 
  
 +
$displayName = ClinicalDocument/code/@displayName
  
Beispiel 2: in setId/@extension im CDA wird eine UUID geführt
+
$codeSystem = ClinicalDocument/code/@codeSystem
  
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<ClinicalDocument xmlns="urn:hl7-org:v3">
+
<RegistryPackage
+
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
<setId root="2.25" extension="urn:uuid:19FEE6C3-6B35-4C5B-B1CC-2B5B4001AB2"/>
+
    <Classification
<versionNumber value="2"/>  
+
        classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
+
        classifiedObject="theDocument"
</ClinicalDocument>
+
        nodeRepresentation="$code">
 +
        <Name>
 +
            <LocalizedString value="$displayName"/>
 +
        </Name>
 +
        <Slot name="codingScheme">
 +
            <ValueList>
 +
                <Value>urn:oid:$codeSystem</Value>
 +
            </ValueList>
 +
        </Slot>
 +
    </Classification>
 +
</RegistryPackage>
 
</pre>
 
</pre>
  
Wie oben angeführt wird folgender CXi Wert erstellt:
+
===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:
 +
 
 +
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer ID für das Dokument verpflichtend:
 +
##ClinicalDocument/id
  
"<nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki>&amp;amp;2.25&amp;amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO"
+
====Spezifikation====
<pre class="ilfbox_code">
 
<ExtrinsicObject mimeType="text/xml"
 
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
 
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
 
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
 
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
 
        <ValueList>
 
            <Value><nowiki>&lt;nowiki&gt;urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^&lt;/nowiki&gt;</nowiki><nowiki>&</nowiki>amp;amp;2.25
 
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki>
 
&amp;amp;amp;1.2.40.0.34.99.999&amp;amp;amp;ISO</Value>
 
        </ValueList>
 
    </Slot>
 
</ExtrinsicObject>
 
</pre>
 
  
===intendedRecipient===
+
uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:<br />
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.
+
Fall 1<br />
 +
Attribut ClinicalDocument/id/@extension ist nicht vorhanden
  
==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
+
$value = concat(ClinicalDocument/id/@root)
===availabilityStatus===
 
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Dokuments.
 
  
Mögliche Werte laut IHE sind:
+
Fall 2<br />
* Approved
+
Attribut ClinicalDocument/id/@extension ist vorhanden
* Deprecated
 
  
Dieses Attribut wird im Zuge des Einbringens von neuen Dokumenten („Submission“) durch die empfangende XDS Registry immer auf “'''Approved'''” gesetzt.
+
$value = concat(
 
+
ClinicalDocument/id/@root, "^",
availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.
+
ClinicalDocument/id/@extension
 +
)
  
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
+
<ExternalIdentifier
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
+
registryObject="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
+
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
     id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
+
value="$value">
</pre>
+
     <Name>
 +
        <LocalizedString value="XDSDocumentEntry.uniqueId"/>
 +
    </Name>
 +
</ExternalIdentifier></pre>
  
===formatCode (und formatCodeDisplayName)===
+
===referenceIdList===
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.
+
Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE ITI TF-3<ref name="ITITF3"/> (27 September 2013) Dokument neu hinzugekommen. Für CDA-Befunde sind drei unterschiedliche Einträge in referenceIdList vorgesehen:
Im CDA-Schema wurde für die HL7-Austria Domäne ein genau entsprechendes Element geschaffen, "hl7at:formatCode".
 
  
====Bildungsregel für den formatCodeDisplayName ====
+
#eindeutige Identifikation aller Dokumente eines Dokumentenstammes, d.h. vorhergehende und auch zukünftige Versionen (ownDocument_setId, M [1..1])
TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.
+
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number, O [0..1])
 +
#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).
  
Der formatCodeDisplayName ist analog zum formatCode aus den displayNames des entsprechenden Value Sets [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS] 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:'''
+
{{BeginYellowBox}}
* '''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''
+
Im Rahmen von ELGA MUSS die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten strukturiert sein.
* '''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''
+
{{EndYellowBox}}
* '''ELGA Laborbefund, EIS Full Support v2.06+'''
 
  
====Spezifikation====
 
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br/>
 
<span >$code</span> = ClinicalDocument/hl7at:formatCode/@code <br/>
 
<span >$displayName</span> = gemäß Liste der in ELGA gültigen FormatCodes<br/>
 
<span >$codeSystem</span> = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]
 
<pre class="ilfbox_code">
 
<Classification
 
    classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
 
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
 
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
 
    nodeRepresentation="$code">
 
    <Name>
 
        <LocalizedString value="$displayName"/>
 
    </Name>
 
    <Slot name="codingScheme">
 
        <ValueList>
 
            <Value>urn:oid:$codeSystem</Value>
 
        </ValueList>
 
    </Slot>
 
</Classification>
 
</pre>
 
  
===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
+
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA.
+
 
Es wird der Code aus dem CDA Header Element "healthCareFacility" genutzt.
+
Dieser Datentyp ist in IHE ITI TF-3<ref name="ITITF3"/> Data Types in folgender Weise spezifiziert:
  
====Spezifikation====
+
{| class="wikitable" width="100%"
 +
!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.<br />
 +
Therefore, Universal Id Type is always ISO. The required format is: <br />IdNumber^^^&OIDofAA&ISO<br />No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above.<br />An explicit example is:<br />543797436^^^&1.2.840.113619.6.197&ISO<br />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.
  
'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
+
*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.
 +
|}
  
<span >$code </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code
+
{{BeginYellowBox}}
 +
'''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.{{EndYellowBox}}
  
<span >$displayName </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName
+
====Versionierung bzw. Versionsklammer (ownDocument_setId)====
 +
Um eine eindeutige Identifikation aller registrierten Versionen eines CDA R2 Dokumentes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Es kann ein beliebiger Identifikator verwendet werden, solange er die Anforderung erfüllt, alle registrierten Versionen eines CDA R2 Dokuments mit derselben ID eindeutig zu kennzeichnen. Für ELGA wird dazu ownDocument_setId definiert, die auf dem CDA Header-Element "setId" basiert.
  
<span >$codeSystem </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem
+
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).''"
 
<pre class="ilfbox_code">
 
<Classification
 
    classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
 
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
 
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
 
    nodeRepresentation="$code">
 
    <Name>
 
        <LocalizedString value="$displayName"/>
 
    </Name>
 
    <Slot name="codingScheme">
 
        <ValueList>
 
            <Value>urn:oid:$codeSystem</Value>
 
        </ValueList>
 
    </Slot>
 
</Classification>
 
</pre>
 
  
===mimeType===
+
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:  
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.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>
 
<ref name="RFC2046">Multipurpose Internet Mail Extensions (MIME) Part Part Two: Media Types [http://tools.ietf.org/html/rfc2046 IETF RFC 2046]</ref>
 
<ref name="RFC2047">Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text [http://tools.ietf.org/html/rfc2047 IETF RFC 2047]</ref>
 
<ref name="RFC2048">Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [http://tools.ietf.org/html/rfc2048 IETF RFC 2048]</ref>
 
<ref name="RFC2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>
 
  
Im Fall von CDA R2 Dokumenten ist der Mime Type laut IHE immer fix "text/xml".
+
#Laut Vorgabe der ELGA Dokumenten Leitfäden ist die Angabe einer setId für das Dokument verpflichtend:
 +
#*ClinicalDocument/setId [M]
  
====Spezifikation====
+
=====Spezifikation=====
 +
ownDocument-SetId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.
+
concat
  
Folgende Mime-Types sind für Dokumente zugelassen:<br/>
+
(
CDA R2: '''text/xml'''<br/>
 
DICOM/KOS: '''application/dicom'''<br/>
 
 
 
<pre class="ilfbox_code">
 
<ExtrinsicObject
 
            id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
 
            mimeType="text/xml"
 
            objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
 
            status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>
 
</pre>
 
 
 
===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:
+
ClinicalDocument/setId/@extension, "^^^", "&amp;amp;",
  
# Im CDA werden die Informationen über Dokumente, die mit dem eingebrachten Dokumenten in einer bestimmten Relation stehen, in folgendem Element abgelegt:
+
ClinicalDocument/setId/@root, "&amp;amp;ISO", "^",  
## ClinicalDocument/relatedDocument
 
# Der Typ der Relation MUSS verpflichtend in folgendem Attribut angegeben werden:
 
## ClinicalDocument/relatedDocument/@typeCode
 
## Folgende Relationen sind in ELGA erlaubt (siehe „[[ILF:Allgemeiner Implementierungsleitfaden 2020|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente]]“ [1]):
 
### Versionierung (RPLC)
 
# Das zugrundeliegende Dokument (auf welches die Art der Relation wirkt), wird in folgendem Element angegeben:
 
## ClinicalDocument/relatedDocument/parentDocument
 
  
====Spezifikation====
+
"<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>", "^", "&amp;amp;",
  
'''parentDocumentId''' MUSS mit folgenden Elementen in CDA übereinstimmen:
+
homeCommunityId, "&amp;amp;ISO"
  
concat(
 
ClinicalDocument/relatedDocument/parentDocument/id/@root,"^",
 
ClinicalDocument/relatedDocument/parentDocument/id/@extension
 
 
)
 
)
  
 +
Bitte beachten Sie, dass sowohl die ClinicalDocument/setId/@root als auch die homeCommunityId in der Schreibweise "&", OID-Wert, "&ISO" anzugeben sind.
  
  
 +
Beispiel 1: setId/@root und setId/@extension sind im CDA strukturiert. In /@extension wird KEINE UUID angegeben.
  
'''parentDocumentRelationship''' MUSS mit folgenden Elementen in CDA übereinstimmen:
+
<pre class="ilfbox_code">
 +
<ClinicalDocument xmlns="urn:hl7-org:v3">
 +
 +
<setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZZZZZ"/>
 +
<versionNumber value="2"/>
 +
 +
</ClinicalDocument>
 +
</pre>
  
ClinicalDocument/relatedDocument/@typeCode
+
Wie oben angeführt wird folgender CXi Wert erstellt:
 +
<pre class="ilfbox_code">
 +
<ExtrinsicObject mimeType="text/xml"
 +
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
 +
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
 +
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
 +
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
 +
        <ValueList>        <Value>ZZZZZZZZZZZZZZZZZZZ^^^&amp;amp;1.2.40.0.34.99.111.1.1
 +
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>
 +
^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
 +
        </ValueList>
 +
    </Slot>
 +
</ExtrinsicObject>
 +
</pre>
 +
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.
  
  
 +
Beispiel 2: in setId/@extension im CDA wird eine UUID geführt
  
===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 wurde für die HL7-Austria Domäne wurde ein genau entsprechendes Element geschaffen, "hl7at:practiceSettingCode".
 
 
====Spezifikation====
 
 
'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classificationgemäß folgender Vorschrift zusammengesetzt:
 
 
<span >$code</span> = ClinicalDocument/hl7at:practiceSettingCode/@code<br/>
 
<span >$displayName</span> = ClinicalDocument/hl7at:practiceSettingCode/@displayName<br/>
 
<span >$codeSystem</span> = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem<br/>
 
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
<Classification
+
<ClinicalDocument xmlns="urn:hl7-org:v3">
    classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
+
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
+
<setId root="2.25" extension="urn:uuid:19FEE6C3-6B35-4C5B-B1CC-2B5B4001AB2"/>
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
+
<versionNumber value="2"/>  
    nodeRepresentation="$code">
+
    <Name>
+
</ClinicalDocument>
        <LocalizedString value="$displayName"/>
 
    </Name>
 
    <Slot name="codingScheme">
 
        <ValueList>
 
            <Value>urn:oid:$codeSystem</Value>
 
        </ValueList>
 
    </Slot>
 
</Classification>
 
 
</pre>
 
</pre>
  
===objectType ===
+
Wie oben angeführt wird folgender CXi Wert erstellt:
Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen „stabiles Dokument“ (stable document, SD) und „On-demand Dokument“ (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.
 
  
Für "Stable Document" DocumentEntry:
+
"<nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^&amp;amp;2.25&amp;amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</nowiki>"
 
<pre class="ilfbox_code">
 
<pre class="ilfbox_code">
 
<ExtrinsicObject mimeType="text/xml"
 
<ExtrinsicObject mimeType="text/xml"
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
+
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
+
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
    id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
+
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
</pre>
+
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
 
+
        <ValueList>
Für "On-Demand Document" DocumentEntry:
+
            <Value><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki><nowiki>&</nowiki>amp;amp;2.25
<pre class="ilfbox_code">
+
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki>
<ExtrinsicObject mimeType="text/xml"
+
&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
    objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
+
        </ValueList>
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
+
    </Slot>
    id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
+
</ExtrinsicObject>
 
</pre>
 
</pre>
  
==ELGA-spezifische Erweiterungen der XDS-Metadaten==
+
====Referenz zwischen Dokument und Studie (Accession Number)====
Die folgenden Daten entsprechen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information.  
+
Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (''acquisition, store'') als auch bei der Befundschreibung (''report'') verfügbar ist. Dies trifft auf die Accession Number zu (bzw. ein vergleichbares Element, das im implementierten Workflow zur Verknüpfung von Studie und Befund verwendet wird).  
 +
 
 +
=====Spezifikation=====
  
===elgaFlag===
+
Für Befunde der bildgebenden Diagnostik (diagnostic image report) KANN als Accession Number jene aus der ReferenceIdList der XDS-I Metadaten des KOS Objektes, mit dem eine Verlinkung hergestellt werden soll, genutzt werden. Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Das elgaFlag dient zur Kennzeichnung eines Dokuments als „ELGA-Dokument“<sup>18</sup>. 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"
 
  
====Spezifikation====
+
Accession Number wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
<pre class="ilfbox_code">
 
<Slot name="urn:elga-bes:elgaFlag">
 
    <ValueList>
 
        <Value>true</Value>
 
    </ValueList>
 
</Slot>
 
</pre>
 
  
 +
$id = Accession Number z.B. 20201111
  
 +
$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1
  
<sup>18</sup> 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.
+
concat
  
===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.
+
$id, "^^^", "&amp;amp;"
  
====Spezifikation====
+
$root,  "&amp;amp;ISO", "^",
<pre class="ilfbox_code">
+
 
  <rim:Slot name="urn:elga-bes:elgaHash">
+
"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
    <rim:ValueList>
 
      <rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>
 
    </rim:ValueList>
 
  </rim:Slot>
 
</pre>
 
  
 +
)<pre class="ilfbox_code">
 +
<ExtrinsicObject mimeType="text/xml"
 +
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
 +
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
 +
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
 +
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
 +
        <ValueList>       
 +
            <Value>20201111^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
 +
        </ValueList>
 +
    </Slot>
 +
</ExtrinsicObject>
 +
</pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"
 +
<br />
  
 +
====Verlinkung via Aufenthaltszahl (encounterId)====
 +
Durch encounterId wird die Verlinkung sämtlicher Befunde oder Bilddaten (siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#referenceIdList|referenceIdList]] für Dicom KOS-Objekte), die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-Metadaten unterstützt. Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-/XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird.
  
 +
<br />
 +
=====Spezifikation=====
 +
encounterId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
  
<!--Anhänge-->
+
concat
  
=Anhänge=
+
(
==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
 
  
|-
+
ClinicalDocument/componentOf/encompassingEncounter/id/@extension, "^^^", "&amp;amp;",
|[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
 
  
|-
+
ClinicalDocument/componentOf/encompassingEncounter/id/@root, "&amp;amp;ISO", "^",
|[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
 
  
|-
+
"<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"
|[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
 
  
|-
+
Bitte beachten Sie, dass die ClinicalDocument/componentOf/encompassingEncounter/id/@root
|[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
 
  
|-
+
in der Schreibweise "&", OID-Wert, "&ISO" anzugeben ist.
|[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
 
|}
 
  
==Revisionsliste==
+
Wie oben angeführt wird folgender CXi Wert erstellt:<pre class="ilfbox_code">
{| class="wikitable"
+
<ExtrinsicObject mimeType="text/xml"
!Vers.
+
    objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
!Datum
+
    status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
!Änderungsgrund
+
    id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
|-
+
    <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
|0.05
+
        <ValueList>
|16.05.2011
+
            <Value>Az123456^^^&amp;amp;1.2.40.0.34.99.4613.3.4&amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>
|Ergebnisse aus dem technischen Online-Meeting
+
            </Value>
|-
+
        </ValueList>
|2.00 Beta
+
    </Slot>
|12.08.2011
+
</ExtrinsicObject>
|Erster „Release candidate“ des Dokuments für internen Review innerhalb der Arbeitsgruppe.
+
</pre>
|-
+
 
|2.00 rc1
+
 
|30.08.2011
+
 
|Redaktionelle Überarbeitung.
+
<br />
|-
+
 
|2.00 FWGD
+
===intendedRecipient===
|10.10.2011
+
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.
|Fertigstellung des „Final Working Group Draft“. Veröffentlicht für öffentlichen Review.
+
 
|-
+
Der intendedRecipient entfällt bei On-Demand Documents.
|2.01
+
 
|11.06.2012
+
==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
|Fertigstellung der gültigen Version 2.01 „Final“. <br />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
+
===availabilityStatus===
|-
+
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Dokuments.
|2.01
+
 
|21.12.2012
+
Mögliche Werte laut IHE sind:
|Layout-Anpassung
+
 
|-
+
*Approved
|2.01a
+
*Deprecated
|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.) <br />Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt <br />Allgemein: Typos ausgebessert
+
Dieses Attribut wird im Zuge des Einbringens von neuen Dokumenten ("Submission") durch die empfangende XDS Registry immer auf "'''Approved'''" gesetzt.
|-
+
 
|2.02
+
availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.
|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.
+
<pre class="ilfbox_code">
|-
+
<ExtrinsicObject mimeType="text/xml"
|2.02
+
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
|12.08.2013
+
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
|2.3.2.3 PDF/A-1a-Vorschrift hinzugefügt
+
    id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
|-
+
</pre>
|2.02
+
 
|13.08.2013
+
===formatCode (und formatCodeDisplayName)===
|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF/A-1a-
+
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 wurde für die HL7-Austria Domäne ein genau entsprechendes Element geschaffen, "hl7at:formatCode".
|2.02
+
 
|17.09.2013
+
====Spezifikation====
|Typos, Formatierung und Seitenumbrüche ausgebessert
+
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br />
|-
+
<span>$code</span> = ClinicalDocument/hl7at:formatCode/@code <br />
|2.02a
+
<span>$displayName</span> = ClinicalDocument/hl7at:formatCode/@displayName <br />
|06.02.2014
+
<span>$codeSystem</span> = ClinicalDocument/hl7at:formatCode/@codeSystem
|Beispiele in Tabelle 3 korrigiert
+
<pre class="ilfbox_code">
|-
+
<Classification
|2.03
+
    classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
|26.02.2014
+
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
|Definition von ReferenceIdList eingefügt
+
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
|-
+
    nodeRepresentation="$code">
|2.03
+
    <Name>
|03.03.2014
+
        <LocalizedString value="$displayName"/>
|Definition von intendedRecipient eingefügt
+
    </Name>
|-
+
    <Slot name="codingScheme">
|2.03
+
        <ValueList>
|03.03.2014
+
            <Value>urn:oid:$codeSystem</Value>
|Änderungen in Tabelle 3: <br /> LegalAuthenticator – von [R] auf [R2] geändert<br /> IntendedRecipient – von "-" auf [O] geändert, für Verwendung mit XDW vorgesehen<br /> ReferenceIdList hinzugefügt<br /> Den Namen des Value Sets von „ELGA-PracticeSettingCode“ auf „ELGA-PracticeSettingCode-vs“ geändert
+
        </ValueList>
|-
+
    </Slot>
|2.03.
+
</Classification>
|03.03.2014
+
</pre>
|Anhang gelöscht: <br /> 3.1. IHE ITI-TF3, Kapitel 4.1.7 „Document Definition Metadata“<br /> 3.2. IHE PCC-TF2, Kapitel 4.1.1 „XDSDocumentEntry Metadata“<br /> 3.3. IHE XDS Data Types
+
 
|-
+
===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
|2.03
+
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA.
|03.03.2014
+
Es wird der Code aus dem CDA Header Element "healthCareFacility" genutzt.
|Korrekturen: <br /> ITI Version einheitlich geändert auf “(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)“.<br /> 1.1.3 Hinweis auf Terminologieserver hinzugefügt<br /> Tabelle 3 angepasst:<br /> EntryUUID Beschreibung geändert<br /> patientId Beschreibung geändert
+
 
|-
+
====Spezifikation====
|2.03
+
 
|06.03.2014
+
'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
|Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId
+
 
|-
+
<span>$code </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code
|2.03
+
 
|21.03.2014
+
<span>$displayName </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName
|Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt
+
 
|-
+
<span>$codeSystem </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem
|2.03
+
|26.03.2014
+
<pre class="ilfbox_code">
|Kapitel 1.4. Korrektur von Dokumentverweisen
+
<Classification
|-
+
    classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
|2.03a
+
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
|28.03.2014
+
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
|Kapitel 2.1 Korrektur von Fußnotennummern
+
    nodeRepresentation="$code">
|-
+
    <Name>
|2.03a
+
        <LocalizedString value="$displayName"/>
|28.03.2014
+
    </Name>
|Kapitel 2.2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000
+
    <Slot name="codingScheme">
|-
+
        <ValueList>
|2.03b
+
            <Value>urn:oid:$codeSystem</Value>
|1.7.2014
+
        </ValueList>
|Den Namen des Value Sets von „ELGA-PracticeSetting Code-vs“ auf „ELGA_Practicesetting_VS“ korrigiert
+
    </Slot>
|-
+
</Classification>
|2.03b
+
</pre>
|11.07.2014
+
 
|2.3.2.5 OID in der Spezifikation ergänzt
+
===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.<ref name="RFC2045"/>
|2.03b
+
<ref name="RFC2046">Multipurpose Internet Mail Extensions (MIME) Part Part Two: Media Types [http://tools.ietf.org/html/rfc2046 IETF RFC 2046]</ref>
|11.07.2014
+
<ref name="RFC2047">Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text [http://tools.ietf.org/html/rfc2047 IETF RFC 2047]</ref>
|2.3.6 OID in der Spezifikation ergänzt
+
<ref name="RFC2048">Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [http://tools.ietf.org/html/rfc2048 IETF RFC 2048]</ref>
|-
+
<ref name="RFC2049"/>
|2.03b
+
 
|05.08.2014
+
Im Fall von CDA R2 Dokumenten ist der Mime Type laut IHE immer fix "text/xml".
|2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert
+
 
|-
+
====Spezifikation====
|2.03b
+
 
|06.08.2014
+
'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, welches das DocumentEntry repräsentiert.
|2.1 Überblickstabelle: ParentDocumentId und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]
+
 
|-
+
Folgende Mime-Types sind für Dokumente zugelassen:<br />
|2.03b
+
CDA R2: '''text/xml'''<br />
|06.08.2014
+
 
|Referenzen auf CDA Implementierungsleitfäden aktualisiert
+
<pre class="ilfbox_code">
|-
+
<ExtrinsicObject
| colspan="3" |Version 2.05
+
            id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
|-
+
            mimeType="text/xml"
|2.05
+
            objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
|03.11.2014
+
            status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>
|EntryUUID als „ELGA-Relevant“ klassifiziert.<br /> Darstellung der Übersichtstabelle geändert
+
</pre>
|-
+
 
|2.05
+
===parentDocumentId, parentDocumentRelationship===
|03.11.2014
+
Das ''parentDocumentId'' Element verweist auf das Dokument, zu dem das eingebrachte Dokument in einer bestimmten Relation steht.
|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)
+
 
|-
+
Das ''parentDocumentRelationship'' Element beschreibt den Typ der Relation (Versionierung, Transformation).
|2.05
+
 
|19.11.2014
+
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.
|2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht
+
 
|-
+
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
|2.05
+
 
|19.11.2014
+
#Im CDA werden die Informationen über Dokumente, die mit dem eingebrachten Dokumenten in einer bestimmten Relation stehen, in folgendem Element abgelegt:
|2.2.2. authorPerson: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.
+
##ClinicalDocument/relatedDocument
|-
+
#Der Typ der Relation MUSS verpflichtend in folgendem Attribut angegeben werden:
|2.05
+
##ClinicalDocument/relatedDocument/@typeCode
|19.11.2014
+
##Folgende Relationen sind in ELGA erlaubt (siehe "[[ILF:Allgemeiner Implementierungsleitfaden 2020|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente]]" [1]):
|2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden
+
###Versionierung (RPLC)
|-
+
#Das zugrundeliegende Dokument (auf welches die Art der Relation wirkt), wird in folgendem Element angegeben:
|2.05
+
##ClinicalDocument/relatedDocument/parentDocument
|19.11.2014
+
 
|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software
+
====Spezifikation====
|-
+
 
|2.05
+
'''parentDocumentId''' MUSS mit folgenden Elementen in CDA übereinstimmen:
|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]
+
concat(
|-
+
ClinicalDocument/relatedDocument/parentDocument/id/@root,"^",
|2.05
+
ClinicalDocument/relatedDocument/parentDocument/id/@extension
|26.11.2014
+
)
|2.4 ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und ELGA-Flag. Auch in 2.1 entsprechend angegeben.
+
 
|-
+
'''parentDocumentRelationship''' MUSS mit folgenden Elementen in CDA übereinstimmen:
|2.05
+
 
|12.03.2014
+
ClinicalDocument/relatedDocument/@typeCode
|Seite 2-3: Absätze  „Verbindlichkeit“, „Hinweise zur Verwendung“ und „Erarbeitung des Implementierungsleitfadens“ hinzugefügt.
+
 
|-
+
===practiceSettingCode (und practiceSettingCodeDisplayName)===
| colspan="3" |Version 2.06
+
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.  
|-
+
 
|2.06
+
Im CDA-Schema wurde für die HL7-Austria Domäne ein entsprechendes Element in den CDAs geschaffen, "hl7at:practiceSettingCode".  
|19.05.2015
+
 
|1.2.2. Codesysteme und Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.
+
====Spezifikation====
|-
+
 
|2.06
+
'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classificationgemäß folgender Vorschrift zusammengesetzt:
|13.10.2015
+
 
|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch
+
<span>$code</span> = ClinicalDocument/hl7at:practiceSettingCode/@code<br />
|-
+
<span>$displayName</span> = ClinicalDocument/hl7at:practiceSettingCode/@displayName<br />
|2.06
+
<span>$codeSystem</span> = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem<br />
|13.10.2015
+
<pre class="ilfbox_code">
|1.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.
+
<Classification
|-
+
    classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
|2.06
+
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
|07.10.2015
+
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
|1.4.3. Kapitel „Metadaten aus „On-Demand Documents“ (ODD)“ eingefügt
+
    nodeRepresentation="$code">
|-
+
    <Name>
|2.06
+
        <LocalizedString value="$displayName"/>
|10.09.2015
+
    </Name>
|2.1 Tabelle 3: Beschreibung der entryUUID ergänzt
+
    <Slot name="codingScheme">
|-
+
        <ValueList>
|2.06
+
            <Value>urn:oid:$codeSystem</Value>
|07.10.2015
+
        </ValueList>
|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)
+
    </Slot>
|-
+
</Classification>
|2.06
+
</pre>
|30.10.2015
+
 
|2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt wird, falls mehrere ID-Elemente angegeben sind.
+
===objectType===
|-
+
Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "stabiles Dokument" (stable document, SD) und "On-demand Dokument" (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.
|2.06
+
 
|19.05.2015
+
Für "Stable Document" DocumentEntry:
|2.2.5. und 2.2.15: Typos verbessert
+
<pre class="ilfbox_code">
|-
+
<ExtrinsicObject mimeType="text/xml"
|2.06
+
    objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
|29.10.2015
+
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
|2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt
+
    id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
|-
+
</pre>
|2.06
+
 
|21.07.2015
+
Für "On-Demand Document" DocumentEntry:
|2.2.10. legalAuthenticator: Hinweis, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar ist.
+
<pre class="ilfbox_code">
|-
+
<ExtrinsicObject mimeType="text/xml"
|2.06
+
    objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
|08.10.2015
+
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
|2.3.7 objectType hinzugefügt
+
    id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
|-
+
</pre>
| colspan="3" |'''Version 2.06.2 (Nebenversion)'''<br /> x …betrifft Implementierung (erste Spalte)
+
 
|-
+
==ELGA-spezifische Erweiterungen der XDS-Metadaten==
|
+
Die folgenden Daten erweitern den IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt.  
|01.08.2016
+
 
|Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
+
===elgaFlag===
|-
+
Das elgaFlag dient zur Kennzeichnung eines Dokuments als "ELGA-Dokument"<sup>18</sup>. 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:
|
+
 
|18.5.2016
+
*"true"    oder
|1.2 Erklärung zur Verwendung von XDS Folder und SubmissionSet hinzugefügt.
+
*"false"
|-
+
<sup>18</sup> 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.
|
+
====Spezifikation====
|01.08.2016
+
 
|2.1. Tabelle 3: Korrektur der Optionalität von eventCodeList auf [R2], wie im Text bei 2.2.8 angegeben
+
<pre class="ilfbox_code">
|-
+
<Slot name="urn:elga-bes:elgaFlag">
|x
+
    <ValueList>
|14.6.2016
+
        <Value>true</Value>
|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.
+
    </ValueList>
|-
+
</Slot>
|
+
</pre>
|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
+
===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.
|
+
 
|05.01.2017
+
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.
|2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.
+
 
|-
+
====Spezifikation====
|
+
<pre class="ilfbox_code">
|y
+
  <rim:Slot name="urn:elga-bes:elgaHash">
|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;amp;"
+
    <rim:ValueList>
|-
+
      <rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>
|
+
    </rim:ValueList>
|y
+
  </rim:Slot>
|Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
+
</pre>
|-
+
 
|
+
<!--Anhänge-->
|y
+
 
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
+
=Anhänge=
|-
+
 
|
+
==Einzelnachweise==
|y
+
<references />
|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.
+
==Literatur und Weblinks ==
|-
+
* IHE International https://www.ihe.net/
|
+
* HL7® International http://www.hl7.org/
|
+
* Clinical Document Architcture (CDA®) Release 2.0 https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
+
* DICOM® — Digital Imaging and Communications in Medicine https://www.dicomstandard.org/
|-
+
* Österreichische CDA Implementierungsleitfäden [https://wiki.hl7.at/index.php?title=Implementierungsleitf%C3%A4den HL7 Austria Wiki]
|
+
 
|
+
==Revisionsliste==
|Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
+
 
|-
+
===Hauptversion 3.0.0 (2021)===
|
+
Diese Hauptversion wurde auf Basis der neuen Vorgaben aus dem Allgemeinen Implementierungsleitfaden 3.0.0 grundlegend überarbeitet und umstrukturiert. Hinzugekommen sind die Vorgaben für die Registrierung von DICOM KOS-Objekten. Auf eine Revisionsliste mit direktem Vergleich zur Vorversion wurde daher verzichtet.
|
+
Die relevanten Änderungen sind:
|Kapitel "4.2.7 legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
+
{| class="wikitable"
|-
+
|-
|
+
|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;amp;"
|
+
|-
|Kapitel "4.2.4 creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
+
|"referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
|-
+
|-
|
+
|"Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
|y
+
|-
|Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
+
|"Spezifikation": Verbot von CR und LF hinzugefügt.
|-
+
|-
|
+
|"Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
|y
+
|-
|Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
+
|"sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
|-
+
|-
|
+
|"legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
|
+
|-
|Kapitel "4.2.2.1 Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
+
|"creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
 +
|-
 +
|"healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
 +
|-
 +
|"formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
 +
|-
 +
|"Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
 +
|-
 +
|"XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.
 +
|-
 +
|"referenceIdList": Ergänzung der Verwendung der encounterId
 
|}
 
|}
 +
 +
===Hauptversion 2.06===
 +
Eine Liste vorherigen Revisionen findet sich auf der '''[[ILF_Diskussion:XDS_Metadaten_(Version_3)|Diskussionsseite]]'''.
 +
 +
==Erratum==
 +
Weitere Probleme und allfällige Korrekturen werden auf der [[ILF_Diskussion:XDS_Metadaten_(Version_3)|Diskussionsseite]] im Wiki gesammelt.

Aktuelle Version vom 26. Januar 2022, 13:53 Uhr


Inhaltsverzeichnis


1 Zusammenfassung

Dieses Dokument beschreibt die IHE XDS Metadaten (XDSDocumentEntry), die für die Registrierung von Befunden (HL7 CDA) und Bilddaten (DICOM KOS) in der ELGA Infrastruktur notwendig sind und wie sie aus den zugrundeliegenden Informationsobjekten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden XDS-Metadaten-Guide im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.

Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für die Registrierung elektronischer Dokumente in der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012)[1]. Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing[2] und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) [3] sowie DICOM Key Object Selection Documents (in Folge KOS)[4].

2 Informationen über dieses Dokument

2.1 Impressum

Medieneigentümer, Herausgeber, Hersteller, Verleger:
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050
Internet: 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: Sofern nicht anders angegeben: © ELGA GmbH

Nutzung: Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria www.hl7.at.
Die Nutzung ist ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente 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.2 Haftungsausschluss

Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht und über ein öffentliches Kommentierungsverfahren kontrolliert. Die Nutzung des vorliegenden Leitfadens erfolgt in ausschließlicher Verantwortung der Anwender. Aus der Verwendung des vorliegenden Leitfadens können keinerlei Rechtsansprüche gegen die Autoren, Herausgeber oder Mitwirkenden erhoben und/oder abgeleitet werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls nicht beabsichtigt und von den Erstellern des Dokumentes nicht gewünscht.

2.3 Sprachliche Gleichbehandlung

Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer, Frauen und andere Geschlechtsidentitäten 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.

2.4 Lizenzinformationen

Die Verwendung dieses Leitfadens für die Zwecke der Erstellung, des Verkaufs und des Betriebs von Computerprogrammen, sofern nicht anders angegeben oder sich die Standards auf andere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen, ist ausdrücklich genehmigt.

Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance[5] .

2.4.1 Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")

Third Party Intellectual Property

Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass der Herausgeber nicht alle Rechte und Ansprüche in und an den Materialien besitzt und dass die Materialien geistiges Eigentum von Dritten enthalten und / oder darauf verweisen können ("Third Party Intellectual Property (IP)").
Die Anerkennung dieser Lizenzbestimmungen gewährt dem Lizenznehmer keine Rechte in Bezug auf Third Party IP. Der Lizenznehmer allein ist für die Identifizierung und den Erhalt von notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig verantwortlich.
Jegliche Handlungen, Ansprüche oder Klagen eines Dritten, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, bleiben die Haftung des Lizenznehmers.

2.5 Verbindlichkeit

Die Verbindlichkeit und die Umsetzungsfrist von Leitfäden sind im Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.

Ein Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten ("Mandatory" [M], "Required" [R] und "Fixed" [F]), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.

Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit österreichischem und europäischem Recht, insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz, Gesundheitstelematikgesetz 2012, DSGVO) 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.

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

2.6 Verwendete Grundlagen und Bezug zu anderen Standards

Grundlage dieses Implementierungsleitfadens ist der internationale Standard IHE ITI Cross-enterprise Document Sharing [2] von Integrating the Healthcare Enterprise (IHE)[6].

Weiters bezieht sich dieser Leitfaden auf den internationalen Standard "HL7® Clinical Document Architecture, Release 2.0" (CDA ®)[3], für die das Copyright © von Health Level Seven International[7] gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert[8]. CDA definiert die Struktur und Semantik von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und Patienten. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen. Die Dokumentmetadaten für CDA Dokumente im Österreichischen Gesundheitswesen werden grundsätzlich vom "Allgemeinen CDA Implementierungsleitfaden"[9] definiert. Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)[10], die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden. 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.

Dieser Leitfaden basiert auf den Vorgaben des Allgemeinen Implementierungsleitfadens Version 3 und gilt entsprechend für alle CDA-Dokumente, die auf Basis des Leitfadens erstellt werden.

2.7 Wichtige unterstützende Materialien

Auf der Website: XDS Metadaten Guide werden unter anderem folgende Materialien zur Verfügung gestellt:

  • die PDF-Version dieses Leitfadens

Gemeinsam mit diesem Leitfaden werden auf der Website der ELGA GmbH (Website der ELGA GmbH) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:

  • ELGA-Gesamtarchitektur[11]
  • Beispieldokumente
  • Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
  • CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
  • Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
  • Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
  • Hinweise für die zu verwendenden Terminologien
  • Leitfaden zur richtigen Verwendung von Terminologien
Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an cda@elga.gv.at gesendet werden. Weitere Informationen finden Sie unter www.elga.gv.at/CDA.

2.8 Bedienungshinweise

2.8.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".


2.8.2 PDF-Navigation

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



3 Harmonisierung

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

Autoren
Organisation Person1
Herausgeber, Projektleiter, CDA-Koordinator
ELGA GmbH Stefan Sabutsch
Autoren
CodeWerk Software Services and Development GmbH Jürgen Brandstätter
DICOM Austria Emmanuel Helm
DICOM Austria Silvia Winkler
ELGA GmbH, HL7 Austria Stefan Sabutsch
ELGA GmbH Oliver Kuttin
ELGA GmbH Stefan Repas
Wiener Krankenanstaltenverbund Konrad Hölzl

1 Namen ohne Titel

4 Einleitung

4.1 Intention und Abgrenzung

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

Eine IHE XDS Registry verwaltet Dokumente und macht diese zugänglich. Sie erlaubt die Suche und das Filtern nach den Dokumenten über die Metadaten der Dokumente (Metadaten sind Daten, die andere Daten definieren und beschreiben). Werden, wie für ELGA, mehrere Registries gemeinsam genutzt, müssen die Metadaten übergreifend harmonisiert werden und Metadatenstandards bereitgestellt werden: Wertebereiche, Abhängigkeiten, Zuständigkeit, Abbildungsregeln, Versionierung und Policies.

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

4.2 Gegenstand dieses Dokuments

Dieses Dokument definiert die Metadaten beim Einbringen von Dokumenten in Form von Befunden[9] oder Bilddaten in die ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)[2]. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet:

  • Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumente (Metadaten der XDSDocumentEntry Objekte): IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 12.0 (22.4.2016) Final Text[12]

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 Spezifikation wurde im Zusammenhang mit dem "Allgemeinen Implementierungsleitfaden"[9], den "ELGA CDA Implementierungsleitfäden" und dem Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch[13] erstellt.

4.2.1 XDS Folder

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

4.2.2 XDS Submission Sets

Mit Ausnahme der Kapitel "5.1.12.2 submissionSet.contentTypeCode" und "6.1.12.2 submissionSet.contentTypeCode" wird keine weitere Profilierung des XDS Submission Sets gegenüber dem XDS Standard in ELGA vorgenommen.

Etwaige, Service-spezifische, Vorgaben auf Schnittstellen-Ebene sind in den entsprechenden Schnittstellenspezifikationen (u.a. Schnittstellen Berechtigungssystem, Schnittstellenspezifikation zur Anbindung des elektronischen Impfpasses) angeführt und im Rahmen konkreter System-Anbindungen zu berücksichtigen.

4.3 Hinweise zur Verwendung des Dokuments

4.3.1 Codesysteme und Value Sets

Die in diesem Dokument erwähnten Codesysteme bzw. Value Sets werden am 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.

4.3.2 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/).

4.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 in den "ELGA CDA-Implementierungsleitfäden" ersichtlich. 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.

4.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:

4.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.

4.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. Hierbei MUSS die SetId der referenceIdList in den XDS-Metadaten zum neuen Dokument der der Vorgängerversion entsprechen. Die XDS-Metadaten der Vorgängerversion des 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.

4.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.

4.4.2 Größenbeschränkung

ELGA schreibt für die Größe der eingebrachten CDA eine Maximalgröße von 20 MB vor. Größere Dokumente sind abzulehnen. Es liegt generell 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, Kapitel 6.10.

4.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 TF-3)[12].

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: Siehe auch Vorschriften zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3[12].

4.5.1 Metadaten aus unstrukturierten Dokumenten

Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument oder binären Objekt 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 oder binäre Objekt korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden.

4.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 11.0, Volume 2, Kapitel XDSDocumentEntry Metadata beschrieben.[14]

4.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 für On-Demand Documents findet sich IT Infrastructure Technical Framwork (ITI), Volume 3[12].

4.5.4 Metadaten aus Bilddaten (KOS)

Bilddaten können über KOS-Objekte (Key Object Selection Document) referenziert und abgerufen werden. Die notwendigen Metadaten können in gewissem Maße aus diesen KOS-Objekten selbst automatisiert entnommen werden. Eine genaue Beschreibung für den Aufbau von KOS-Objekten findet sich im Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch.

4.5.5 XDS Metadaten im Vergleich IHE vs. ELGA

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

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

Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).

4.6 Überblickstabelle der XDS-I Metadaten für DICOM KOS Objekte

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

In der Tabelle 3 werden die XDS-I Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität) angegeben.


Tabelle 1: Legende zur Spalte "Quelle" der folgenden Tabelle

Code Bedeutung
K Aus KOS-Inhalt abgeleitet
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 2: Legende zur Spalte "Optionalität" der folgenden Tabelle

Code Bedeutung
M Das Element MUSS mit einem korrekten "echten" Wert angegeben werden.

"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ("required").

R Das Element SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ("required if known").
O Optional
NP Das Element ist NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] ("prohibited")


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

Metadaten Element Optionalität Quelle Beschreibung
author (besteht aus den folgenden Komponenten) M [1..1] - Die Person oder das Gerät, welche(s) das Dokument verfasst hat
authorInstitution M [1..1] E1/K ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
authorPerson R [0..1] K Daten der Person

(Name, ID, etc.)

authorRole R [0..1] K Rolle der Person
authorSpeciality R [0..1] E1/K Fachrichtung der Person
classCode M [1..1] A Dokumenten/Objektklasse (Oberklasse)

z.B.: 55113-5 "Key images Document Radiology"

confidentialityCode M [1..1] A Vertraulichkeitscode. Fester Wert "N"
creationTime M [1..1] K Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes
eventCodeList M [1..*] A/K Liste von Codes von Gesundheitsdienstleistungen
eventCodeDisplayName M [1..1] A/K Bezeichnung von Gesundheitsdienstleistungen nach APPC
intendedRecipient NP [0..0] - Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
languageCode M [1..1] A Sprachcode. Fester Wert "de-AT"
legalAuthenticator NP [0..0] - Rechtlicher Unterzeichner
serviceStartTime M [1..1] K Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
serviceStopTime NP [0..0] - Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
sourcePatientId M [1..1] K Patienten ID im Informationssystem des GDA, z.B.: im RIS
sourcePatientInfo NP [0..0] - Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
title M [1..1] A/K Titel des Dokuments
typeCode M [1..1] A Objekttyp (Unterklasse)

codierter Wert

uniqueId M [1..1] K Global eindeutige ID des Objektes

z.B. SOP Instance UID

referenceIdList M [1..*] K/E1 Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
Explizit zu setzende Metadaten
availabilityStatus M [1..1] E1 Gültigkeit des Objektes
formatCode M [1..1] E1 Format des Objektes
healthcareFacilityTypeCode M [1..1] E1 Klassifizierung des GDA
mimeType M [1..1] E1 Mime Type des Dokuments

Fester Wert für KOS: "application/dicom"

parentDocumentId O [0..1] E1 Verweis auf ein referenziertes Objekt
parentDocumentRelationship O [0..1] E1 Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC, XFRM
practiceSettingCode M [1..1] E1 Fachliche Zuordnung des Dokuments
entryUUID M [1..1] E1 UUID des Metadaten-Records des Dokuments(XDS DocumentEntry)
objectType M [1..1] E1 Typ des DocumentEntries

Fester Wert "SD"

comments O [0..1] K Kommentar zum Dokument/Objekt
patientId M [1..1] E1 Patienten-ID in der XDS Affinity Domain
Von Registry oder Repository automatisch gesetzte Metadaten
hash M [1..1] A Hash Wert des Dokuments. Wird vom Repository befüllt
homeCommunityId M [1..1] A 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.
repositoryUniqueId M [1..1] A Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
size M [1..1] A Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository befüllt.


URI NP [0..0] A Wird in XDS-I nicht verwendet
Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)
elgaFlag M [1..1] B Kennzeichnet ein Dokument als "ELGA-Dokument"
elgaHash M [1..1] B Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes




4.7 Überblickstabelle der XDS Metadaten für HL7 CDA Objekte

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 6 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.

Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle

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 5: Legende zur Spalte "Optionalität" der folgenden Tabelle

Code Bedeutung
M Das Element MUSS mit einem korrekten "echten" Wert angegeben werden.

"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ("required").

R Das Element SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ("required if known").
O Optional
NP Das Element ist NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] ("prohibited")


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

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


9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht.
10 ODD: "On-demand Document": Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird.
11 Der Inhalt des typeCodes soll mit dem contentTypeCode des Submission Sets übereinstimmen.
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert.
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein.

5 XDS-I Metadaten für DICOM KOS Objekte

Die folgenden Kapitel spezifizieren die XDS-I Metadaten von DICOM KOS-Objekten für deren Verwendung in ELGA. Nicht weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt[12].

Die folgende Tabelle gibt einen Überblick jener XDS-I Metadaten-Elemente, die direkt aus dem DICOM KOS bzw. der zugrundeliegenden DICOM Study abgeleitet werden können. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in ELGA für das Einbringen von DICOM KOS Objekten, sowie die Quelle aus der die Informationen stammen.

Tabelle 7: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet

XDS-I Metadaten Element Opt. Attribut in

der Studie

Attribut

im KOS

Beschreibung
author M [1..1]
author.authorInstitution M [1..1] (0008,0080) (0008,0080) Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl die Kurzbezeichnung als auch die OID der Institution aus dem GDA-Index anzugeben.

Zur Ermittlung des Namens kann das DICOM Tag (0008,0080) herangezogen werden.

Achtung: Dieses Attribut ist Type 3 (optional) (General Equipment Module).

Achtung: Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.

Die Person, welche die Studie durchführt, ist als author anzugeben:
author.authorPerson R [0..1] (0008,1052) Performing Physicians Identification Sequence

Code und weitere Daten aus dem ersten Item in der Sequence

Achtung: Die Identifikationsdaten der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.

Alternativ:

(0008,1050)

Performing Physicians Name

Enthält dieses Attribut mehrere Namen, so ist der erste Name zu wählen.

Achtung: Die Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.

Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
author.authorPerson R [0..1] (0008,0060) + (0008,0070) + (0008,1090) Modality Code + Manufacturer + Manufacturer's Model Name

Achtung: Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.

creationTime M [1..1] (0008,0020) + (0008,0030) (0008,0020) + (0008,0030) Study Date + Study Time

Für den Fall, dass Study Date und Study Time nicht zur Verfügung stehen, ist es zulässig, den Erstellungszeitpunkt des KOS ((0008,0023) contentDate + (0008,0033) contentTime) als creationTime zu verwenden.

eventCodeList M [1..*] Enthält eine Liste von Codes von Gesundheitsdienstleistungen nach APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" [15]

eventCodeList
DisplayNameList
M [1..1] Enthält den Display Name des APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" [15]

serviceStartTime M [1..1] (0008,0020) + (0008,0030) (0008,0020) + (0008,0030) Study Date und Study Time
sourcePatientId M [1..1] (0010,0020) (0010,0020) Die Patient ID im eigenen Informationssystem
sourcePatientInfo M [1..1] (0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)

(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)

Die ELGA Vorgabe empfiehlt, Name, Geburtstag und Geschlecht NICHT anzugeben.
title M [1..1] (0008,0060) + (0008,1030) Der relevante Modality Code der Studie oder alle Modality Codes der Studie und die Study Description.

Alternativ darf anstatt der Study Description der DisplayName des APPC verwendet werden.

Anmerkung:

Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".

uniqueId M [1..1] (0008,0018) Die SOP Instance UID des KOS
referenceIdList M [1..1] Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
value mit CXi.5 =
"urn:elga:iti:xds:2014: OwnDocument_setId"
M [1..1] (0020,000D) oder ein vergleichbares Attribut (0020,000D) oder ein vergleichbares Attribut Die setId zur Klammerung aller Versionen eines KOS

Diese kann von jedem Bereich frei gewählt werden, sie ist mit dem Datentyp urn:elga:iti:xds:2014:OwnDocument_setId anzugeben.

Eine mögliche Wahl der setId ist die Study Instance UID. Die geeignete Wahl der setId hängt auch vom implementierten Stornoworkflow ab, siehe KOS Leitfaden (Kapitel 8.2.2.)[13]

value mit CXi.5 =
"urn:ihe:iti:xds:2013: accession"
R [0..1] (0008,0050) oder ein vergleichbares Attribut wie z.B.

(0040,1001) Requested Procedure ID

(0008,0050)


Die ID, die zur Verlinkung mit dem Befund heranzuziehen ist.

Diese ist mit dem Datentyp urn:ihe:iti:xds:2013:accession anzugeben.

Achtung:

Welche ID dazu geeignet ist, die Verlinkung mit dem zugehörigen Befund herzustellen, ist vom jeweils implementierten Workflow abhängig.

Gemäß dem Integrationsprofil IHE RAD Scheduled Workflow dient dazu die Accession Number, die im DICOM Attribut (0008,0050) enthalten ist.

Weicht der lokale radiologische Workflow vom IHE Profil ab, kann es erforderlich sein, ein anderes DICOM Attribut für die Verlinkung heranzuziehen.

Unabhängig von der Wahl des DICOM Attributs ist aber in jedem Fall der Datentyp urn:ihe:iti:xds:2013:accession zu verwenden.

comments O [0..1] (0008,1030) (0008,1030) Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.

5.1 XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet

5.1.1 author

Die Person oder Maschine, die das Dokument erstellt hat. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).

5.1.1.1 authorInstitution

Das authorInstitution Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.

Die authorInstitution benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden können. Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag "descriptor" 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"
Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.

  • oid: OID der Organisation aus dem GDA-Index (muss ermittelt werden)
  • name: (0008,0080), Institution Name, Name der Organisation als String,

Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante Kurzbezeichnung zu verwenden.

Achtung: Das DICOM-Tag (0008,0080), Institution Name, ist vom Type 3 (optional) (General Equipment Module).

Achtung: Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.

5.1.1.1.1 Spezifikation

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

$name … Name der Organisation, die die Studie erstellt hat

$oid ... OID der Organisation aus dem GDA-Index

concat(
$name,"^^^^^^^^^",
$oid,"&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="authorInstitution">
        <ValueList>
            <Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO
            </Value>
        </ValueList>
    </Slot>    
</Classification>

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

5.1.1.2 authorPerson

Das Element authorPerson beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche die Bilddaten inhaltlich erstellt hat.

Im Fall eines DICOM Objektes gilt eine Verknüpfung mit folgenden (optionalen) DICOM Attributen:

  1. Die Person kann aus den DICOM Attributen der Studie abgeleitet werden
    • Identifikator: Code aus Attribut "Performing Physicians Identification Sequence", (0008,1052), Datentyp SQ, wenn vorhanden. Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence.
    • Name: Attribut "Performing Physicians Name", (0008,1050), Datentyp PN (entspricht den ersten 5 Feldern von HL7 V2 Datentyp XPN. Maximum 64 Zeichen pro component group, ohne zusätzliche ideographische und phonetische Zeichen). Wenn mehrere Namen vorhanden sind, ist der erste zu übernehmen.
    • Root: OID-Unterknoten für Personen (entsprechend der Organisations-OID aus dem GDA-Index)
  2. Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den folgenden DICOM Attributen abgleitet werden
    • Modalität: Attribut "Modality", (0008,0060), erlaubte Werte siehe DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality [16]
    • Hersteller: Attribut "Manufacturer", (0008,0070)
    • Modellname: Attribut " Manufacturer's Model Name", (0008,1090)


Achtung: Die Identifikationsdaten und Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.

Achtung: Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.

5.1.1.2.1 Spezifikation für Personen

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


1.Fall: Bei der lokalen ID handelt es sich um KEINE OID:

$id = Code #1 aus (0008,1052) Performing Physicians Identification Sequence

$person = (0008,1050) Performing Physicians Name

$root = OID-Knoten für den Personenidentifikator

concat(
$id,"^",
$person,"^",
$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>11375^Musterdoc^Josef^Maria^Msc^DIDr^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
           </Value>
        </ValueList>
    </Slot>    
</Classification>


2. Fall: Bei der lokalen ID handelt es sich um eine OID:

concat(
$id,"^",
$person

)
<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>2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value>
        </ValueList>
    </Slot>    
</Classification>

Dies folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf die XCN Komponenten wie in IHE RAD TF-2 Rev.19 2020[17], "Table 4.68.4.1.2.3-3: XCN Data type mapping" vorgegeben.

5.1.1.2.2 Spezifikation für Software und Geräte

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

$Modality = Modality (0008,0060)

$Manufacturer = Manufacturer (0008,0070)

$ManufacturersModelName = Manufacturer's Model Name (0008,1090)


concat(

"^",

$Modality,"^",

$Manufacturer,"^",

$ManufacturersModelName

)
<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>^CT^Geräthersteller^Gerätename</Value>
        </ValueList>
    </Slot>
</Classification>

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

5.1.1.3 authorRole

Das authorRole Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objekt Erzeugung innehatte.

Dieser Leitfaden beschreibt keine Einschränkungen für die Verwendung.

Beispiel:

  • "Radiologie"
  • "Modalität"

5.1.1.4 authorSpeciality

Das authorSpeciality Element beschreibt die Fachrichtung der Person, welche das KOS-Objekt verfasst hat.

Beispiel:

  • "Facharzt für Radiologie"
  • "Facharzt für Nuklearmedizin"
5.1.1.4.1 Spezifikation

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

Bsp: Fachärztin/Facharzt für Radiologie

<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>Fachärztin/Facharzt für Radiologie</Value>
        </ValueList>
    </Slot>    
</Classification>

Wenn eine Person als Autor vorhanden ist, MUSS der Wert einem DisplayName aus dem Value Set "ELGA_AuthorSpeciality" entsprechen.

Im Fall von Geräten oder Software als Autor MUSS das Element leer bleiben.

5.1.2 classCode (und classCodeDisplayName)

Das classCode Element klassifiziert (grobe Granularität) das registrierte Objekt und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:

classCode Objektklasse in grober Granularität
typeCode Objektklasse in feiner Granularität.
Siehe Kapitel typeCode

5.1.2.1 Spezifikation

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

Es wird ein fester Wert gesetzt: 55113-5 "Key images Document Radiology" (LOINC: 2.16.840.1.113883.6.1)

$code = "55113-5"
$displayName = "Key images Document Radiology"
$codeSystem = "2.16.840.1.113883.6.1"

<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>

5.1.3 confidentialityCode

Das confidentialityCode Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.

Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf KOS-Objekte ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt, bzw. fix auf "normal" (N) gesetzt.

Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich. Es wird der Vertraulichkeitscode gemäß folgender Spezifikation übernommen:

Zulässige Werte gemäß Value Set "ELGA_Confidentiality" [18].

5.1.3.1 Spezifikation

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

$code = "N"
$displayName = "normal"
$codeSystem = "2.16.840.1.113883.5.25"

<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>

5.1.4 creationTime

Das creationTime Element beschreibt den Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes. Es soll die Zeit angegeben werden, die diese Erstellungszeit am besten beschreibt:

  1. Erstellungsdatum der Studie (aus dem KOS Objekt oder der DICOM Studie):
    • Study Date (0008,0020)
    • Study Time (0008,0030)
  2. Sollte das zuvor genannte Attribut nicht verfügbar sein, muss alternativ das Erstellungsdatum des KOS Objektes verwendet werden:
    • Content Date (0008,0023)
    • Content Time (0008,0033)

Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From UTC[19] berücksichtigt werden, falls angegeben:

  • Timezone Offset From UTC (0008,0201)
  • Es DÜRFEN NUR folgende Datumsformen verwendet werden:
    1. YYYYMMDD
    2. YYYYMMDDhhmmss

5.1.4.1 Spezifikation

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

$date = (0008,0020) Study Date oder (0008,0023) Content Date

$time = (0008,0030) Study Time oder (0008,0033) Content Time und (0008,0201) Timezone Offset from UTC


concat(

$date,

$time

)
<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>20100511134500</Value>
        </ValueList>
    </Slot>
</ExtrinsicObject>

Das Datum MUSS immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher MUSS eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3[12].

5.1.5 eventCodeList (und eventCodeListDisplayName)

Dieses Element enthält eine Liste der erbrachten Gesundheitsdienstleistungen, die das registrierte Dokument oder Objekt beschreibt. Im Fall von Bilddaten findet der APPC Anwendung. (Die korrekte Verwendung von APPC in DICOM Objekten wird im entsprechenden Leitfaden der DICOM Austria spezifiziert: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten"[13]). Es können mehrere APPC bzw. Events (und displayNames) angegeben werden. Sind mehrere Events vorhanden, muss die Reihenfolge der Events und zugehörigen displayNames gleich sein.

5.1.5.1 Spezifikation

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

Für jedes documentationOf Element [1..n]:

$code = APPC code (alle Achsen) z.B. "2.4.0.5-3-3"
$displayName = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule"
$codeSystem = OID des Codesystems APPC: 1.2.40.0.34.5.38

<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>

5.1.6 languageCode

Das languageCode Element beschreibt den Sprachcode in dem ein Dokument oder Objekt verfasst bzw. beschlagwortet ist. Derzeit wird ein fester Wert vorgeschrieben: de-AT

5.1.6.1 Spezifikation

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

Fester Wert "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>

5.1.7 legalAuthenticator

Dieses Element darf für XDS-I nicht verwendet werden [NP].

5.1.8 serviceStartTime / serviceStopTime

Die serviceStartTime/serviceStopTime Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts bzw. der Untersuchung. Für KOS-Objekte kann die serviceStartTime aus dem Objekt gemappt werden:

  1. Das Erstellungsdatum der Studie (aus dem KOS Objekt oder bevorzugt der DICOM Studie):
    • Study Date (0008,0020)
    • Study Time (0008,0030)
  2. Alle Zeiten müssen in XDS in UTC konvertiert werden, daher sollte Timezone Offset From UTC berücksichtigt werden, falls angegeben:
    • Timezone Offset From UTC (0008,0201)

Für die serviceStopTime steht kein Mapping zur Verfügung und wird daher nicht angegeben [NP].

5.1.8.1 Spezifikation

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

concat(

Study Date,

Study Time + Timezone Offset from UTC

)

<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="serviceStartTime">
        <ValueList>
            <Value>20100511134500</Value>
        </ValueList>
    </Slot>
</ExtrinsicObject>

Das Datum MUSS immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher MUSS eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden!

5.1.9 sourcePatientId

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

Für ein Mapping aus KOS steht folgendes Attribut zur Verfügung:

(0010,0020) Patient ID (VR:LO, VM:1)

Eine OID zur Definition des Namensraumes des verwendeten Patientenidentifikators muss entsprechend vorhanden sein.

5.1.9.1 Spezifikation

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

$patientID = (0010,0020) Patient ID

$oid = OID des lokalen Patientenidentifikators


concat(

$patientID,

"^^^&amp;",

$oid,

"&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="sourcePatientId">
        <ValueList>
            <Value>4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO</Value>
        </ValueList>
    </Slot>
</ExtrinsicObject>

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

5.1.10 sourcePatientInfo

Das sourcePatientInfo Element beschreibt die demographischen Daten des Patienten.

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. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.

5.1.11 title

Das title Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

  1. Wenn die Informationen aus der Studie verfügbar sind: Study Description
    • (0008,0060) Modality (Modality Codes aus der DICOM Studie) +
    • (0008,1030) Study Description, Datentyp LO
  2. Wenn mehrere Modality Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
  3. Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. ("CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule")

Achtung: Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".

5.1.11.1 Spezifikation

title wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:

concat(

Modality,

" ",

Study Description

)
<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">
    <Name>
        <LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" />
    </Name>
</ExtrinsicObject>

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

5.1.12 typeCode (und typeCodeDisplayName)

Das typeCode Element beschreibt den Objekttyp, dem das KOS Objekt angehört. Der Objekttyp ist die Spezialisierung einer Objektklasse, jeder Objekttyp gehört zu genau einer Objektklasse.

Unterscheidung typeCode/classCode:

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

5.1.12.1 Spezifikation

typeCode (und typeCodeDisplayName) wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:

Es wird ein fester Wert gesetzt: 55113-5 "Key images Document Radiology"

$code = "55113-5"
$displayName = "Key images Document Radiology"
$codeSystem = "2.16.840.1.113883.6.1"

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

5.1.12.2 submissionSet.contentTypeCode

Der contentTypeCode des Submission Sets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.

$code = "55113-5"

$displayName = "Key images Document Radiology"

$codeSystem = "2.16.840.1.113883.6.1"
<RegistryPackage
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
    <Classification
        classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
        classifiedObject="KeyImageObject"
        nodeRepresentation="$code">
        <Name>
            <LocalizedString value="$displayName"/>
        </Name>
        <Slot name="codingScheme">
            <ValueList>
                <Value>urn:oid:$codeSystem</Value>
            </ValueList>
        </Slot>
    </Classification>
</RegistryPackage>
Jeder Container darf dementsprechend nur 1 Objekt enthalten.

5.1.13 uniqueId

Das uniqueId Element beschreibt den global eindeutigen Identifier des Objektes. Dieser Identifier wird vom Document Source Actor erzeugt.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

(0008,0018) SOP Instance UID (VR:UI, VM:1)

5.1.13.1 Spezifikation

uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:

$value = (0008,0018) SOP Instance UID

<ExternalIdentifier
registryObject="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
value="$value">
    <Name>
        <LocalizedString value="XDSDocumentEntry.uniqueId"/>
    </Name>
</ExternalIdentifier>

5.1.14 referenceIdList

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:

  1. Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId, M [1..1])
  2. Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number, R [0..1])
  3. Verlinkung zwischen DICOM KOS-Objekten und einer Aufenthaltszahl (encounterId, O [0..1])

Weitere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.

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

Dieser Datentyp ist in IHE ITI Data Types in folgender Weise spezifiziert:[12]

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.

5.1.14.1 Versionierung bzw. Versionsklammer (ownDocument_setId)

Um eine eindeutige Identifikation aller registrierten Versionen eines Objektes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Es kann ein beliebiger Identifikator verwendet werden, solange er die Anforderung erfüllt, alle registrierten Versionen eines KOS-Objektes mit derselben ID eindeutig zu kennzeichnen. Als Best Practice für KOS wird die Verwendung von StudyInstanceUID vorgeschlagen.

5.1.14.1.1 Spezifikation

ownDocument-SetId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

Für KOS Objekte kann die StudyInstanceUID (0020,000D) als SetId verwendet werden.

$id = (0020,000D) VR=UI Study Instance UID, z.B. 1.2.40.0.34.99.111.1.1

$homeCommunityId = OID des lokalen ELGA-Bereiches. Diese MUSS [1..1], unabhängig vom für $id gewählten Identifier, angeführt sein, z.B. 1.2.40.0.34.99.999


concat

(

$id, "^^^^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

"&amp;",

$homeCommunityId, "&amp;ISO"

)


Wie oben angeführt wird folgender CXi Wert für <Value> erstellt:

 <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="urn:ihe:iti:xds:2013:referenceIdList">
         <ValueList>         
             <Value>1.2.40.0.34.99.111.1.1^^^^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO</Value>
         </ValueList>
     </Slot>
 </ExtrinsicObject>

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

5.1.14.2 Referenz zwischen Dokument und Studie (Accession Number)

Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (acquisition, store) als auch bei der Befundschreibung (report) verfügbar ist. Dies trifft auf die Accession Number zu (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).

5.1.14.2.1 Spezifikation

Bei der Registrierung von KOS Objekten SOLL eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden. Diese dient als Basis für die Verlinkung mit einem Befund der bildgebenden Diagnostik (diagnostic image report). Wird in der ReferenceIdList der XDS-I Metadaten keine Accession Number angeführt, ist eine Verlinkung nicht möglich. Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).

Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:


$id = Accession Number z.B. 20201111

$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"urn:ihe:iti:xds:2013:accession"

)
 <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="urn:ihe:iti:xds:2013:referenceIdList">
         <ValueList>         
             <Value>20201111^^^&amp;1.2.40.0.34.99.999&amp;ISO^urn:ihe:iti:xds:2013:accession</Value>
         </ValueList>
     </Slot>
 </ExtrinsicObject>
Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"

5.1.14.3 Referenz zwischen Aufenthaltszahl und Studie (encounterId)

Durch encounterId wird die Verlinkung sämtlicher Bilddaten (DICOM KOS-Objekte), die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-I Metadaten unterstützt. Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird.

5.1.14.3.1 Spezifikation

Bei der Registrierung von KOS Objekten KANN eine encounterId in den XDS-I Metadaten in der ReferenceIdList angegeben werden.

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


$id = Aufenthaltszahl z.B. Az123456

$root = OID der Liste der Aufenthaltszahlen der Organisation, z.B. 1.2.40.0.34.99.4613.3.4

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"urn:ihe:iti:xds:2015:encounterId"

)
 <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="urn:ihe:iti:xds:2013:referenceIdList">
         <ValueList>         
             <Value>Az123456^^^&amp;1.2.40.0.34.99.4613.3.4&amp;ISO^urn:ihe:iti:xds:2015:encounterId
             </Value>
         </ValueList>
     </Slot>
 </ExtrinsicObject>

5.1.14.4 Weitere Einträge der referenceIDList

Über die bereits genannten Einträge hinaus sind weitere Einträge in der referenceIdList erlaubt:

  • Study Instance UID mit dem Datentyp: urn:ihe:iti:xds:2016:studyInstanceUid. In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.
  • UniqueID mit dem Datentyp: urn:ihe:iti:xds:2013:uniqueId
Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:
 <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="urn:ihe:iti:xds:2013:referenceIdList">
         <ValueList>               
             <Value>1.2.40.0.34.99.111.1.1^^^^urn:elga:iti:xds:2014:ownDocument_setId
^amp;1.2.40.0.34.99.999&amp;ISO</Value>
             <Value>20201111^^^amp;1.2.40.0.34.99.999&amp;ISO^urn:ihe:iti:xds:2013:accession</Value>
             <Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value>
             <Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>
         </ValueList>
     </Slot>
 </ExtrinsicObject>

5.1.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 der Registrierung von KOS Objekten via XDS-I.

5.1.16 comments

Das comments Element enthält Kommentare zum Objekt. Die Verwendung ist in ELGA optional (wird in einigen Implementierungen nicht angezeigt, z.B. ELGA Bürgerportal)

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten: (0008,1030) Study Description (VR:LO, VM:1)

5.1.16.1 Spezifikation

Comments wird gemäß folgender Vorschrift zusammengesetzt:

$comment = (0008,1030) Study Description
<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">
    <Description">
        <LocalizedString value = "$comment"/>
    </Description>
</ExtrinsicObject>

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

5.2.1 availabilityStatus

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

Mögliche Werte laut IHE sind:

  • Approved
  • Deprecated

Dieses Attribut wird im Zuge des Einbringens von neuen Objekten ("Submission") durch die empfangende XDS Registry immer auf "Approved" gesetzt.

availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.

<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"/>

5.2.2 formatCode (und formatCodeDisplayName)

Das formatCode Element beschreibt das Format des registrierten Objekts. Es ermöglicht einem empfangenden System (Document Consumer Actor) die Identifizierung des für die Weiterverarbeitung zu erwartenden Objektformats und somit die korrekte Darstellung und Verarbeitung.

5.2.2.1 Spezifikation

formatCode (und formatCodeDisplayName) wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:


$code = "1.2.840.10008.5.1.4.1.1.88.59"
$displayName = "Key Object Selection Document"
$codeSystem = "1.2.840.10008.2.6.1"

<Classification
    classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
    nodeRepresentation="$code">
    <Name>
        <LocalizedString value="$displayName"/>
    </Name>
    <Slot name="codingScheme">
        <ValueList>
            <Value>urn:oid:$codeSystem</Value>
        </ValueList>
    </Slot>
</Classification>

5.2.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)

Das healthcareFacilityTypeCode Element beschreibt die Klassifizierung des GDA, z.B.

  • 158 "Fachärztin/Facharzt"
  • 300 "Allgemeine Krankenanstalt"

Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).

Zulässige Werte gemäß Value Set "ELGA_ HealthcareFacilityTypeCode".

5.2.3.1 Spezifikation

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

$code = Klassifizierung des GDA (Code)

$displayName = Klartext des angegebenen Codes

$codeSystem = OID der ausgebenden Stelle

<Classification
    classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
    nodeRepresentation="$code">
    <Name>
        <LocalizedString value="$displayName"/>
    </Name>
    <Slot name="codingScheme">
        <ValueList>
            <Value>urn:oid:$codeSystem</Value>
        </ValueList>
    </Slot>
</Classification>

5.2.4 mimeType

Das mimeType Element beschreibt den "Internet Media Type" des Objektes gemäß dem "Multipurpose Internet Mail Extensions" (MIME) Standard. Der Standard wird beschrieben in RFC 2045[20] und RFC 2049[21].

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

5.2.4.1 Spezifikation

mimeType wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, welches das DocumentEntry repräsentiert.

Folgende Mime-Types sind für DICOM KOS Objekte zugelassen:

  • application/dicom
<ExtrinsicObject
            id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
            mimeType="application/dicom"
            objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
            status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>

5.2.5 practiceSettingCode (und practiceSettingCodeDisplayName)

Das practiceSettingCode Element beschreibt die fachliche Zuordnung des Objektes. Es soll den Fachbereich wiedergeben, dem der Inhalt des Objektes am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung, z.B.:

  • F044 "Radiologie"
  • F052 "Unfallchirurgie"

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

Zulässige Werte gemäß Value Set "ELGA_PracticeSetting_VS".

5.2.5.1 Spezifikation

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

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

<Classification
    classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
    nodeRepresentation="$code">
    <Name>
        <LocalizedString value="$displayName"/>
    </Name>
    <Slot name="codingScheme">
        <ValueList>
            <Value>urn:oid:$codeSystem</Value>
        </ValueList>
    </Slot>
</Classification>

5.2.6 objectType

Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "stabiles Dokument" (stable document, SD) und "On-demand Dokument" (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.

Für KOS Objekte wird der fixe Wert "urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" für "Stable Document" vorgegeben:

<ExtrinsicObject mimeType="application/dicom"
    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"/>

5.3 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.

5.3.1 elgaFlag

Das elgaFlag dient zur Kennzeichnung eines Objektes als "ELGA-Objekt"18. 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"

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

5.3.1.1 Spezifikation

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

5.3.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.

5.3.2.1 Spezifikation

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

6 XDS Metadaten für CDA Dokumente

Die folgenden Kapitel spezifizieren die XDS-Metadaten von HL7 CDA-Dokumenten für deren Verwendung in ELGA. Nicht angegebene Metadaten sind nicht weiter eingeschränkt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol. 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.[12]

6.1 XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet

6.1.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.

6.1.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 einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag "descriptor" 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"
      Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.
  3. GDA, in deren Gültigkeitsbereich Dokumente erstellt werden können, sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
  4. Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.

Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da es vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante Kurzbezeichnung zu verwenden.

6.1.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,"&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="authorInstitution">
        <ValueList>
            <Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;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&amp;ISO^^^^45</Value>
        </ValueList>
    </Slot>    
</Classification>

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

6.1.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).

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

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

6.1.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 [R].
  3. Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.
6.1.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.

6.1.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 [R].
  3. Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.
6.1.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.

6.1.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 typeCode

6.1.2.1 Spezifikation

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

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

<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>

6.1.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:

6.1.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>

6.1.4 creationTime

Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden. Dieses Datum kann für die chronologische Sortierung der Befunde bei der Anzeige der Dokumentenliste verwendet werden.

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

  1. Im CDA wird dieser Zeitpunkt wie folgt abgelegt:
    ClinicalDocument/effectiveTime
  2. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe verpflichtend.
  3. Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert.
  4. Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:
    @value … enthält das Datum in folgenden möglichen Formen
    1. YYYYMMDD
    2. YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
      Bsp: 20081224082015+0100
      Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
  5. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.


CreationTime entfällt bei On-Demand Documenten.

Das Aktualisierungsdatum von Dokumenten (Update-Datum) kann über submissionTime (in XDS.submissionSet) erkannt werden.

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

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).

6.1.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 ServiceEvents wie folgt abgelegt:
    1. ClinicalDocument/documentationOf/serviceEvent
  2. Mehrere dieser ServiceEvents können durch beliebig viele "documentationOf" Elemente ausgedrückt werden.
  3. Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines ServiceEvents verpflichtend, wenn bekannt [R].
  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 ServiceEvent eine Gesundheitsdienstleistung angegeben werden muss und welche Bedeutung dieses Element hat.

6.1.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>

6.1.5.2 Spezielle Vorschriften laut IHE PCC

Das IHE Patient Care Coordination (PCC) Technical Framework vol. 2[14] definiert in Kapitel "Medical Document Binding" Spezialbehandlungen für gewisse Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC).

Diese speziellen Vorschriften werden in ELGA nicht angewandt.

6.1.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:

6.1.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>

6.1.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

ACHTUNG: Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste Element (ClinicalDocument/LegalAuthenticator[1]) übernommen werden.


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 direkt 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

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

6.1.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 [R].

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 ServiceEvent 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

Es soll jeweils das erste serviceEvent für das Mapping verwendet werden.

6.1.8.1 Spezifikation

serviceStartTime wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@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="serviceStartTime">
        <ValueList>
            <Value>20200511173000</Value>
        </ValueList>
    </Slot>
</ExtrinsicObject>

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. 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).

serviceStopTime wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value = "20200516133000+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="serviceStopTime">
        <ValueList>
            <Value>20200516113000</Value>
        </ValueList>
    </Slot>
</ExtrinsicObject>

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. 20200516133000+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 20200516113000).

6.1.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] … ID des Patienten vom einbringenden (lokalen) System
    2. id[2] … Österreichische Sozialversicherungsnummer (nur wenn bekannt)
      Achtung: Diese ID gelangt nicht in die Metadaten!

6.1.9.1 Spezifikation

sourcePatientId wird gemäß folgender Vorschrift zusammengesetzt:

concat(

ClinicalDocument/recordTarget/patientRole/id[1]/@extension,

"^^^&amp;",

ClinicalDocument/recordTarget/patientRole/id[1]/@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="sourcePatientId">
        <ValueList>
<Value>4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO</Value>
        </ValueList>
    </Slot>
</ExtrinsicObject>

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

Ein spezieller Leitfaden kann eine abweichende Mapping-Vorschrift definieren!

6.1.10 sourcePatientInfo

Das sourcePatientInfo Element beschreibt die demographischen Daten des Patienten.

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. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.

6.1.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

6.1.11.1 Spezifikation

title wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/title

<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">
    <Name>
        <LocalizedString charset="UTF-8" value="Entlassungsbrief der chirurgischen Abteilung" xml:lang="de-AT" />
    </Name>
</ExtrinsicObject>

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

6.1.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.

6.1.12.1 Spezifikation

typeCode (und typeCodeDisplayName) wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:

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

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

6.1.12.2 submissionSet.contentTypeCode

Der contentTypeCode des Submission Sets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.

$code = ClinicalDocument/code/@code

$displayName = ClinicalDocument/code/@displayName

$codeSystem = ClinicalDocument/code/@codeSystem

<RegistryPackage
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
    <Classification
        classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
        classifiedObject="theDocument"
        nodeRepresentation="$code">
        <Name>
            <LocalizedString value="$displayName"/>
        </Name>
        <Slot name="codingScheme">
            <ValueList>
                <Value>urn:oid:$codeSystem</Value>
            </ValueList>
        </Slot>
    </Classification>
</RegistryPackage>

6.1.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

6.1.13.1 Spezifikation

uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:

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

$value = concat(ClinicalDocument/id/@root)

Fall 2
Attribut ClinicalDocument/id/@extension ist vorhanden

$value = concat( ClinicalDocument/id/@root, "^", ClinicalDocument/id/@extension )

<ExternalIdentifier
registryObject="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
value="$value">
    <Name>
        <LocalizedString value="XDSDocumentEntry.uniqueId"/>
    </Name>
</ExternalIdentifier>

6.1.14 referenceIdList

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE ITI TF-3[12] (27 September 2013) Dokument neu hinzugekommen. Für CDA-Befunde sind drei unterschiedliche Einträge in referenceIdList vorgesehen:

  1. eindeutige Identifikation aller Dokumente eines Dokumentenstammes, d.h. vorhergehende und auch zukünftige Versionen (ownDocument_setId, M [1..1])
  2. Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number, O [0..1])
  3. Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).


Im Rahmen von ELGA MUSS die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten strukturiert sein.


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

Dieser Datentyp ist in IHE ITI TF-3[12] 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.

6.1.14.1 Versionierung bzw. Versionsklammer (ownDocument_setId)

Um eine eindeutige Identifikation aller registrierten Versionen eines CDA R2 Dokumentes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Es kann ein beliebiger Identifikator verwendet werden, solange er die Anforderung erfüllt, alle registrierten Versionen eines CDA R2 Dokuments mit derselben ID eindeutig zu kennzeichnen. Für ELGA wird dazu ownDocument_setId definiert, die auf dem CDA Header-Element "setId" basiert.

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:
    • ClinicalDocument/setId [M]
6.1.14.1.1 Spezifikation

ownDocument-SetId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat

(

ClinicalDocument/setId/@extension, "^^^", "&amp;",

ClinicalDocument/setId/@root, "&amp;ISO", "^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^", "&amp;",

homeCommunityId, "&amp;ISO"

)

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


Beispiel 1: setId/@root und setId/@extension sind im CDA strukturiert. In /@extension wird KEINE UUID angegeben.

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

Wie oben angeführt wird folgender CXi Wert erstellt:

 <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="urn:ihe:iti:xds:2013:referenceIdList">
         <ValueList>         <Value>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</Value>
         </ValueList>
     </Slot>
 </ExtrinsicObject>

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


Beispiel 2: in setId/@extension im CDA wird eine UUID geführt

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

Wie oben angeführt wird folgender CXi Wert erstellt:

"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"

<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="urn:ihe:iti:xds:2013:referenceIdList">
         <ValueList>
             <Value>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</Value>
         </ValueList>
     </Slot>
 </ExtrinsicObject>

6.1.14.2 Referenz zwischen Dokument und Studie (Accession Number)

Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (acquisition, store) als auch bei der Befundschreibung (report) verfügbar ist. Dies trifft auf die Accession Number zu (bzw. ein vergleichbares Element, das im implementierten Workflow zur Verknüpfung von Studie und Befund verwendet wird).

6.1.14.2.1 Spezifikation

Für Befunde der bildgebenden Diagnostik (diagnostic image report) KANN als Accession Number jene aus der ReferenceIdList der XDS-I Metadaten des KOS Objektes, mit dem eine Verlinkung hergestellt werden soll, genutzt werden. Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).

Accession Number wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:


$id = Accession Number z.B. 20201111

$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"urn:ihe:iti:xds:2013:accession"

)
 <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="urn:ihe:iti:xds:2013:referenceIdList">
         <ValueList>         
             <Value>20201111^^^&amp;1.2.40.0.34.99.999&amp;ISO^urn:ihe:iti:xds:2013:accession</Value>
         </ValueList>
     </Slot>
 </ExtrinsicObject>
Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"


6.1.14.3 Verlinkung via Aufenthaltszahl (encounterId)

Durch encounterId wird die Verlinkung sämtlicher Befunde oder Bilddaten (siehe Kapitel referenceIdList für Dicom KOS-Objekte), die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-Metadaten unterstützt. Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-/XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird.


6.1.14.3.1 Spezifikation

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

concat

(

ClinicalDocument/componentOf/encompassingEncounter/id/@extension, "^^^", "&amp;",

ClinicalDocument/componentOf/encompassingEncounter/id/@root, "&amp;ISO", "^",

"urn:ihe:iti:xds:2015:encounterId"

)

Bitte beachten Sie, dass die ClinicalDocument/componentOf/encompassingEncounter/id/@root

in der Schreibweise "&", OID-Wert, "&ISO" anzugeben ist.

Wie oben angeführt wird folgender CXi Wert erstellt:
 <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="urn:ihe:iti:xds:2013:referenceIdList">
         <ValueList>
            <Value>Az123456^^^&amp;1.2.40.0.34.99.4613.3.4&amp;ISO^urn:ihe:iti:xds:2015:encounterId
            </Value>
         </ValueList>
     </Slot>
 </ExtrinsicObject>



6.1.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.

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

6.2.1 availabilityStatus

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

Mögliche Werte laut IHE sind:

  • Approved
  • Deprecated

Dieses Attribut wird im Zuge des Einbringens von neuen Dokumenten ("Submission") durch die empfangende XDS Registry immer auf "Approved" gesetzt.

availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.

<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"/>

6.2.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 wurde für die HL7-Austria Domäne ein genau entsprechendes Element geschaffen, "hl7at:formatCode".

6.2.2.1 Spezifikation

formatCode (und formatCodeDisplayName) wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
$code = ClinicalDocument/hl7at:formatCode/@code
$displayName = ClinicalDocument/hl7at:formatCode/@displayName
$codeSystem = ClinicalDocument/hl7at:formatCode/@codeSystem

<Classification
    classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
    nodeRepresentation="$code">
    <Name>
        <LocalizedString value="$displayName"/>
    </Name>
    <Slot name="codingScheme">
        <ValueList>
            <Value>urn:oid:$codeSystem</Value>
        </ValueList>
    </Slot>
</Classification>

6.2.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)

Das healthcareFacilityTypeCode Element beschreibt die Klassifizierung des GDA. Es wird der Code aus dem CDA Header Element "healthCareFacility" genutzt.

6.2.3.1 Spezifikation

healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName) wird als ebRIM Classification 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

<Classification
    classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
    nodeRepresentation="$code">
    <Name>
        <LocalizedString value="$displayName"/>
    </Name>
    <Slot name="codingScheme">
        <ValueList>
            <Value>urn:oid:$codeSystem</Value>
        </ValueList>
    </Slot>
</Classification>

6.2.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.[20] [22] [23] [24] [21]

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

6.2.4.1 Spezifikation

mimeType wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, welches das DocumentEntry repräsentiert.

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

<ExtrinsicObject
            id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
            mimeType="text/xml"
            objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
            status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>

6.2.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

6.2.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

6.2.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 wurde für die HL7-Austria Domäne ein entsprechendes Element in den CDAs geschaffen, "hl7at:practiceSettingCode".

6.2.6.1 Spezifikation

practiceSettingCode (und practiceSettingCodeDisplayName) wird als ebRIM Classificationgemäß folgender Vorschrift zusammengesetzt:

$code = ClinicalDocument/hl7at:practiceSettingCode/@code
$displayName = ClinicalDocument/hl7at:practiceSettingCode/@displayName
$codeSystem = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem

<Classification
    classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
    classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
    id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
    nodeRepresentation="$code">
    <Name>
        <LocalizedString value="$displayName"/>
    </Name>
    <Slot name="codingScheme">
        <ValueList>
            <Value>urn:oid:$codeSystem</Value>
        </ValueList>
    </Slot>
</Classification>

6.2.7 objectType

Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "stabiles Dokument" (stable document, SD) und "On-demand Dokument" (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.

Für "Stable Document" DocumentEntry:

<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"/>

Für "On-Demand Document" DocumentEntry:

<ExtrinsicObject mimeType="text/xml"
    objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
    status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
    id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>

6.3 ELGA-spezifische Erweiterungen der XDS-Metadaten

Die folgenden Daten erweitern den IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt.

6.3.1 elgaFlag

Das elgaFlag dient zur Kennzeichnung eines Dokuments als "ELGA-Dokument"18. 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"

18 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.

6.3.1.1 Spezifikation

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

6.3.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.

6.3.2.1 Spezifikation

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


7 Anhänge

7.1 Einzelnachweise

  1. Gesundheitstelematikgesetz 2012 https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20008120
  2. 2,0 2,1 2,2 IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing https://www.ihe.net/resources/technical_frameworks/#iti
  3. 3,0 3,1 HL7 Standards: Clinical Document Architecture HL7 CDA
  4. NEMA PS3 / ISO 12052, Digital Imaging and Communications in Medicine (DICOM®) Standard, National Electrical Manufacturers Association, Rosslyn, VA, USA. Unter ständiger Weiterentwicklung, die aktuelle Version ist frei verfügbar auf http://dicom.nema.org/).
  5. IHE Principles of Governance
  6. Integrating the Healthcare Enterprise (IHE) International, Incorporated http://www.ihe.net
  7. Health Level Seven International www.hl7.org
  8. ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical Document Architecture, Release 2 https://www.iso.org/standard/44429.html
  9. 9,0 9,1 9,2 Allgemeiner Implementierungsleitfaden für CDA Dokumente https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_(Version_3)
  10. HL7 Austria www.hl7.at
  11. ELGA-Gesamtarchitektur 2.30a http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/
  12. 12,00 12,01 12,02 12,03 12,04 12,05 12,06 12,07 12,08 12,09 12,10 12,11 12,12 12,13 12,14 12,15 12,16 12,17 12,18 IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 12.0 (2016) https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf, zuletzt besucht am 25.01.2021
  13. 13,0 13,1 13,2 DICOM Austria: Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch DICOM Austria KOS Leitfaden, zuletzt besucht am 19.02.2021
  14. 14,0 14,1 IHE "Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2 https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf
  15. 15,0 15,1 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Datenhttps://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten
  16. DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1
  17. IHE Radiology (RAD) Technical Framework Volume 2x Rev.19, 2020 https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf
  18. Value Set "ELGA_Confidentiality" https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality
  19. Timezone Offset From UTC http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8
  20. 20,0 20,1 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies IETF RFC 2045
  21. 21,0 21,1 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples IETF RFC 2049
  22. Multipurpose Internet Mail Extensions (MIME) Part Part Two: Media Types IETF RFC 2046
  23. Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text IETF RFC 2047
  24. Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures IETF RFC 2048

7.2 Literatur und Weblinks

7.3 Revisionsliste

7.3.1 Hauptversion 3.0.0 (2021)

Diese Hauptversion wurde auf Basis der neuen Vorgaben aus dem Allgemeinen Implementierungsleitfaden 3.0.0 grundlegend überarbeitet und umstrukturiert. Hinzugekommen sind die Vorgaben für die Registrierung von DICOM KOS-Objekten. Auf eine Revisionsliste mit direktem Vergleich zur Vorversion wurde daher verzichtet. Die relevanten Änderungen sind:

Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;"
"referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
"Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
"Spezifikation": Verbot von CR und LF hinzugefügt.
"Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
"sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
"legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
"creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
"healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
"formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
"Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
"XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.
"referenceIdList": Ergänzung der Verwendung der encounterId

7.3.2 Hauptversion 2.06

Eine Liste vorherigen Revisionen findet sich auf der Diskussionsseite.

7.4 Erratum

Weitere Probleme und allfällige Korrekturen werden auf der Diskussionsseite im Wiki gesammelt.