Änderungen

|title=XDS Metadaten 20203.0.1

{{#customtitle:XDS -Metadaten 2020}}{{Underconstruction(Version 3.0.1+20211001)}}

{{Underconstruction}} --><!-- Implementierungsleitfaden "XDS -Metadaten 2020(Version 3)"

|Group = ELGA CDA<br/>ImplementierungsleitfädenImplementierungsleitfaden XDS-Metadaten (XDSDocumentEntry)|Title = Leitfaden zur Registrierung von CDA Dokumenten für ELGA mit IHE Cross-Enterprise Document Sharing: <br/>XDS Metadaten in ELGA (XDSDocumentEntryVersion 3)|Subtitle = Zur Anwendung im österreichischen<br/>Gesundheitswesen [1.2.40.0.34.7.16.69.23]|Short = XDS -Metadaten

|Version = 23.060.21+20211001|Submitted = HL7 AustriaELGA GmbH|Date = 2001. März 201710.2021|Copyright = 20172011-2021|Status = EntwurfNormativ

|OID = n1.n2.40.0.34.7.6.9.3|Realm = ÖsterreichAustria

{{Contributor | Logo = Logo.jpg | Name = Abc | Location = Hürth Wien}}

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">== Allgemeines Impressum==Ziel dieses Implementierungsleitfadens <div class="mw-collapsible-content">''Medieneigentümer, Herausgeber, Hersteller, Verleger:''<br />ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050<br />Internet: [http://www.elga.gv.at www.elga.gv.at]Email: [mailto:cda@elga.gv.at cda@elga.gv.at]<br />Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch ''Redaktion, Projektleitung, Koordination: ''<br />Mag.Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at 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 [http://www.hl7.at www.hl7.at].<br />Die Nutzung ist die Beschreibung von Struktur, Format ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente ausdrücklich erlaubt. Andere Arten der Nutzung und Standards von medizinischen Dokumenten auch auszugsweise Wiedergabe bedürfen der Elektronischen Gesundheitsakte Genehmigung des Medieneigentümers. Download unter [https://www.gesundheit.gv.at www.gesundheit.gv.at] und [https://www.elga.gv.at/cda www.elga.gv.at/cda]</div></div> <div class="toccolours mw-collapsible mw-collapsed" overflow:auto;"ELGA> ==Haftungsausschluss==<div class="mw-collapsible-content" >Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012)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, aber auch für medizinische Dokumente im österreichischen GesundheitswesenHerausgeber 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.</div><br/div>

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<div class="toccolours mw- und Kuranstaltengesetz, Gesundheitscollapsible mw- 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.<br/collapsed" overflow:auto;">

<div class="mw-collapsible-content">Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer , Frauen und Frauen 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.</div></div>

== Verbindlichkeit Lizenzinformationen=='''Review notwendig'''Mit der ELGA-Verordnung 2015 (in der Fassung der ELGA-VO-Nov-2015) macht die Bundesministerin Die Verwendung dieses Leitfadens für Gesundheit und Frauen die Festlegungen für InhaltZwecke der Erstellung, Struktur, Format des Verkaufs und Codierung verbindlichdes Betriebs von Computerprogrammen, die in den Implementierungsleitfäden Entlassungsbrief Ärztlich, Entlassungsbrief Pflege, Pflegesituationsbericht, Laborbefunde, Befund bildgebender Diagnostik, e-Medikation sowie XDS Metadaten (jeweils in der Version 2.06) getroffen wurden. Die anzuwendende ELGA-Interoperabilitätsstufen ergeben sofern nicht anders angegeben oder sich aus §21 Abs.6 ELGA-VO. Die Leitfäden in ihrer jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind von der Gesundheitsministerin Standards auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Dokumente für ELGA wird durch das Gesundheitstelematikgesetz 2012 (GTelG 2012) und darauf basierenden Durchführungsverordnungen durch die Bundesministerin für Gesundheit und Frauen vorgegebenandere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen, ist ausdrücklich genehmigt.<br />

Die Verbindlichkeit Lizenzinformationen und die Umsetzungsfrist dieses Leitfadens ist im Gesundheitstelematikgesetz 2012, BGBlRichtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.I Nrihe.111net/2012 sowie in den darauf fußenden ELGAwp-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")===<div style="border: thin #77c123 solid;width:100%; margin-left: 10px"> <div style="line-Verordnungen geregeltheight: 1.25; font-size:16px; border-bottom: 1px solid #81ab1f; box-shadow: 0 4px 0 0 #a2d727;margin-bottom:4px; color:#77c123; width:100%"> <p style="padding: 10px 15px;font-size:18px;">Third Party Intellectual Property</p> </div> <div style="width:100%;"> <p style="padding: 15px;">

Neue Hauptversionen Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass der Implementierungsleitfäden KÖNNEN ab dem Tag ihrer Veröffentlichung durch Herausgeber nicht alle Rechte und Ansprüche in und an den Materialien besitzt und dass die Bundesministerin für Gesundheit Materialien geistiges Eigentum von Dritten enthalten und Frauen / oder darauf verweisen können (www.gesundheit.gv.at"Third Party Intellectual Property (IP) verwendet werden, spätestens 18 Monate nach ihrer Veröffentlichung MÜSSEN sie verwendet werden. Andere Aktualisierungen (Nebenversionen") dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.<br />

Die Einhaltung der gesetzlichen Bestimmungen liegt 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 Verantwortungsbereich der Ersteller der CDA-DokumenteZusammenhang mit den Materialien oder anderweitig verantwortlich.<br />

== Zielgruppe ==Anwender dieses Dokuments sind Softwareentwickler und BeraterJegliche Handlungen, Ansprüche oder Klagen eines Dritten, die allgemein mit Implementierungen und Integrationen im Umfeld der ELGA, insbesondere der ELGAsich aus einer Verletzung eines Third Party IP-GesundheitsdatenRechts durch den Lizenznehmer ergeben, betraut sindbleiben die Haftung des Lizenznehmers.Eine weitere Zielgruppe sind alle an der Erstellung von CDA-Dokumenten beteiligten Personen, einschließlich der Endbenutzer der medizinischen Softwaresysteme und der Angehörigen von Gesundheitsberufen.</p> </div></div>

== Hinweis auf verwendete Grundlagen Verbindlichkeit==Der vorliegende Leitfaden wurde unter Verwendung der nachstehend beschriebenen Dokumente erstelltDie Verbindlichkeit und die Umsetzungsfrist von Leitfäden sind im Gesundheitstelematikgesetz 2012, BGBl. Das Urheberrecht an allen genannten Dokumenten wird im vollen Umfang respektiertI Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.

Dieser Standard beruht 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 Spezifikation 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 ("HL7 Clinical Document ArchitectureMandatory" [M], Release 2.0"Required" [R] und "Fixed" [F]), für die das Copyright &copy; von Health Level Seven International giltsind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. HL7 Standards können über die HL7 Anwendergruppe Österreich Andere Aktualisierungen (HL7 AustriaNebenversionen), die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden (dürfen auch ohne Änderung dieser Verordnung unter www.hl7gesundheit.gv.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 veröffentlicht werden.

Die Vorgaben für das Österreichische Patient Summary wurden weitgehend aus dem HL7 Leitfaden für das Internationale Patient Summary entlehnt Anwendung dieses Implementierungsleitfadens hat im Einklang mit österreichischem und europäischem Recht, insbesondere mit den relevanten Materiengesetzen ([http://internationalz.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten-patientund Kuranstaltengesetz, Gesundheits-summaryund Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz, Gesundheitstelematikgesetz 2012, DSGVO) zu erfolgen.net HL7 IPS])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.

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

==DanksagungVerwendete Grundlagen und Bezug zu anderen Standards==Die ELGA GmbH weist auf das Dokument „Arztbrief auf Basis Grundlage dieses Implementierungsleitfadens ist der HL7 Clinical internationale Standard IHE ITI Cross-enterprise Document Architecture Release 2.0 für das deutsche Gesundheitswesen“ hin, welches vom Verband der Hersteller Sharing <ref name="IHE ITI"></ref> von IT-Lösungen für das Gesundheitswesen Integrating the Healthcare Enterprise (IHE)<ref name="IHE">Integrating the Healthcare Enterprise (VHitGIHE) herausgegeben wurdeInternational, Incorporated [http://www. Einige Ausführungen in dem genannten Dokument wurden in das vorliegende Dokument übernommenihe. Das Urheberrecht an dem Dokument „Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2net http://www.ihe.0 für das deutsche Gesundheitswesen“, wird im vollen Umfang respektiertnet]</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 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 [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. 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}}Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Hinweise zur Nutzung Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens Version 3]''' und gilt entsprechend für alle CDA-Dokumente, die auf Basis des Leitfadenserstellt werden.{{EndILFBox}}

==RevisionslisteWichtige unterstützende Materialien==Diese Version ist eine Nebenversion zur Hauptversion 2.06 und ersetzt diese. Die durchgeführten Änderungen ersehen Sie {{BeginYellowBox}}Auf der Website: [[ILF:Befund bildgebende Diagnostik#Revisionsliste_2XDS_Metadaten_Guide|RevisionslisteXDS Metadaten Guide]]werden unter anderem folgende Materialien zur Verfügung gestellt:* die PDF-Version dieses Leitfadens{{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:

*ELGA-Gesamtarchitektur<ref name==Weitere unterstützende Materialien==Gemeinsam mit diesem Leitfaden werden auf der Website der "ELGA-Gesamtarchitektur">ELGA GmbH -Gesamtarchitektur 2.30a [http://www.elga.gv.at/cdatechnischer-hintergrund/technischer-aufbau-im-ueberblick/ http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/] weitere Dateien und Dokumente zur Unterstützung bereitgestellt: </ref>*Beispieldokumente, zu verwendende Codes, Vorgaben zur Registrierung von CDA-Dokumenten, das *Referenz-Stylesheet (Tool zur Darstellung von CDAim Browser - Konvertierung in HTML)*CDA2PDF Suite (Tool zur Erzeugung einer PDF-Dokumenten, Algorithmen 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 etc(Leitfaden für XDS-Metadaten)*Hinweise für die zu verwendenden 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}}

Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an cda@elga.gv.at[mailto'''<Hinweis>'''<br/>authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter http://www.elga.gv.at/CDA.

* Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts* Seitenweise blättern: <div class="Bildtoccolours mw-collapsible mw-collapsed" Tasten* Scrollenoverflow: Pfeil nach oben bzw. unten* Zoomen: Strg + Mouserad drehen* Suchen im Dokument: Strg + Fauto;">

==Impressum=PDF-Navigation===''Medieneigentümer, Herausgeber, Hersteller, Verleger:''<br /div class="mw-collapsible-content">ELGA GmbHNutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), Treustraße 35um direkt in der PDF-43, Wien, Österreich. Telefon: 01. 2127050. Internet: http://www.elga.gv.at. Email: [mailto:cda@elga.gv.at cda@elgaVersion dieses Dokuments zu navigieren.gv.at]. <br />GeschäftsführerFolgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern: DI Dr. Günter Rauchegger, DI (FH) Dr. Franz Leisch

''Redaktion, Projektleitung, Koordination*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</div><br /div>Mag. Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]

'''Erarbeitung des Implementierungsleitfadens'''<br/>

{| class="wikitable" |- ! colspan="2" style="text-align:left" |Autoren|- ! style="text-align:left" width="6510%" |Organisation|| style="text-align:left" width="60%" |Person¹|- 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

! style="text|ELGA GmbH||Oliver Kuttin|-align:left" colspan="3"|ELGA GmbH| AutorenStefan Repas

! style="text-align:left" width="10%" | Kürzel ||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person¹|- 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|| Fachhochschule Technikum Wien || Stefan Sauermann|- 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

¹ Personen Namen ohne Titel<!--Einleitung-->

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

Für Eine IHE XDS Registry verwaltet Dokumente und macht diese zugänglich. Sie erlaubt die Registrierung von Bilddaten Suche und das Filtern nach den Dokumenten über XDS-I wird eine eigene Spezifikation veröffentlichtdie 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.

Dieses Dokument definiert die Metadaten² beim Einbringen von CDA-Dokumentenin Form von Befunden<supref name="ALF">3</supref> oder Bilddaten in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<supref name="IHE ITI">4</supref>. Die hier definierten Regeln sind von den folgenden „Technical Frameworks“ "Technical Frameworks" der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten Dokumente (Metadaten der XDSDocumentEntry Objekte)** : ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 1012.0 (2722.94.20132016) Final Text''* Darüber hinaus gehende Spezifikation speziell für CDA Dokumente** ''Patient Care Coordination <ref name="ITITF3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 12.0 (PCC2016)[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], Volume 2''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>, 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.

Eine weitere Profilierung des XDS SubmissionSets gegenüber dem XDS Standard wird Etwaige, Service-spezifische, Vorgaben auf Schnittstellen-Ebene sind in ELGA nicht vorgenommen. Die vorliegende Spezifikation wurde im Zusammenhang mit den „ELGA CDA Implementierungsleitfäden“ erstellt. Zum Zeitpunkt der Erstellung liegen folgende Implementierungsleitfäden vor:* ELGA CDA Implementierungsleitfäden (HL7 Implementation Guide for CDA® R2):** „[[ILF:Allgemeiner Implementierungsleitfaden|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente]] [1]** „[[ILF:Entlassungsbrief (Ärztlich)|Entlassungsbrief entsprechenden Schnittstellenspezifikationen (Ärztlich)]]“ [2]** „[[ILF:Entlassungsbrief (Pflege)|Pflegerischer Entlassungsbrief]]“ [3]** „[[ILF:Laborbefund|Laborbefund]]“ [4]** „[[ILF:Befund bildgebende Diagnostik|Befund bildgebende Diagnostik]]“ [5]** „[[ILF:E-Medikation|e-Medikation]]“ [6]** „[[ILF:Pflegesituationsbericht|Pflegesituationsbericht]]“ [7]   ² Daten, die andere Daten definieren und beschreiben. Eine Registry verwaltet Metadaten und ermöglicht so die Recherche nach Metadatenu. Werden mehrere Registries gemeinsam genutzt, müssen die Metadaten übergreifend harmonisiert werden, bzwa. Metadatenstandards bereitgestellt werden: WertebereicheSchnittstellen Berechtigungssystem, Abhängigkeiten, Zuständigkeit, Abbildungsregeln, Versionierung Schnittstellenspezifikation zur Anbindung des elektronischen Impfpasses) angeführt und Policies.<br/>³ HL7 Clinical Document Architecture, Release 2.0 (http://www.hl7im Rahmen konkreter System-Anbindungen zu berücksichtigen.org)<br/>⁴ IHE IT Infrastructure Technical Framework (http://www.ihe.net)

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

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"OID-Portal für das Österreichische Gesundheitswesen“ Gesundheitswesen" publiziert (https://www.gesundheit.gv.at/OID_Frontend/).

Für die erste Umsetzungsphase von ELGA wurden die Dokumentenklassen Entlassungsbrief (Ärztlich, Pflegerisch), Laborbefund und Befunde der bildgebenden Diagnostik („Radiologiebefunde“"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 in den "ELGA CDA-Implemen-tierungs¬leitfädenImplementierungsleitfä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.

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

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“ "approved" versehen.

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

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 bestehenden Dokumentes bekommen den Status „deprecated“"deprecated". In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp „replace“ "replace" (RPLC)).

Dokumente werden „Storniert“"storniert", indem der Dokumentstatus auf „deprecated“ "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.  ====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].

ELGA schreibt keine Größenbeschränkung für registrierte Objekte die Größe der eingebrachten CDA eine Maximalgröße von 20 MB vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. 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 [1], Kapitel 6.10]]. ===Eingebettete PDF-Dateien===Eingebettete PDF-Dateien MÜSSEN dem Standard PDF/A 1a (gemäß „ISO 19005-1:2005 Level A conformance“) entsprechen⁵.  ⁵Bis zum verpflichtenden Vorliegen von Dokumenten in EIS Full Support (2018) ist PDF/A-1b zulässig.

Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumente entsprechend klassifiziert und beschrieben werden. Diese beschreibenden „Metadaten“ "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 Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE „IT"IT-Infrastructure“ Infrastructure" (ITI) Technical Framework, Volume 3 festgelegt (IHE ITITF-TF33)<ref name="ITITF3"/>.

'''Hinweis:''' Sehen Sie Siehe auch die Vorschrift Vorschriften zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE „IT Infrastructure“ IT Infrastructure Technical Framworks(ITI) Technical Frameworks , Volume 3, Revision 10.0 – Final Text (27. 09.2013)⁶.   <sup>6<ref name="ITITF3"/sup> http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf, zuletzt besucht am 26.3.2014

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. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.

Die IHE hat im Rahmen des „Patient "Patient Care Coordination“ 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 "Patient Care Coordination“ Coordination" (PCC) Technical Frameworks Revision 911.0, Volume 2 , Kapitel XDSDocumentEntry Metadata beschrieben.<ref name="IHEPCC">IHE "Patient Care Coordination" (4PCC) Technical Frameworks Revision 11.0, Volume 2 [https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf https://www.10ihe.2013)<sup>7net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf]</supref>, Kapitel XDSDocumentEntry Metadata beschrieben.

⁷ http://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf, zuletzt besucht am 26.3.2014 ===Metadaten aus „On-Demand Documents“ Bilddaten (ODDKOS) ===Über XDS Bilddaten können auch Dokumente über KOS-Objekte (Key Object Selection Document) referenziert und abgerufen werden, die zum Abfragezeitpunkt automatisch generiert werden. Für diese Dokumente werden Verweise Die notwendigen Metadaten können in der Registry eingetragen, damit sie bei der Abfrage auch gefunden gewissem Maße aus diesen KOS-Objekten selbst automatisiert entnommen 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 Eine genaue Beschreibung der für Onden Aufbau von KOS-Demand Documents Objekten findet sich im IHE IT Infrastructure Technical Framework, Revision 12 (18.9.2015)⁸Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch.

* # Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)* # Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)* <span style="color:red;"># '''Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können(XDS Document Source)'''</span>* <span style="color:red;">'''# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)## '''ELGA relevante'''## Nicht ELGA relevanteDieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert). ==Ü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.  <br /span>''Tabelle 1: Legende zur Spalte "Quelle" der folgenden Tabelle'' {| class="wikitable" width="100%"|- style="background:#CBD7F1"! style="text-align:left" |Code|| style="text-align:left" |Bedeutung|- style="background:#CBD7F1"|K||Aus KOS-Inhalt abgeleitet|- style="background:#white"|E1||Explizit gesetzt (ELGA relevant)|- style="background:#white"|E2||Explizit gesetzt (nicht ELGA relevant)|- style="background:#white"|A||Von Registry oder Repository automatisch gesetzt** <span |- style="background:#white"|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt|}  ''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle '' {| class="wikitable" width="100%"|- ! style="text-align:left" |Code|| style="text-align:left" |Bedeutung|- style="background:CBD7F1"|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"|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"|O||Optional|- style="colorbackground:red;white">|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)''{| class="wikitable"| colspan="2" |'''Metadaten Element'''|'''Optionalität'''|'''Quelle'''|'''Beschreibung'''|-| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)|'''ELGA relevanteM [1..1]'''|<nowiki>-</spannowiki>** Nicht ELGA relevante|Die Person oder das Gerät, welche(s) das Dokument verfasst hat|-| rowspan="4" ||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/KDieses Dokument behandelt nur XDS Metadaten Elemente |Fachrichtung der fett und rot markierten KategorienPerson|-| colspan="2" |'''classCode'''|'''M [1..1]'''|A|Dokumenten/Objektklasse (Oberklasse)

⁸ httpz.B.:55113-5 "Key images Document Radiology"|-| colspan="2" |'''confidentialityCode'''|'''M [1..1]'''|A|Vertraulichkeitscode. Fester Wert "N"|-| colspan="2" |'''creationTime'''|'''M [1..1]'''|K|Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes|-| colspan="2" |'''eventCodeList'''|'''M [1..*]'''|A/K|Liste von Codes von Gesundheitsdienstleistungen|-||'''eventCodeDisplayName'''|'''M [1..1]'''|A/wwwK|Bezeichnung von Gesundheitsdienstleistungen nach APPC|-| colspan="2" |'''intendedRecipient'''|'''NP [0.ihe.net0]'''| -|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung|-| colspan="2" |'''languageCode'''|'''M [1..1]'''|A|Sprachcode. Fester Wert "de-AT"|-| colspan="2" |'''legalAuthenticator'''|'''NP [0..0]'''| -|Rechtlicher Unterzeichner|-| colspan="2" |'''serviceStartTime'''|'''M [1..1]'''|K|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung|-| colspan="2" |'''serviceStopTime'''|'''NP [0..0]'''| -|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung|-| colspan="2" |'''sourcePatientId'''|'''M [1..1]'''|K|Patienten ID im Informationssystem des GDA, z.B.: im RIS|-| colspan="2" |'''sourcePatientInfo'''|'''NP [0..0]'''| -|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS|-| colspan="2" |'''title'''|'''M [1..1]'''|A/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1K|Titel des Dokuments|-| colspan="2" |'''typeCode'''|'''M [1..pdf, zuletzt besucht am 081]'''|A|Objekttyp (Unterklasse) codierter Wert|-| colspan="2" |'''uniqueId'''|'''M [1.10.20151]'''|K|Global eindeutige ID des Objektes

<!z.B. SOP Instance UID|-| colspan="2" |'''referenceIdList'''|'''M [1..*]'''|K/E1|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert|-| colspan="5" |'''''Explizit zu setzende Metadaten'''''|-| colspan="2" |'''availabilityStatus'''|'''M [1..1]'''|E1|Gültigkeit des Objektes|-| colspan="2" |'''formatCode'''|'''M [1..1]'''|E1|Format des Objektes|-| colspan="2" |'''healthcareFacilityTypeCode'''|'''M [1..1]'''|E1|Klassifizierung des GDA|-| colspan="2" |'''mimeType'''|'''M [1..1]'''|E1|Mime Type des Dokuments Fester Wert für KOS: "application/dicom"|-| colspan="2" |'''parentDocumentId'''|'''O [0..1]'''|E1|Verweis auf ein referenziertes Objekt|-| colspan="2" |'''parentDocumentRelationship'''|'''O [0..1]'''|E1|Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC, XFRM|-| colspan="2" |'''practiceSettingCode'''|'''M [1..1]'''|E1|Fachliche Zuordnung des Dokuments|-| colspan="2" |'''entryUUID'''|'''M [1..1]'''|E1|UUID des Metadaten-Records des Dokuments(XDS DocumentEntry)|-| colspan="2" |'''objectType'''|'''M [1..1]'''|E1|Typ des DocumentEntries Fester Wert "SD"|-| colspan="2" |'''comments'''|'''O [0..1]'''|K|Kommentar zum Dokument/Objekt|-| colspan="2" |'''patientId'''|'''M [1..1]'''|E1|Patienten-ID in der XDS Affinity Domain|-| colspan="5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten '''''|-| colspan="2" |'''hash'''|'''M [1..1]'''|A|Hash Wert des Dokuments. Wird vom Repository befüllt|-| colspan="2" |'''homeCommunityId'''|'''M [1..1]'''|A|Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für CDA Dokumenteeine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.|-| colspan="2" |'''repositoryUniqueId'''|'''M [1..1]'''|A|Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.|-| colspan="2" |'''size'''|'''M [1..1]'''|A|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository befüllt.<br />|-| colspan="2" |'''URI'''|'''NP [0..0]'''[[#%20ftn1|<nowiki/>]][[#%20ftn1|<nowiki/>]]|A|Wird in XDS -I nicht verwendet|-|-| colspan="5" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''|-| colspan="2" |'''elgaFlag'''|'''M [1..1]'''|B|Kennzeichnet ein Dokument als "ELGA-Dokument"|-| colspan="2" |'''elgaHash'''|'''M [1..1]'''|B|Prüfkennzeichen für CDA DokumenteIntegrität und Authentizität des XDS-Metadatensatzes|}<br />[[#%20ftn1|<nowiki/>]]  <br /><p style="page-break-before: always"></p>

==Überblickstabelle der XDS Metadatenfür HL7 CDA Objekte==

In der Tabelle 3 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.

|- style="background:#CBD7F1"

|- style="background:#C8F2BCCBD7F1"

|- style="background:#F4C789white"

|- style="background:#F4C789white"

|- style="background:#DDDDDDwhite"

|- style="background:#DDDDDDwhite"

  ''Tabelle 15: Legende zur Spalte „Quelle“ "Optionalität" der folgenden Tabelle''

|R||Verpflichtend 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”)|- style="background:whiterequired if known"|R2||Verpflichtend wenn bekannt („Required if Known“)''.

|XNP||Wird nicht unterstützt – wird bei Das '''Element i'''st NICHT ERLAUBT. Entspricht der Registrierung nicht eingetragenin älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')

|- style="background:#DA9DA6CBD7F1"| 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="305%" |'''Beschreibung Quelle'''|| rowspan="2" style="text-align:left" width="20%" |'''QuelleBeschreibung '''|- style="background:#DA9DA6CBD7F1"|'''SD'''⁹||'''||ODD'''ODD¹⁰'''|- style="background:#C8F2BCCBD7F1"

|- style="background:#C8F2BCwhite"| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''RM [1..1]'''||'''RM [1..1]'''|C||Die Person, welche das Dokument verfasst hat||-|- style="background:#C8F2BCwhite"| ||authorInstitution||'''RM [1..1]'''||'''RM [1..1]'''|C||ID und Name der Organisation (Kurzbezeichnung), der die Person angehört. (OID aus dem , wie im GDA-Index)||Cangegeben.|- style="background:#C8F2BCwhite"| ||authorPerson||'''RM [1..1]'''||'''RM [1..1]'''|C||Daten der Person.<br />(Name, ID, etc.)||C|- style="background:#C8F2BCwhite"| ||authorRole||'''R2R [0..1]'''||'''XNP [0..0]'''|C||Rolle der Person||C|- style="background:#C8F2BCwhite"| ||authorSpeciality||'''R2R [0..1]'''||'''XNP [0..0]'''|C||Fachrichtung der Person||C|- style="background:#C8F2BCwhite"| colspan="2" |'''classCode'''||'''RM [1..1]'''||'''RM [1..1]'''|C||Dokumentenklasse (Oberklasse)<br />z.B.: 18842-5 „Entlassungsbrief“||C"Entlassungsbrief"|- style="background:#C8F2BCwhite"| colspan="2" |'''confidentialityCode'''||'''RM [1..1]'''||'''XNP [0..0]'''|C||Vertraulichkeitscode des Dokuments||C|- style="background:#C8F2BCwhite"| colspan="2" |'''creationTime'''||'''RM [1..1]'''||'''RNP [0..0]'''|C|Zeitpunkt der Dokumentenerstellung||CMedizinisch relevantes Datum, je nach Definition im speziellen Leitfaden|- style="background:#C8F2BCwhite"| colspan="2" |'''eventCodeList'''||'''R2R [0..*]'''||'''R2R [0..*]'''|C||Liste von Gesundheitsdienstleistungen|-| colspan="2" |'''formatCode'''|'''M [1..1]'''|'''M [1..1]'''|C|Format des Dokumenteninhalts|- style="background:#C8F2BCwhite"| colspan="2" |'''intendedRecipient'''||'''O[0..1]'''||'''XNP [0..0]'''|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C|- style="background:#C8F2BCwhite"| colspan="2" |'''languageCode'''||'''RM [1..1]'''||'''RM [1..1]'''|C||Sprachcode des Dokuments<br />z.B.: "de-AT"||C|- style="background:#C8F2BCwhite"| colspan="2" |'''legalAuthenticator'''||'''R2R [0..1]'''||'''XNP [0..0]'''|C||Rechtlicher Unterzeichner des Dokuments|-|colspan="2" |'''practiceSettingCode'''|'''M [1..1]'''|'''M [1..1]'''|C|Fachliche Zuordnung des Dokuments|- style="background:#C8F2BCwhite"| colspan="2" |'''serviceStartTime'''||'''R2R [0..1]'''||'''O[0..1]'''|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C|- style="background:#C8F2BCwhite"| colspan="2" |'''serviceStopTime'''||'''R2R [0..1]'''||'''O[0..1]'''|C||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung||C|- style="background:#C8F2BCwhite"| colspan="2" |'''sourcePatientId'''||'''RM [1..1]'''||'''RM [1..1]'''|C||Patienten ID im Informationssystem des GDA. , z.B.: im KIS des KH||C|- style="background:#C8F2BCwhite"| colspan="2" |'''sourcePatientInfo'''||'''RNP [0..0]'''||'''RNP [0..0]'''|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C|- style="background:#C8F2BCwhite"| colspan="2" |'''Title'''||'''RM [1..1]'''||'''RM [1..1]'''|C||Titel des Dokuments||C|- style="background:#C8F2BCwhite"| colspan="2" |'''typeCode'''¹¹||'''RM [1..1]'''||'''RM [1..1]'''|C||Dokumententyp (Unterklasse) <br />codierter Wert, z.B.: 11490-0, „Entlassungsbrief "Entlassungsbrief aus stationärer Behandlung (Arzt)“||C"|- style="background:#C8F2BCwhite"| colspan="2" |'''uniqueId'''||'''RM [1..1]'''||'''RM [1..1]'''|C||Global eindeutige ID des Dokuments||C|- style="background:#C8F2BCwhite"| colspan="2" |'''referenceIdList'''||'''RM [1..1]'''||'''O[0..1]'''|C||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert|- style="background:white"| colspan="2" |'''healthcareFacilityTypeCode'''||'''M [1..1]'''||'''M [1..1]'''|C||Klassifizierung des GDA

|- style="background:#F4C789white"

|- style="background:#F4C789white"| colspan="2" |'''availabilityStatus'''||'''RM [1..1]'''||'''RM [1..1]'''|E1||Gültigkeit des Dokuments||E1|- style="background:#F4C789white"| colspan="2" |'''formatCodemimeType'''||'''RM [1..1]'''||'''RM [1..1]'''||Format des Dokumenteninhalts||E1|- style="background:#F4C789"| colspan="2" |'''healthcareFacilityTypeCode'''||'''R'''||'''R'''||Klassifizierung des GDA||E1|- style="background:#F4C789"| colspan="2" |'''mimeType'''||'''R'''||'''R'''||Mime Type des Dokuments<br />z.B.: „text"text/xml“ xml" für CDA||E1|- style="background:#F4C789white"| colspan="2" |'''parentDocumentId'''||'''O¹²||'''O [0..1]'''||'''O[0..1]'''|E1||Verweis auf ein referenziertes Dokument||E1|- style="background:#F4C789white"| colspan="2" |'''parentDocumentRelationship'''||'''O¹³||'''O [0..1]'''||'''O[0..1]'''|E1||Typ der Relation zu dem referenzierten Dokument.<br />z.B.: RPLC, XFRM||E1|- style="background:#F4C789white"| colspan="2" |'''practiceSettingCodeentryUUID'''||'''RM [1..1]'''||'''RM [1..1]'''||Fachliche Zuordnung des Dokuments||E1|- style="background:#F4C789"| colspan="2" |'''entryUUID'''||'''R'''||'''R'''||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)||E1|- style="background:#F4C789white"| colspan="2" |'''objectType'''||'''RM [1..1]'''||'''RM [1..1]'''|E1||Typ des DocumentEntries (SD oder ODD)||E1|- style="background:#F4C789white"| colspan="2" |'''comments'''||'''O[0..1]'''||'''O[0..1]'''|E2||Kommentar zum Dokument||E2|- style="background:#F4C789white"| colspan="2" |'''patientId'''||'''RM [1..1]'''||'''RM [1..1]'''|E1||Patienten-ID in der XDS Affinity Domain||E1

|- style="background:#DDDDDDwhite"

|- style="background:#DDDDDDwhite"| colspan="2" |'''hash'''||'''RM [1..1]'''||'''XNP [0..0]'''|A||Hash Wert des Dokuments. Wird vom Repository befüllt.||A|- style="background:#DDDDDDwhite"| colspan="2" |'''homeCommunityId'''||'''RM [1..1]'''||'''RM [1..1]'''|A||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine „Community“"Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.||A|- style="background:#DDDDDDwhite"| colspan="2" |'''repositoryUniqueId '''||'''RM [1..1]'''||'''RM [1..1]'''|A||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.||A|- style="background:#DDDDDDwhite"| colspan="2" |'''size'''||'''RM [1..1]'''||'''XNP [0..0]'''|A||Größe des Dokuments in Bytes. Wird vom Repository befüllt.||A|- style="background:#DDDDDDwhite"| colspan="2" |'''URI'''||'''-¹⁴NP [0..0]'''||'''-NP [0..0]'''|A||<span style="color:red;">'''Wird in XDS nicht verwendet'''</span>||A|- style="background:#DDDDDDwhite"

|- style="background:#DDDDDDwhite"| colspan="2" |'''elgaFlag'''||'''RM [1..1]'''||'''RM [1..1]'''|B||Kennzeichnet ein Dokument als „ELGA"ELGA-Dokument“||BDokument"|- style="background:#DDDDDDwhite"| colspan="2" |'''elgaHash'''||'''RM [1..1]'''||'''RM [1..1]'''|B||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B

⁹ SD: „Stable Document“"Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht.<br />¹⁰ ODD: „On"On-Demand Document“demand Document": Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird. <br />¹¹ Der Inhalt des typeCodes soll mit dem contentTypeCode des SubmissionSets Submission Sets übereinstimmen.<br />¹² MUSS vorhanden sein, wenn eine „parentDocumentRelationship“ "parentDocumentRelationship" existiert. <br />¹³ MUSS gemeinsam mit einer „parentDocumentId“ "parentDocumentId" angegeben sein.<br /> =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<ref name="ITITF3"/>. 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''' '''der Studie'''|'''Attribut''' '''im KOS'''|'''Beschreibung'''|- 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. 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.|- 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 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.|- style="background:white"|||'''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.|- 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 '''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 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.|- style="background:white"| colspan="2" |eventCodeList|M [1..*]|||Enthält eine Liste von Codes von Gesundheitsdienstleistungen nach APPC siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten<supnowiki/>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 siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom" />|- style="background:white"| 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) (0010,0010) (0010,0030) (0010,0040)|(0010,0020) (0010,0010) (0010,0030) (0010,0040)|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. 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".<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 Diese kann von jedem Bereich frei gewählt werden, sie ist mit dem Datentyp '''<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>''' 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.)<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. Diese ist mit dem Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' 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 '''<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.|} ==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==  ===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. 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.  *''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> '''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.{{EndYellowBox}} =====Spezifikation===== '''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: <span>$name</span> … Name der Organisation, die die Studie erstellt hat <span>$oid ... OID der Organisation aus dem GDA-Index</span> concat(<br /><span>$</span>name,"^^^^^^^^^",<br /><span>$</span>oid,"&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="authorInstitution"> <ValueList> <Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;amp;ISO </Value> </ValueList> </Slot> </Classification></pre> Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />. ====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: #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) {{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. '''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}} =====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(<br /><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>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>  2. Fall: Bei der lokalen ID handelt es sich um eine OID: concat(<br /><span> $id</span>,"^",<br /><span> $person</span><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>2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value> </ValueList> </Slot> </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. =====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  )<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" />. ====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" ====authorSpeciality====Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das KOS-Objekt verfasst hat. Beispiel: *"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"><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></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. {{EndYellowBox}} ===classCode (und classCodeDisplayName)===Das ''classCode'' Element klassifiziert (grobe Granularität) das registrierte Objekt und ist relevant für das Berechtigungssystem. Unterscheidung classCode/typeCode:{| class="wikitable"|- style="background:white"|'''''classCode'''''|'''''Objektklasse in grober Granularität'''''|- style="background:white"|''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> <Value>urn:oid:$codeSystem</Value> </ValueList> </Slot></Classification></pre> ===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" <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==== confidentialityCode wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: $code = "N"<br />$displayName = "normal"<br />$codeSystem = "2.16.840.1.113883.5.25" <pre class="ilfbox_code"><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></pre> ===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: #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) 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: *Timezone Offset From UTC (0008,0201)*Es DÜRFEN NUR folgende Datumsformen verwendet werden:*#YYYYMMDD*#YYYYMMDDhhmmss ====Spezifikation==== '''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br /> $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 )<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="creationTime"> <ValueList> <Value>20100511134500</Value> </ValueList> </Slot></ExtrinsicObject></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. 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<ref name="ITITF3" />.{{EndYellowBox}} ===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. ====Spezifikation==== '''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br /> Für jedes documentationOf Element [1..n]:<br /> <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 /><span>$codeSystem</span> = OID des Codesystems APPC: 1.2.40.0.34.5.38<br /><pre class="ilfbox_code"><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></pre> ===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'''====Spezifikation==== '''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: Fester Wert "de-AT"<pre class="ilfbox_code"><ExtrinsicObject mimeType="text/supxml" 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></pre>  ===legalAuthenticator===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) Für die serviceStopTime steht kein Mapping zur Verfügung und wird daher nicht angegeben [NP]. ====Spezifikation===='''serviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: concat( Study Date, Study Time + Timezone Offset from UTC )<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="serviceStartTime"> <ValueList> <Value>20100511134500</Value> </ValueList> </Slot></ExtrinsicObject></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. 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}} ===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.====Spezifikation==== '''sourcePatientId''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: $patientID = (0010,0020) Patient ID $oid = OID des lokalen Patientenidentifikators  concat( $patientID, "^^^&amp;amp;", $oid, "&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"> <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" />. ===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}} ===title===Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes. Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten: #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 Modality 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}}====Spezifikation==== '''title''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt: concat(  Modality, " ", 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}} ===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:{| 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]]|} ====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" <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"><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></pre> ====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"<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. ===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)====Spezifikation==== uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt: $value = (0008,0018) SOP Instance UID <pre class="ilfbox_code"><ExternalIdentifierregistryObject="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===Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:  #Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId, M [1..1])#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]) '''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:<ref name="ITITF3"/><!-- 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. *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}} '''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}} ====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. =====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, "^^^^",  "<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>", "^",  "&amp;amp;",  $homeCommunityId, "&amp;amp;ISO" )  Wie oben angeführt wird folgender CXi Wert für <Value> 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>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> </ValueList> </Slot> </ExtrinsicObject></pre> Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist. ====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). =====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;amp;" $root, "&amp;amp;ISO", "^", "<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>" )<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" ====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=====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;amp;" $root, "&amp;amp;ISO", "^", "<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>" )<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>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> </Value> </ValueList> </Slot> </ExtrinsicObject></pre> ====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: <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.*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki> Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<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>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> ===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. ===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) ====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 /> ==XDS Metadaten 2: explizit zu setzen (ELGA relevant)=====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. <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> ===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. ====Spezifikation===='''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: <br /><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"><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)===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).{{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==== '''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: <span>$code </span>= Klassifizierung des GDA (Code) <span>$displayName </span>= Klartext des angegebenen Codes <span>$codeSystem </span>= OID der ausgebenden Stelle <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===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>. Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom". ====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<br /><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"*F052 "Unfallchirurgie" Im KOS-Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.{{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]".{{EndYellowBox}} ====Spezifikation==== '''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: <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"><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></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> ==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.  ===elgaFlag===Das elgaFlag dient zur Kennzeichnung eines Objektes als "ELGA-Objekt"¹⁸. 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 Vollständigkeit halber angegebenBerechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen: *"true" oder*"false" ¹⁸ 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. ====Spezifikation==== <pre class="ilfbox_code"><Slot name="urn:elga-bes:elgaFlag"> <ValueList> <Value>true</Value> </ValueList></Slot></pre> ===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. ====Spezifikation====<pre class="ilfbox_code"> <rim:Slot name="urn:elga-bes:elgaHash"> <rim:ValueList> <rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value> </rim:ValueList> </rim:Slot></pre> =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"/>

 # 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. # GDAsGDA, in dessen deren Gültigkeitsbereich Dokumente erstellt werden können , sind seitens der Basiskomponente „GDA Index“ "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}}

{{BeginOrangeBox}}'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: <span style="color:red;">$inst</span> … ClinicalDocument/author/assignedAuthor/representedOrganization{{EndOrangeBox}} *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"><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;amp;ISO</Value> </ValueList> </Slot> </Classification></pre> 

*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/>{{BeginOrangeBox}}concat(<br/><span style="color2:red;">$inst</span>/name,"^^^^^^^^^",<br/><span style="color:red;">$inst</span>/id[1]/@root<br/>)<br/>Bsp: Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45{{EndOrangeBox}}

Fall 2<br/>Element $inst/id[1] ist vorhanden<br/>Attribut &$inst/id[1]/@root ist vorhanden<br/>Attribut &$inst/id[1]/@extension ist vorhanden<br/>{{BeginOrangeBox}}concat(<br/><span style="color:red;">$inst</span>/name,"^^^^^&",<br/><span style="color:red;">$inst</span>/id[1]/@root,"&ISO^^^^"<br/><span style="color:red;">$inst</span>/id[1]/@extension<br/>)<br/>Bsp: Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&ISO^^^^45{{EndOrangeBox}}

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 ITITF-TF3]3<ref name="ITITF3"/>.{{EndYellowBox}}

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

 # Laut Festlegung wird der Autor im Header-Element „author“ "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

{{BeginOrangeBox}}concat(<br/><span style="color'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:red"> $person</span>/id/@extension,"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/family,"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/given[1],"^",<br/><span style="color:red"> $person<ClinicalDocument/span>/assignedPerson/nameauthor/given[2],"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/suffix,"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;amp;",<br/><span style="color:red"> $person</span>/id/@root,"&amp;amp;ISO"<br/>)<br/>Bsp: 1234^Musterdoktor^Herbert^^^Dr.^^^&amp;amp;1.2.3.4.5.6.7.8.9&amp;amp;ISO{{EndOrangeBox}}assignedAuthor

{{BeginOrangeBox}}'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: <span> $person</span> = ClinicalDocument/author/assignedAuthor concat(<br/>"^",<br/><span style="color:red"> $person</span>/assignedAuthoringDevice/manufacturerModelName,"^",<br/><span style="color:red"> $person</span>/assignedAuthoringDevice/softwareName<br/>)<br/>Bsp<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>^Good Health System^Best Health Software Application</Value> </ValueList>{{EndOrangeBox}} </Slot></Classification></pre>

Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITITF-TF3]3<ref name="ITITF3"/>.{{EndYellowBox}}

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

 # Laut Festlegung wird die „Rolle“ "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 '''''[R2R]'''''.# Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.

 * „Facharzt "Facharzt für Gynäkologie“Gynäkologie"* „Facharzt "Facharzt für interne Medizin“Medizin" 

#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. =====Spezifikation====Spezifikation= '''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: ClinicalDocument/author/assignedAuthor/code/@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="authorSpeciality"> <ValueList> <Value>Anästhesiologie und Intensivmedizin</Value> </ValueList> </Slot> </Classification></pre>

| '''''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]]|} Ausgangsbasis dieses Werts ist das Element ClinicalDocument/code, welches ELGA auf hierarchische Überbegriffe (die Dokumentenklasse) gemappt werden kann. Der Wert für classCode ergibt sich aus dieser Zusammenfassung. {{BeginValueSetBox}}Vorschrift für die Zusammenfassung ClassCode - TypeCode:<br/>Als classCode MUSS dasjenige Element des Lvl-Typ „0“ des Value Sets „'''ELGA_Dokumentklassen'''“ angegeben werden, in dessen Unterelementen sich der Wert der Ausgangsbasis (ClinicalDocument/code) befindet. Weitere Informationen finden sich in den ELGA CDA Implementierungsleitfäden.{{EndValueSetBox}} Beispiel:  Die Spezialisierungen des Entlassungsbriefes „Ärztlich“ und „Pflege“ werden unter dem Sammelbegriff „Entlassungsbrief“ zusammengefasst:{| class="wikitable"! Lvl-Typ! Code (LOINC)! DisplayName! Deutsche Sprachvariante¹⁵! Element in XDS

|''' 0-S'''|''' 18842-5'''| Discharge summary| Entlassungsbrief| '''classCode'typeCode''|-style="backgroundDokumentenklasse in feiner Granularität.<br /> Siehe Kapitel [[ILF:white"| 1-L| 11490-0| Physician Discharge summary| Entlassungsbrief Ärztlich| typeCode|-style="background:white"| 1-L| 34745-0| Nurse Discharge summary| Entlassungsbrief PflegeXDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2| typeCode]]

<span style="color'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:red;">$typeCode </span>= ClinicalDocument/code/@code<br/>

Mapping der Dokumentenklasse (feine Granularität) auf Sammelbegriff:<br/><span style="color:red;">$code = Mapping-Tabelle($typeCode)ClinicalDocument/code/translation/@code<br/>$displayName = ClinicalDocument/code/translation/@displayName($code)<br/>$codeSystem = fixe OID aus der Mapping-TabelleClinicalDocument/code/translation/@codeSystem<br/></span><pre class="orangeilfbox_code"><rim:Classification classificationScheme= "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="theDocument" nodeRepresentation="$code">  <rim:Name> <rim:LocalizedString value="$displayName"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>urn:oid:$codeSystem</rim:Value> </rim:ValueList> </rim:Slot></rim:Classification>

Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlichund wird fix auf "N" (normal) gesetzt.  Es wird der Vertraulichkeitscode aus dem CDA Header Element gemäß folgender Spezifikation übernommen:{{BeginValueSetBox}}Zulässige Werte gemäß Value Set „'''ELGA_Confidentiality'''“. {{EndValueSetBox}}

confidentialityCode wird als ebRIM Slot gemäß folgendem Beispiel abgebildet:<pre class="orange"><rim:Classification classificationScheme= "urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="theDocument" nodeRepresentation="$code"br />

<rimpre class="ilfbox_code"><Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="theDocument" nodeRepresentation="N"> <Name> <rim:LocalizedString value="$displayNamenormal"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>urn:oid:$codeSystem2.16.840.1.113883.5.25</rim:Value> </rim:ValueList> </rim:Slot></rim:Classification></pre>{{EndYellowBox}}

Das creationTime Element beschreibt den Zeitpunkt Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden. Dieses Datum kann für die chronologische Sortierung der Befunde bei der Anzeige der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSENDokumentenliste verwendet werden.

 # Im CDA wird die Klassifizierung des Dokuments 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 Dokumentendatums ein verpflichtendes ElementDatums 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. {{BeginYellowBox}}CreationTime entfällt bei On-Demand DocumentsDocumenten.{{EndYellowBox}} Das Aktualisierungsdatum von Dokumenten (Update-Datum) kann über submissionTime (in XDS.submissionSet) erkannt werden.

{{BeginYellowBox}}'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>ClinicalDocument/effectiveTime/@value = "20200511193000+0200"<pre class="orangeilfbox_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">ClinicalDocument <Slot name="creationTime"> <ValueList> <Value>20200511173000</Value> </effectiveTimeValueList> </@valueSlot>Bsp: 20100511134500</ExtrinsicObject>

Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.{{BeginYellowBox}}creationTime '''Hinweis: MUSS'''<br/>creationTime MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ "Kürzen" auf andere Formate ist nicht zulässig. Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20100511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS '''diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20100511173000).

Dies entspricht einer Transformation auf Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200511193000+0200). In den HL7 v2 DTM Datentyp XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS '''diese zuvor gemäß [IHE ITI-TF3]der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200511173000).

 # Im CDA wird die Liste der Service-Events ServiceEvents wie folgt abgelegt:## ClinicalDocument/documentationOf/serviceEvent# Mehrere dieser Service-Events ServiceEvents können durch beliebig viele „documentationOf“ "documentationOf" Elemente ausgedrückt werden.# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines Service-Events ServiceEvents verpflichtend, wenn bekannt [R2R].# Ein serviceEvent 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 Service Event ServiceEvent eine Gesundheitsdienstleistung angegeben werden muss, und welche Bedeutung dieses Element hat.

Für jedes documentationOf Element 1..n'''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br/>

<span style="color:red;">$code </span>= ClinicalDocument/Für jedes documentationOf[Element 1..n]/serviceEvent/code/@code<br/><span style="color:red;">$displayName</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName<br/><span style="color:red;">$codeSystem</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem<br/><pre class="orange"><rim:Classification classificationScheme= "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" classifiedObject="theDocument" nodeRepresentation="$code">

<rimspan>$code </span>= ClinicalDocument/documentationOf[n]/serviceEvent/code/@code<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"><Classification classificationScheme= "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" classifiedObject="theDocument" nodeRepresentation="$code"> <Slot name="codingScheme"> <rim:ValueList> <rim:Value>urn:oid:$codeSystem</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="$displayName"/> </rim:Name></rim:Classification>

Das IHE Patient Care Coordination (PCC Profil ) Technical Framework vol. 2<ref name="IHEPCC"/> definiert in Kapitel „Medical "Medical Document Bindings“ Binding" Spezialbehandlungen für gewissen gewisse Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC).

{{BeginYellowBox}}'''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: ClinicalDocument/languageCode/@code = "de-AT"<pre class="orangeilfbox_code">ClinicalDocument<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/@code"> <ValueList>Bsp: <Value>de-AT</Value> </ValueList> </Slot></ExtrinsicObject>

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“"Medikationsliste").

'''legalAuthenticatorACHTUNG:''' wird gemäß folgender Vorschrift zusammengesetzt:<br/>{{BeginOrangeBox}}<span style="color:red"> $person </span>= ClinicalDocument/Nach DocumentEntry.legalAuthenticator/assignedEntity{{EndOrangeBox}}{{BeginOrangeBox}}concatkann jeweils nur das erste Element (<brClinicalDocument/><span style="color:red"> $person</span>/id/@extension,"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/family,"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/givenLegalAuthenticator[1],"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/given[2],"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/suffix,"^",<br/><span style="color:red"> $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;amp;",<br/><span style="color:red"> $person</span>/id/@root,"&amp;amp;ISO"<br/>)<br/>Bsp: 1234^Musterdoktor^Herbert^^^Dr.^^^&amp;amp;1.2.3.4.5.6.7.8.9&amp;amp;ISO{{EndOrangeBox}}Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3]übernommen werden.

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

 # Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens einem Service-Event ServiceEvent verpflichtend:## ClinicalDocument/documentationOf/serviceEvent# Das Element serviceEvent 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{{BeginYellowBox}}Es soll jeweils das erste '''serviceEvent''' für das Mapping verwendet werden.{{EndYellowBox}}

Dieses Element '''serviceStartTime''' wird gemäß folgender Vorschrift zusammengesetzt:<pre class="orange">ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@valueBsp: 20110504120000</pre>'''Hinweis: MUSS'''<br/>Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ "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. 2010051119300020200511193000+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 2010051117300020200511173000).

Dieses Element '''serviceStopTime''' wird gemäß folgender Vorschrift zusammengesetzt:<pre class="orange">ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@valueBsp: 20110510173000</pre>'''Hinweis: MUSS'''<br/>Dieses Element MUSS – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein „Kürzen“ "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. 2010051119300020200516133000+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 2010051117300020200516113000).

 # 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 (lokalen) System## did[2] … Österreichische Sozialversicherungsnummer (nur wenn bekannt)<br/><span style="color:red;">Achtung: Diese ID gelangt nicht in die Metadaten!</span>

Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.Im Fall eines CDA R2 Dokuments gilt grundsätzlich folgende Verknüpfung mit den CDA Header Elementen:# Laut Vorgabe der ELGA Gesundheitsdaten ist beim Patienten die Angabe der folgenden Elemente verpflichtend:## Verpflichtend### Lokale ID des Patienten aus dem System (id[1])### Patientenname (name)### Geschlecht (administrativeGender)### Geburtsdatum (birthTime)## Verpflichtend wenn bekannt### Sozialversicherungsnummer des Patienten (id[2])<br/><span style="color:red^^^&amp;amp;">Achtung: Diese ID gelangt nicht in die Metadaten!</span>### Adresse (addr)#### Beliebige Granularität{{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. Von einer Speicherung in der Registry wird daher abgeraten.{{EndYellowBox}}

====Spezifikation (empfohlene Variante)===={{BeginYellowBox}}'''sourcePatientInfo''' wird gemäß folgender Vorschrift zusammengesetzt:{{BeginOrangeBox}}$patientRole = ClinicalDocument/recordTarget/patientRole{{EndOrangeBox}}{{BeginOrangeBox}}<span style="color:red">$id </span>= concat($patientRole/id[1]/@extension, "^^^&amp;amp;",$patientRole/id[1]/@root, "&amp;amp;ISO")Bsp: 4711^^^&amp;amp;1.2.3.4.5.6.7.8.9&amp;amp;ISO

<span style="color:red">$name </span>= "&amp;amp;ISO"

)<span stylepre class="color:redilfbox_code">$birthtime </span>ExtrinsicObject mimeType= "text/xml"  <span style objectType="colorurn:red">$gender </span> = "uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"  <span style status="colorurn:oasis:names:tc:ebxml-regrep:red">$addr </span>= "StatusType:Approved" {{EndOrangeBox}}<pre class id="orangeurn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"> <rim:Slot name="sourcePatientInfosourcePatientId"> <rim:ValueList> <rim:Value>PID-4711^^^&amp;amp;1.2.3|$id </rim:Value> <rim:Value>PID-.4.5|$name </rim:Value> <rim:Value>PID-.6.7|$birthtime .8.9&amp;amp;ISO</rim:Value> <rim:Value>PID-8|$gender </rim:ValueValueList> <rim:Value>PID-11|$addr </rim:ValueSlot> </rim:ValueList></rim:SlotExtrinsicObject>

====Optionale Spezifikation (mit demografischen Patientendaten)=sourcePatientInfo===Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.

'''sourcePatientInfo''' wird gemäß folgender Vorschrift zusammengesetzt:<pre class="orange">$patientRole = ClinicalDocument/recordTarget/patientRole</pre><pre class="orange">$id = concat($patientRole/id[1]/@extensionIn ELGA werden die Elemente name, "^^^&amp;amp;"administrativeGender,$patientRole/id[1]/@rootbirthTime und addr NICHT zur Identifikation des Patienten benötigt, "&amp;amp;ISO"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.Bsp: 4711^^^&amp;amp;1.2.3.4.5.6.7.8.9&amp;amp;ISO{{EndYellowBox}}

$name = concat($patientRole/patient/name/family,"^",$patientRole/patient/name/given[1],"^",$patientRole/patient/name/given[2],"^",$patientRole/patient/name/suffix,"^",$patientRole/patient/name/prefix[@qualifier="AC"])BspIm Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen: Mustermann^Herbert^^^Ing.

$birthtime = $patientRole/patient/birthtime#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumententitels verpflichtend:##ClinicalDocument/@valueBsp: 19650120title

$gender = $patientRole/patient/administrativeGenderCode/@codeBsp: M===Spezifikation====

$addr = concat($patientRole/addr/streetAddressLine,"^^'''title''' wird als ebRIM ",$patientRoleName/addr/city,@value"^-Attribut im Container ",$patientRole/addr/state,ExtrinsicObject"^",$patientRole/addr/postalCode,"^",$patientRole/addr/country)… oder …$addr = concat(concat($patientRole/addr/streetName," ",$patientRole/addr/houseNumber),"^^",$patientRole/addr/city,"^",$patientRole/addr/state,"^",$patientRole/addr/postalCode,"^",$patientRole/addr/country)Bspgemäß folgender Vorschrift zusammengesetzt: Mustergasse 11^^Wien^W^1230^AustriaBemerkung: Wenn die Adresse nicht in der erforderlichen Granularität zur Verfügung steht, dann wird dieses Element (PID-11) nicht angegeben.</pre>

ClinicalDocument/title <pre class="orangeilfbox_code"><rim:Slot nameExtrinsicObject mimeType="sourcePatientInfotext/xml"> <rim objectType="urn:uuid:ValueList>7edca82f-054d-47f2-a032-9b2a5b5186c1" <rimstatus="urn:oasis:names:tc:Value>PIDebxml-3|$id</rimregrep:StatusType:Value>Approved" <rimid="urn:uuid:Value>PID1e2ede82-8570-4be2-bd46-5|$name</rim:Valuede986a4333be"> <rim:Value>PID-7|$birthtime</rim:ValueName> <rim:Value>PIDLocalizedString charset="UTF-8|$gender</rim" value="Entlassungsbrief der chirurgischen Abteilung" xml:Value> <rim:Value>PIDlang="de-11|$addr<AT" /rim:Value> </rim:ValueListName></rim:SlotExtrinsicObject>

| '''typeCode'''| '''Dokumentenklasse in feiner Granularität (Spezialisierung).'''

| classCode| Dokumentenklasse in grober Granularität.<br/> Siehe Kapitel [[ILF:XDS Metadaten 2020(Version 3)#classCode_.28und_classCodeDisplayName.2929_2|classCode]]

{{BeginValueSetBox}}#Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:Zulässige Werte gemäß Value Set „'''ELGA_ Dokumentenklassen'''“. <br##ClinicalDocument/>codeAls typeCode MUSS das passende #Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentencodes ein verpflichtendes Element aus dem Lvl.#Ein Code-Typ „1“ des Value Sets „'''ELGA_Dokumentklassen'''“ angegeben werden, weitere Informationen finden sich Element in den ELGA CDA Implementierungsleitfädenbeinhaltet unter anderem die folgenden Attribute:##@code … Codierter Wert der Dokumentenklasse###Bsp: Code "11490-0"##@displayName … Lesbarer Wert der Dokumentenklasse###Bsp: "Discharge summarization note (physician)"##@codeSystem … Codierter Wert des zugrundliegenden Codesystems###Bsp: "2.16.840.1.113883.6.1"{{EndValueSetBox}}#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe dieser 3 Attribute des Elements code verpflichtend.

'''typeCode (und typeCodeDisplayName)''' wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt: <span style="color:red"> $code</span> = ClinicalDocument/code/@code<br/><span style="color:red"> $displayName</span> = ClinicalDocument/code/@displayName<br/><span style="color:red"> $codeSystem</span> = ClinicalDocument/code/@codeSystem<br/><pre class="orangeilfbox_code"><rim:Classification classificationScheme= "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="theDocument" nodeRepresentation="$code"> <rim:Name> <rim:LocalizedString value="$displayName"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>urn:oid:$codeSystem</rim:Value> </rim:ValueList> </rim:Slot></rim:Classification>

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z====submissionSet.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse contentTypeCode====Der contentTypeCode des Submission Sets wird als ebRIM Classification umgesetzt und den Dokumententyp angewendet werdensoll dieselben Werte wie typeCode des DocumentEntry tragen. Eine entsprechende Liste “hl7-austria-Dokumentenklassen” OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http: $code = ClinicalDocument/code/@code $displayName = ClinicalDocument/code/@displayName $codeSystem = ClinicalDocument/code/www.hl7.at).@codeSystem

<pre class="ilfbox_code"><RegistryPackage status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" <Classification classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" classifiedObject=submissionSet.contentTypeCode="theDocument" nodeRepresentation="$code"> <Name> <LocalizedString value="$displayName"/> </Name> <Slot name="codingScheme"> <ValueList> <Value>urn:oid:$codeSystem</Value> </ValueList> </Slot> </Classification></RegistryPackage>Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.</pre>

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

uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:<br /> Fall 1<br/>

$value = concat(ClinicalDocument/id/@root) Fall 2<br/>

<pre class$value ="orange">concat(

Bsp<pre class="ilfbox_code"><ExternalIdentifierregistryObject="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"identificationScheme="urn: 1uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"value="$value"> <Name> <LocalizedString value="XDSDocumentEntry.2.3.4.5.6.7.8.9^0815uniqueId"/> </Name></ExternalIdentifier></pre>{{EndYellowBox}}

Um Das referenceIdList Element stellt eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE ITI TF-3<ref name="ITITF3"/> (vorhergehende und auch zukünftige Versionen27 September 2013) innerhalb der XDSDokument neu hinzugekommen. Für CDA-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.Befunde sind drei unterschiedliche Einträge in referenceIdList vorgesehen:

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar#eindeutige Identifikation aller Dokumente eines Dokumentenstammes, d.h. vorhergehende und auch zukünftige Versionen (ownDocument_setId, M [1..1])#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number, O [0.. Dieses Element ist 1])#Verlinkung zwischen einer Aufenthaltszahl mit allen im IHE_ITI_TF_Vol3 Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (27 September 2013encounterId, O [0..1]) Dokument neu hinzugekommen.

Aus dem „Allgemeinen Implementierungsleitfaden“ [1]: „''Die setId bezeichnet das Set {{BeginYellowBox}}Im Rahmen von Dokumenten, ELGA MUSS die zu einer Reihe von Versionen gehören. Sie bleibt über alle Versionen ClinicalDocument/SetId als ein Eintrag in der Dokumente gleich (initialer Wert bleibt erhalten)referenceIdList in den XDS Metadaten strukturiert sein.''“{{EndYellowBox}}

Dieser Datentyp ist in IHE_ITI_TF_Rev10.0_Vol3_FT_2013IHE ITI TF-09-27 in der Table 4.2.3.1.7-2: <ref name="ITITF3"/> Data Types in folgender Weise spezifiziert:

|'''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.{{EndYellowBox}} ====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:  #Laut Vorgabe der ELGA Dokumenten Leitfäden ist die Angabe einer setId für das Dokument verpflichtend: #*ClinicalDocument/setId [M] =====Spezifikation=====ownDocument-SetId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: concat ( ClinicalDocument/setId/@extension, "^^^", "&amp;amp;",  ClinicalDocument/setId/@root, "&amp;amp;ISO", "^",  "<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>", "^", "&amp;amp;",  homeCommunityId, "&amp;amp;ISO" ) Bitte beachten Sie, dass sowohl die ClinicalDocument/setId/@root als auch die homeCommunityId in der Schreibweise "&", OID-Wert, "&ISO" anzugeben sind. 

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

{{BeginYellowBox}}referenceIdList wird gemäß folgender Vorschrift zusammengesetzt:<pre class="orangeilfbox_code"><ClinicalDocument xmlns=„urn"urn:hl7-org:v3“>…<id root="1.2.40.0.34.99.111.1.1" extension="BBBBBBBBBBBBBBBBBBv3"/>

Bitte beachten Sie, dass sowohl die ClinicalDocumentWie 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> </setIdExtrinsicObject></@root als auch pre> Die homeCommunityId ist die homeCommunityId in der Schreibweise „&“, eindeutige OID-Wert, „&ISO“ anzugeben sindunter welcher die ELGA Affinity Domäne registriert ist.

"ZZZZZZZZZZZZZZZZZZZ^^^&amp;amp;1.Beispiel 2.40.0.34.99.111.1.1&amp;amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO"{{EndYellowBox}}Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.in setId/@extension im CDA wird eine UUID geführt

{{BeginYellowBox}}Folgend ein weiteres Beispiel unter Verwendung einer UUID in ClinicalDocument/setId:<pre class="orangeilfbox_code"><ClinicalDocument xmlns=„urn"urn:hl7-org:v3“>…<id root="1.2.40.0.34.99.111.1.1" extension="BBBBBBBBBBBBBBBBBBv3"/>

concat(ClinicalDocument/setId/@extension, Wie oben angeführt wird folgender CXi Wert erstellt: "<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=", ClinicalDocumentilfbox_code"><ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</setIdnowiki>" status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</@root, nowiki>" id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>"^> <Slot name=", <nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <ValueList> <Value><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki><nowiki>&</nowiki>amp;amp;2.25 <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> ====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).  =====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, homeCommunityIdgenutzt werden. Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).

Daher würde sich in diesem Fall Accession Number wird als ebRIM Slot gemäß folgender CXi Wert ergebenVorschrift 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;amp;" $root, "&amp;amp;ISO", "^", "<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>" )<pre class="ilfbox_code"> <ExtrinsicObject mimeType=intendedRecipient"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>">Für die spätere Verwendung von <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 Cross Enterprise Document Workflow RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"<br /> ====Verlinkung via Aufenthaltszahl (XDWencounterId) ist der intendedRecipient notwendig. Derzeit ====Durch encounterId wird dieses Element 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 ELGA nicht verwendetden XDS-Metadaten unterstützt. Sobald IHE XDW für ELGA zugelassen Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-/XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird, folgt die . <br />=====Spezifikation dieses Elementes. =====encounterId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: concat (

==XDS Metadaten 2"<nowiki>urn: explizit zu setzen (ELGA relevant)=====availabilityStatus===Das availabilityStatus-Element beschreibt die Aktualitätihe:iti:xds:2015:encounterId</Sichtbarkeit des eingebrachten Dokuments.nowiki>"

===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 Dokumentsin der Schreibweise "&", OID-Wert, "&ISO" anzugeben ist.

Im CDAWie oben angeführt wird folgender CXi Wert erstellt:<pre class="ilfbox_code"> <ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:7edca82f-Schema steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung, die Information lässt sich aber gegebenenfalls aus dem Element clinicalDocument054d-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>Az123456^^^&amp;amp;1.2.40.0.34.99.4613.templateId ableiten3.4&amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki> </Value> </ValueList> </Slot> </ExtrinsicObject></pre>

====Dokumente in ELGA Interoperabilitätsstufe „Enhanced“ und „Full Support“=intendedRecipient===Die Angabe erfolgt gemäß der Liste Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der intendedRecipient notwendig. Derzeit wird dieses Element in ELGA gültigen Formatcodes mit zusätzlicher Angabe der nicht verwendet. Sobald IHE XDW für ELGA-Interoperabilitäts-Stufe (EIS „Enhanced“zugelassen wird, …)folgt die Spezifikation dieses Elementes.{{BeginValueSetBox}}Zulässige Werte gemäß Value Set '''„ELGA_FormatCode_VS“'''. <br/>(aus der Codeliste ELGA_FormatCode 1.2.40.0.34.5.37){{EndValueSetBox}}

Beispiele:* '''urn:elga:dissum:2011:EIS_Enhanced'''** Gemäß dem Implementierungsleitfaden „Ärztlicher Entlassungsbrief“ [2], im ELGADer intendedRecipient entfällt bei On-Interoperabilitätsstufe „Enhanced“ (Mindest-Stufe für strukturierte Dokumentinhalte).* '''urn:elga:lab:2011:EIS_FullSupport'''** Gemäß dem Implementierungsleitfaden „Laborbefund“ [4], im ELGA-Interoperabilitätsstufe „Full Support“.Demand Documents.

==XDS Metadaten 2: explizit zu setzen (ELGA relevant)====Dokumente in ELGA Interoperabilitätsstufe „Basic“: Zusatz erforderlich=availabilityStatus===Folgt ein ELGA CDA Dokument einem Implementierungsleitfaden einer Fachdomäne in ELGADas availabilityStatus-Interoperabilitätsstufe „Basic“, so enthält dieses Dokument entweder unstrukturierten oder strukturierten Text gemäß CDA Level 1 oder ein eingebettetes Objekt (PDF, JPEG-Grafik, etc.).{{BeginYellowBox}}Alle in ELGA-CDA-Dokumente eingebetteten PDF-Dateien MÜSSEN dem Standard PDFElement beschreibt die Aktualität/A 1a (gemäß „ISO 19005-1:2005 Level A conformance“) entsprechenSichtbarkeit des eingebrachten Dokuments.{{EndYellowBox}}

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

Dieses Attribut wird im Zuge des Einbringens von neuen Dokumenten ("Submission") durch die empfangende XDS Registry immer auf "'''Beispiel:Approved'''* '''urn:elga:dissum:2015-v2.06:EIS_Basic:PDF'''<br/>:Gemäß dem Implementierungsleitfaden „Entlassungsbrief Ärztlich“ [2], im ELGA-Interoperabilitätslevel „Basic“/„Structured“, das eingebettete Objekt liegt als im PDF/A vor" gesetzt.

====Zusatz bei selbst-definierten maschinenlesbaren Elementen (Dokumente in EIS „Enhanced“ oder „Full Support“)====Liegt ein CDA Dokument in ELGA Interoperabilitätsstufe „Enhanced“ oder „Full Support“ vor '''''und enthält das Dokument zusätzliche selbst-definierte maschinenlesbare Elemente (CDA Level 3 oder „Entries“)'''''', so ist dies durch den Zusatz eines Plus-Zeichens („+“) availabilityStatus wird im Formatcode zu kennzeichnen.{{BeginYellowBox}}Die Kennzeichnung von Dokumenten mit selbst-definierten maschinenlesbaren Elementen ist ein „+“ (Plus-Zeichen) am Ende Attribut @status des Formatcodes.{{EndYellowBox}}'''Beispiele:'''* '''urn:elga:dissum-n:2015-v2.06:EIS_Enhanced+'''* '''urn:elga:lab:2015-v2ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.06:EIS_FullSupport+'''

<pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status=Bildungsregel für den formatCodeDisplayName "urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id====Der formatCodeDisplayName ist analog zum formatCode aus den displayNames der entsprechenden Value Sets zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels „"urn:uuid:“ (Doppelpunkt) am Ende angefügt werden, das Plus1e2ede82-8570-4be2-Zeichen am Ende des FormatcodeDisplayNames). bd46-de986a4333be"/></pre>

===formatCode (und formatCodeDisplayName)===Das '''Beispiele:'''* 'formatCode''ELGA Entlassungsbrief Ärztlich, EIS Basic v2Element beschreibt das Format des Dokuments bezüglich seiner semantischen Interoperabilität.06:PDF''Es ermöglicht einem empfangenden System ('* 'Document Consumer Actor''ELGA Entlassungsbrief Pflege, EIS Enhanced v2) die Identifizierung des für die Weiterverarbeitung zu erwartenden Dokumentenformats und somit die korrekte Darstellung und Verarbeitung des Dokuments.06+'''* '''ELGA LaborbefundIm CDA-Schema wurde für die HL7-Austria Domäne ein genau entsprechendes Element geschaffen, EIS Full Support v2"hl7at:formatCode".06+'''

{{BeginYellowBox}}'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br/><span style="color:red;">$code</span> = gemäß Liste der in ELGA gültigen FormatCodes ClinicalDocument/hl7at:formatCode/@code <br/><span style="color:red;">$displayName</span> = gemäß Liste der in ELGA gültigen FormatCodesClinicalDocument/hl7at:formatCode/@displayName <br/><span style="color:red;">$codeSystem</span> = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37ClinicalDocument/hl7at:formatCode/@codeSystem<pre class="orangeilfbox_code"><rim:Classification classificationScheme= "urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="theDocumenturn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf" nodeRepresentation="$code"> <rim:Name> <rim:LocalizedString value="$displayName"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>urn:oid:$codeSystem</rim:Value> </rim:ValueList> </rim:Slot></rim:Classification>

<span style="color'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:red;">$code </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code

<span style="color:red;">$displayName code </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayNamecode

<span style="color:red;">$codeSystem displayName </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem <pre class="orange">displayName

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

Das ''mimeType'' Element beschreibt den „Internet "Internet Media Type“ Type" des Dokuments gemäß dem „Multipurpose "Multipurpose Internet Mail Extensions“ Extensions" (MIME) Standard. Der Standard wird beschrieben in RFC 2045bis RFC 2049.<ref name="RFC2045"/><supref name="RFC2046">16Multipurpose Internet Mail Extensions (MIME) Part Part Two: Media Types [http://tools.ietf.org/html/rfc2046 IETF RFC 2046]</supref><ref name="RFC2047"> bis 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 20492048]<sup/ref>17<ref name="RFC2049"/sup>.

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, welches das DocumentEntry repräsentiert. Folgende Mime-Types sind für Dokumente zugelassen:<br/>CDA R2: '''text/xml'''<br/>DICOM/KOS: '''application/dicom'''<br/><pre class="orangeilfbox_code"><rimExtrinsicObject id="urn:ExtrinsicObject uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" mimeType="text/xml" id objectType="urn:uuid:<entryUUID>34268e47-fdf5-41a6-ba33-82133c465248" objectType status= "urn:uuidoasis:names:tc:7edca82febxml-054d-47f2-a032-9b2a5b5186c1regrep:StatusType:Approved"/>

# Im CDA werden die Informationen über Dokumente, die mit dem eingebrachten Dokumenten in einer bestimmten Relation stehen, in folgendem Element abgelegt:## 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

¹⁶ http'''parentDocumentId''' MUSS mit folgenden Elementen in CDA übereinstimmen://tools.ietf.org/html/rfc2045 <br/>¹⁷ http://tools.ietf.org/html/rfc2049

Im CDA-Schema steht kein Element wurde für die HL7-Austria Domäne ein automatisches Mapping entsprechendes Element in dieses Feld zur Verfügung.{{BeginValueSetBox}}Zulässige Werte gemäß Value Set '''„ELGA_PracticeSetting_VS“'''den CDAs geschaffen, "hl7at:practiceSettingCode".{{EndValueSetBox}}

'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classificationgemäß folgender Vorschrift zusammengesetzt: <span style="color:red;">$code</span> = Code aus ELGA_PracticeSettingClinicalDocument/hl7at:practiceSettingCode/@code<br/><span style="color:red;">$displayName</span> = Klartext des angegebenen Codes (ClinicalDocument/hl7at:practiceSettingCode/@displayName)<br/><span style="color:red;">$codeSystem</span> = OID des Codesystems (1.2.40.0.34.5.12)ClinicalDocument/hl7at:practiceSettingCode/@codeSystem<br/><pre class="orangeilfbox_code"><rim:Classification classificationScheme= "urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="theDocumenturn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf" nodeRepresentation="$code"> <rim:Name> <rim:LocalizedString value="$displayName"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>urn:oid:$codeSystem</rim:Value> </rim:ValueList> </rim:Slot></rim:Classification>

===objectType ===Das objectType Element gibt den Typ des Dokuments XDS DocumentEntry wieder, entweder ein „stabiles Dokument“ . Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "stabiles Dokument" (stable document, SD) oder ein „Onund "On-demand Dokument“ Dokument" (on-demand document, ODD)unterschieden. Der Datentyp objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUIDidentifiziert. Für "Stable Document" DocumentEntry:<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>

{{BeginValueSetBox}}Für "On-Demand Document" DocumentEntry:<pre class="ilfbox_code">Zulässige Werte:<brExtrinsicObject mimeType="text/>xml"''' objectType="urn:uuid:7edca82f34268e47-054dfdf5-47f241a6-a032ba33-82133c465248" status="urn:oasis:names:tc:ebxml-9b2a5b5186c1''' (Stable Document)<br/>regrep:StatusType:Approved"''' id="urn:uuid:34268e471e2ede82-fdf58570-41a64be2-ba33bd46-82133c465248''' (On-Demand Document)de986a4333be"/>{{EndValueSetBox}}</pre>

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

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

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

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"XDS.b Provide and Register Transaktion [ITI-41]“", eine „XDS"XDS.b Register Document Transaktion [ITI-42]“ " oder eine „XDS "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"ELGA-Hash“ Hash" gespeichert.

<pre class="orangeilfbox_code">

|-==Einzelnachweise==|[2]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2<references />==Literatur und Weblinks ==* IHE International https: Ärztlicher Entlassungsbrief//www. ihe.net/|-* HL7® International http://www.hl7.org/| || ELGA CDA Implementierungsleitfäden * Clinical Document Architcture (2.06CDA®) [OID 1.Release 2.40.0https://www.34hl7.org/implement/standards/product_brief.cfm?product_id=7* DICOM® — Digital Imaging and Communications in Medicine https://www.2dicomstandard.6], httporg/* Österreichische CDA Implementierungsleitfäden [https://wwwwiki.elgahl7.gvat/index.atphp?title=Implementierungsleitf%C3%A4den HL7 Austria Wiki]

|-|[4]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Laborbefund===Hauptversion 3. |-| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.400.0.34.7.4.6], http://www.elga.gv.at |-|[5]|| ELGA GmbH (20152021) HL7 Implementation Guide for CDA® R2: Befund bildgebende Diagnostik. ===|-| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40Diese Hauptversion wurde auf Basis der neuen Vorgaben aus dem Allgemeinen Implementierungsleitfaden 3.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.0grundlegend überarbeitet und umstrukturiert.34.7.8.6], http://www.elga.gv.at |Hinzugekommen sind die Vorgaben für die Registrierung von DICOM KOS-|[7]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: |-| || Pflegesituationsbericht (2Objekten.06) [OID 1Auf eine Revisionsliste mit direktem Vergleich zur Vorversion wurde daher verzichtet.2.40.0.34.7.12.6], http://www.elga.gv.at |-|[8]|| ELGA GmbH (2015) Organisationshandbuch. |-| || ELGA-Bereiche und Krankenanstalten (2.2.1) [OID 1.2.40.0.34.3.1.2.1.32], httpDie relevanten Änderungen sind://www.elga.gv.at|} ==Revisionsliste==

|0.05|16.05.2011|Ergebnisse aus dem technischen Online-Meeting|-|2.00 Beta|12.08.2011|Erster „Release candidate“ des Dokuments für internen Review innerhalb der Arbeitsgruppe.|-|2.00 rc1|30.08.2011|Redaktionelle Überarbeitung.|-|2.00 FWGD|10.10.2011|Fertigstellung des „Final Working Group Draft“. Veröffentlicht für öffentlichen Review.|-|2.01|11.06.2012|Fertigstellung der gültigen Version 2.01 „Final“. <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|-|2.01|21.12.2012|Layout-Anpassung|-|2.01a|07.03-2013|Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16: "dieses Dokuments“ eingefügt; 363: displayNameOf($code), „Of“ gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch „2“-> „Enhanced“ etc.) <br />Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt <br />Allgemein: Typos ausgebessert|-|2.02|12.08.2013|2.3.2 Präzisierung Korrektur der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessert.|-|2.02|12.08.2013|2.3.2.3 PDF/A-1a-Vorschrift hinzugefügt|-|2.02|13.08.2013|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF/A-1a-|-|2.02|17.09.2013|Typos, Formatierung und Seitenumbrüche ausgebessert|-|2.02a|06.02.2014|Beispiele in Tabelle 3 korrigiert|-|2.03|26.02.2014|Definition von ReferenceIdList eingefügt|-|2.03|03.03.2014|Definition von intendedRecipient eingefügt|-|2.03|03.03.2014|Änderungen in Tabelle 3: <br /> LegalAuthenticator – von [R] auf [R2] geändert<br /> IntendedRecipient – Strukturierung 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|-|2.03.|03.03.2014|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|-|2.03|03.03.2014|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|-|2.03|06.03.2014|Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId|-|2.03|21.03.2014|Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt|-|2.03|26.03.2014|Kapitel 1.4. Korrektur von Dokumentverweisen|-|2.03a|28.03.2014|Kapitel 2.1 Korrektur von Fußnotennummern|-|2.03a|28.03.2014|Kapitel 2.2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000|-|2.03b|1.7.2014|Den Namen des Value Sets von „ELGA-PracticeSetting Code-vs“ auf „ELGA_Practicesetting_VS“ korrigiert|-|2.03b|11.07.2014|2.3.2.5 OID in der Spezifikation ergänzt|-|2.03b|11.07.2014|2.3.6 OID in der Spezifikation ergänzt|-|2.03b|05.08.2014|2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert|-|2.03b|06.08.2014|2.1 Überblickstabelle: ParentDocumentId und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]|-|2.03b|06.08.2014|Referenzen auf CDA Implementierungsleitfäden aktualisiert|-| colspan="3" |Version 2.05|-|2.05|03.11.2014|EntryUUID als „ELGA-Relevant“ klassifiziert.<br /> Darstellung innerhalb der Übersichtstabelle geändert|-|2.05|03.11.2014|2.2.15 TypeCode: ClassificationScheme im XML Beispiel korrigiert von "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143aSnippets zu " (falsch) auf "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" (richtig)|-|2.05|19.11.2014|2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht|-|2.05|19.11.2014|2.2.2. authorPerson: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.|-|2.05|19.11.2014|2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden|-|2.05|19.11.2014|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software|-|2.05|24.11.2014|2.2.1.1. Spezifikation von authorInstitution: Fall entfernt, in dem die ID des GDA unbekannt ist. Die OID des GDA ist für ELGA-CDA [M]|-|2.05|26.11.2014|2.4 ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und ELGA-Flag. Auch in 2.1 entsprechend angegeben.|-|2.05|12.03.2014|Seite 2-3: Absätze „Verbindlichkeit“, „Hinweise zur Verwendung“ und „Erarbeitung des Implementierungsleitfadens“ hinzugefügt.|-| colspan="3&amp;amp;" |Version 2.06|-|2.06|19.05.2015|1.2.2. Codesysteme und Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.|-|2.06|13.10.2015|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch|-|2.06|13.10.2015|1.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.|-|2.06|07.10.2015|1.4.3. Kapitel „Metadaten aus „On-Demand Documents“ (ODD)“ eingefügt|-|2.06|10.09.2015|2.1 Tabelle 3: Beschreibung der entryUUID ergänzt

|2.06|07.10.2015|2.1 Tabelle 3"referenceIdList": 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)Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId

|2.06|30.10.2015|2.2.1 AuthorInstiitution"Überblickstabelle der XDS Metadaten": Präzisiert, dass id[1] gemappt wird, falls mehrere ID-Elemente angegeben sindOptionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.

|2.06|19.05.2015|2.2.5. "Spezifikation": Verbot von CR und 2.2LF hinzugefügt.15: Typos verbessert

|2"Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.06|29.10.2015|2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt

|2"sourcePatientInfo" angepasst.06|21.07.2015|2.2.10. legalAuthenticator: HinweisName, Geschlecht, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar ist.Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich

|2"legalAuthenticator" angepasst.06|08Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.10.2015|2.3.7 objectType hinzugefügt

| colspan="3creationTime" |'''Version 2: Bedeutung von ClinicalDocument.06.2 (Nebenversion)'''<br /> x …betrifft Implementierung (erste Spalte)effectiveTime präzisiert

||01.08.2016|Kapitel Verbindlichkeit"healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Definition der Angabe verbindlicher VorgabenAbleitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.

||18.5.2016|1.2 Erklärung zur Verwendung von XDS Folder "formatCode (und SubmissionSet formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.

||01.08.2016|2.1. Tabelle 3"Spezifikation": Korrektur der Optionalität von eventCodeList auf [R2], wie im Text bei 2Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.2classCode hinzugefügt.8 angegeben

|x|14.6.2016|creationTime, serviceStartTime, serviceStopTime: Präzisierung der Vorgaben "XDS-I Metadaten für Datum/Zeit, sie MUSS immer entsprechen der Angabe in CDA entweder 8 oder 14-stellig angegeben werdenDICOM KOS Objekte" hinzugefügt.

||03.08.2016|2.2.5, 2.3.2.2, 2.3.2.5, 2.3.5, 2.3.5.1, 2.3.5.1, 2.1, 1.4, 2.2.7, 2.2.11, 2.2.15, 2.3.6, 1.4.1.2 Korrektur der Großschreibung bei normativen Vorgaben|-||05.01.2017|2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.|-||y|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;amp;"|-||y|Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Ergänzung der Verwendung einer UUID in ClinicalDocument/setId|-||y|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.|-||y|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.|-||y|Kapitel 4.3.3 "healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.encounterId