683
Bearbeitungen
Änderungen
keine Bearbeitungszusammenfassung
{{#seo:
|title=XDS Metadaten 20203.0.2
|titlemode=append
|keywords= XDS Metadaten, Metadaten, XDS, CDA, CDA Dokumente
|description=Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS).
}}
{{#customtitle:XDS -Metadaten 2020}}{{Underconstruction(Version 3.0.2+20240715)}}
<!--
{{Underconstruction}} --><!-- Implementierungsleitfaden "XDS -Metadaten 2020(Version 3)"
-->
{{Infobox Dokument
|Group = ELGA CDA Implementierungsleitfäden|Title = ELGA Implementierungsleitfaden XDS -Metadaten (XDSDocumentEntry)|Subtitle Title = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA (Version 3)|Subtitle = Zur Anwendung im österreichischen Gesundheitswesen [1.2.40.0.34.7.6.79.3]|Short = XDS -Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.02+20240715
|Submitted = ELGA GmbH
|Date = Februar 01.10.2021
|Copyright = 2011-
|Status = KommentierungNormativ
|Period = n.a.
|OID = 1.2.40.0.34.7.6.79.3
|Realm = Austria
}}
{{TOC limit|4}}
<!--
<!--
{{Infobox Contributors Begin}}
{{Contributor | Logo = Logo.jpg | Name = Abc | Location = Hürth Wien}}
{{Infobox Contributors End}}
-->
}
}}
=Zusammenfassung=
{{BeginYellowBox}}
Dieses Dokument beschreibt die IHE XDS Metadaten (XDSDocumentEntry), die für die Registrierung von Befunden (HL7 CDA Dokumenten ) und Bilddaten (DICOM KOS) in der ELGA Infrastruktur notwendig sind und wie sie aus den CDA Dokumenten zugrundeliegenden Informationsobjekten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden [https://wiki.hl7.at/index.php?title=ILF:XDS_Metadaten_Guide XDS-Metadaten-Guide ] im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für elektronische die Registrierung elektronischer Dokumente in der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012)<ref name="GTelG">Gesundheitstelematikgesetz 2012 [https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20008120 https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20008120]</ref>. Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti IHE ITIhttps://www.ihe.net/resources/technical_frameworks/#iti]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref>. Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte sowie DICOM Key Object Selection Documents (in Folge KOS)<ref name="ELGADICOM" gemäß Gesundheitstelematikgesetz 2012 >NEMA PS3 / ISO 12052, Digital Imaging and Communications in Medicine (GTelG 2012DICOM®)Standard, National Electrical Manufacturers Association, Rosslyn, VA, aber auch für medizinische Dokumente im österreichischen GesundheitswesenUSA.<br />TODO: XDSi-Metadaten einfügen httpsUnter ständiger Weiterentwicklung, die aktuelle Version ist frei verfügbar auf http://collabdicom.dicom-austrianema.atorg/pages/viewpage).action?pageId=20709391&preview=</20709391/20709392/AnbindungBilddaten_Gesamtarchitekturref>.pdf
=Informationen über dieses Dokument=
Die Verwendung dieses Leitfadens für die Zwecke der Erstellung, des Verkaufs und des Betriebs von Computerprogrammen, sofern nicht anders angegeben oder sich die Standards auf andere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen, ist ausdrücklich genehmigt. <br />
Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> . <!-- Seitenumbruch --><p style="page-break-before: always"><br /p>
===Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")===
<div style="border: thin #77c123 solid;width:100%; margin-left: 10px">
Die Verbindlichkeit und die Umsetzungsfrist von Leitfäden sind im Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.
Ein Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf [http://www.gesundheit.gv.at www.gesundheit.gv.at] zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten („Mandatory“ ("Mandatory" [M)], „Required“ ("Required" [R) ] und „Fixed“ ("Fixed" [F)]), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.
Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit der Rechtsordnung der Republik Österreich österreichischem und europäischem Recht, insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz 2000, Gesundheitstelematikgesetz 2012, DSGVO) zu erfolgen. Technische Möglichkeiten können gesetzliche Bestimmungen selbstverständlich nicht verändern, vielmehr sind die technischen Möglichkeiten im Einklang mit den Gesetzen zu nutzen.
Die Einhaltung der gesetzlichen Bestimmungen liegt im Verantwortungsbereich der Ersteller der CDA-Dokumente.
==Verwendete Grundlagen und Bezug zu anderen Standards==
Grundlage dieses Implementierungsleitfadens ist der internationale Standard IHE ITI Cross-enterprise Document Sharing <ref name="IHE ITI"></ref> von Integrating the Healthcare Enterprise (IHE)<ref name="IHE">Integrating the Healthcare Enterprise (IHE) International, Incorporated [http://www.ihe.net http://www.ihe.net]</ref>.
Weiters bezieht sich dieser Leitfaden auf den internationalen Standard "HL7® Clinical Document Architecture, Release 2.0" (CDA ®)<ref name="CDA"></ref> , für die das Copyright © von Health Level Seven International<ref name="HL7">Health Level Seven International [http://www.hl7.org www.hl7.org]</ref> gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert<ref name="ISO CDA">ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical Document Architecture, Release 2 [https://www.iso.org/standard/44429.html 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_2020Allgemeiner_Implementierungsleitfaden_(Version_3) https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_(Version_3)]</ref> definiert.Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at]). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020Version 3]'''und gilt entsprechend für alle CDA-Dokumente, die auf Basis des Leitfadens erstellt werden.
{{EndILFBox}}
==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website TODO: [[ILF:Ambulanzbefund_GuideXDS_Metadaten_Guide|Ambulanzbefund XDS 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="ELGA-Gesamtarchitektur">ELGA-Gesamtarchitektur 2.30a [http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>
*Beispieldokumente
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
*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}}
==Bedienungshinweise==
===Farbliche Hervorhebungen und Hinweise===
''<u>Themenbezogene Hinweise zur besonderen Beachtung:</u>''
{{BeginYellowBox}}
'''<Hinweis:>'''<br />Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
{{EndYellowBox}}
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>
''<u>Verweis auf ELGA Value Set:</u>''
{{BeginILFBox}}
'''<Verweis>'''<br/>Zulässige Werte gemäß Value Set '''"ELGA_FormatCode".'''
{{EndILFBox}}
<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">
</div></div>
=Harmonisierung=
'''Erarbeitung des Implementierungsleitfadens'''<br/>
Dieser Implementierungsleitfaden entstand in Zusammenarbeit der nachfolgend genannten Personen:
{| class="wikitable"
|-
! colspan="2" style="text-align:left" |Autoren|- ! style="text-align:left" width="10%" |Organisation|| style="text-align:left" width="60%" |Person<sup>1</sup>|- style="background:#FFEBAD"| colspan="2" style="text-align:left" |Herausgeber, Projektleiter, CDA-Koordinator|- |ELGA GmbH||Stefan Sabutsch|- style="background:#FFEBAD"| colspan="32" style="text-align:left"| Autoren|- |CodeWerk Software Services and Development GmbH||Jürgen Brandstätter|-|DICOM Austria|Emmanuel Helm|-|DICOM Austria|Silvia Winkler|- |ELGA GmbH, HL7 Austria||Stefan Sabutsch|- |ELGA GmbH||Oliver Kuttin|-|ELGA GmbH|Stefan Repas
|-
|}
<sup>1</sup> Namen ohne Titel
<!--Einleitung-->
=Einleitung=
==Intention und Abgrenzung ==
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. Eine IHE XDS Registry verwaltet Dokumente und macht diese zufänglich. Sie erlaubt die Suche und das Filtern nach den Dokumenten über die Metadaten der Dokumente (Metadaten sind Daten, die andere Daten definieren und beschreiben). Werden wie für ELGA mehrere Registries gemeinsam genutzt, müssen die Metadaten übergreifend harmonisiert werden und Metadatenstandards bereitgestellt werden: Wertebereiche, Abhängigkeiten, Zuständigkeit, Abbildungsregeln, Versionierung und Policies.
Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.
==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumentenin Form von Befunden<ref name="ALF"></ref> oder Bilddaten in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden „Technical Frameworks“ "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. 1712.0 (1622.94.20202016) Final Text''<ref name="IHE ITI TF-3ITITF3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 1712.0 (20202016)[https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf], zuletzt besucht am 25.01.2021</ref> 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 CDA Implementierungsleitfäden“ ELGA Bilddatenaustausch [https://collab.dicom-austria.at/pages/viewpage.action?pageId=27033635 DICOM Austria KOS Leitfaden], zuletzt besucht am 19.02.2021</ref> erstellt.
===XDS Folder===
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
===XDS Submission Sets===
Etwaige, Service-spezifische, Vorgaben auf Schnittstellen-Ebene sind in den entsprechenden Schnittstellenspezifikationen (u.a. Schnittstellen Berechtigungssystem, Schnittstellenspezifikation zur Anbindung des elektronischen Impfpasses) angeführt und im Rahmen konkreter System-Anbindungen zu berücksichtigen.
==Hinweise zur Verwendung des Dokuments==
===Codesysteme und Value Sets===
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.
Wenn codierte Werte angegeben werden, ist es immer die Aufgabe des Document Consumers, die korrekten lesbaren Werte anzuzeigen. Es wird nicht empfohlen, die in den XDS-Metadaten verfügbaren DisplayNames direkt zur Anzeige zur verwenden, da Schreibweisen der DisplayNames variieren oder in unterschiedlichen Sprachen angegeben sein können.
===OID ===
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/).
==Allgemeines zu Dokumenten in ELGA==
Für die erste Umsetzungsphase von ELGA wurden die Dokumentenklassen Entlassungsbrief (Ärztlich, Pflegerisch), Laborbefund und Befunde der bildgebenden Diagnostik („Radiologiebefunde“"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-Implementierungsleitfäden"ersichtlich. Nur über eine Verordnung definierte Dokumentenklassen dürfen in ELGA verwendet werden, alle Dokumente MÜSSEN entsprechend der Spezifikationen der ELGA CDA-Implementierungsleitfäden erstellt werden.
===Dokumentlebenszyklus und XDS-Transaktionen===
ELGA unterstützt die im Folgenden folgenden aufgezählten Aktionen (in Klammer die entsprechende ITI-Transaktion). Alle Transaktionen werden in den Protokollierungssystemen aufgezeichnet:
====Bereitstellen [ITI-41] und Veröffentlichen [ITI-42]====
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]====
Änderungen eines für ELGA bereitgestellten Dokumentes sind NICHT ERLAUBT.
Es ist allerdings möglich, ein Dokument durch ein anderes zu ersetzen, indem ein neues Dokument (bzw. eine neue Version des Dokumentes) gespeichert und registriert wird, . Hierbei MUSS die SetId der referenceIdList in den XDS-Metadaten zum neuen Dokument der der Vorgängerversion entsprechen. Die XDS-Metadaten der Vorgängerversion des 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)).
Beim Ersetzen von ELGA Dokumenten wird das ELGA Berechtigungssystem eventuell zugeordnete individuelle Zugriffsberechtigungen unabhängig von ihrer Anzahl auch auf die Nachfolgeversionen anwenden.
====Stornieren [ITI-57, XDS Metadata Update]====
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].
===Größenbeschränkung ===
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]].
==Allgemeines zu XDS-Metadaten==
Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumente entsprechend klassifiziert und beschrieben werden. Diese beschreibenden „Metadaten“ "Metadaten" werden in Form einer Nachricht gemeinsam mit dem Dokument an das Repository mitgegeben. Da IHE XDS Systeme grundsätzlich für beliebige Dokumentformate offen sind, gilt dies für alle Arten von Dokumenten (CDA, PDF, Bilder, etc.) gleichermaßen.
Die Metadaten eines Dokuments (XDSDocumentEntry) in einem IHE XDS System beinhalten Informationen
* über den GDA, welcher das Dokument erstellt hat
* über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).
Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE „IT"IT-Infrastructure“ Infrastructure" (ITI) Technical Framework, Volume 3 festgelegt (IHE ITITF-TF33).<ref name="IHE ITI TF-3ITITF3"></ref>.
Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.
{{EndYellowBox}}
'''Hinweis:''' Sehen Sie Siehe auch die Vorschrift Vorschriften zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3ITITF3"></ref> .
===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument oder binären Objekt entnommen werden und müssen daher von der erstellenden Anwendung mitgegeben werden. Es entsteht dadurch ein zusätzlicher Aufwand insbesondere hinsichtlich der Qualität der Daten. Die Metadaten müssen das beiliegende Dokument oder binäre Objekt korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.
===Metadaten aus strukturierten Dokumenten (CDA)===
Strukturierte Dokumente bieten die Möglichkeit, die Informationen für die Metadaten beim Einbringen in ein Repository in gewissem Maße aus den Dokumenten selbst automatisiert zu entnehmen. Das vermindert daher die Menge der Informationen, die separat erhoben oder ermittelt werden muss.
Die IHE hat im Rahmen des „Patient "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 11.0, Volume 2, Kapitel XDSDocumentEntry Metadata beschrieben.<ref name="IHEPCC">IHE ITI">Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2 [https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf]</ref>
===Metadaten aus „On"On-Demand Documents“ Documents" (ODD) ===Über XDS können auch Dokumente abgerufen werden, die zum Abfragezeitpunkt automatisch generiert werden. Für diese Dokumente werden Verweise in der Registry eingetragen, damit sie bei der Abfrage auch gefunden werden können. Die Metadaten von ODD unterscheiden sich notwendigerweise von den Metadaten der „stabilen Dokumente“ "stabilen Dokumente" (SD), da sie erst bei Generierung des Dokuments vorhanden sind. Die genaue Beschreibung für On-Demand Documents findet sich IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3ITITF3"></ref>.
===Metadaten aus Bilddaten (KOS)===
===XDS Metadaten im Vergleich IHE vs. ELGA===
# Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
# Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)
# '''Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können(XDS Document Source)'''
# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
## '''ELGA relevante'''
Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).
==Überblickstabelle der XDS-I Metadaten für DICOM KOS Objekte==
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 />''Tabelle 1: Legende zur Spalte „Quelle“ "Quelle" der folgenden Tabelle''
{| class="wikitable" width="100%"
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
|}
''Tabelle 2: Legende zur Spalte „Optionalität“ "Optionalität" der folgenden Tabelle ''
{| class="wikitable" width="100%"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|RM||Verpflichtend 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”"required")''.
|- style="background:white"
|R2R||Verpflichtend wenn 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 "required if Known“known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|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"'')
|}
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" rowspan="2" |'''Metadaten Element'''
|'''Optionalität'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''RM [1..1]'''|Die Person, welche das Dokument verfasst hat
|<nowiki>-</nowiki>
|Die Person oder das Gerät, welche(s) das Dokument verfasst hat
|-
| rowspan="4" |
|authorInstitution
|'''RM [1..1]'''|E1/K|ID der Organisation , der die Person angehört (OID aus dem GDA-Index)|A/K
|-
|authorPerson
|'''R2R [0..1]'''|K|Daten der Person.
(Name, ID, etc.)
|-
|authorRole
|'''R2R [0..1]'''|K
|Rolle der Person
|-
|authorSpeciality
|'''R2R [0..1]'''|E1/K
|Fachrichtung der Person
|-
| colspan="2" |'''classCode'''
|'''RM [1..1]'''|A
|Dokumenten/Objektklasse (Oberklasse)
z.B.: 55113-5 „KOSObjekte“|A"Key images Document Radiology"
|-
| colspan="2" |'''confidentialityCode'''
|'''RM [1..1]'''|Vertraulichkeitscode. Fester Wert „N“
|A
|Vertraulichkeitscode. Fester Wert "N"
|-
| colspan="2" |'''creationTime'''
|'''RM [1..1]'''|Zeitpunkt der Dokumentenerstellung
|K
|Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes
|-
| colspan="2" |'''eventCodeList'''
|'''RM [1..*]'''|A/K
|Liste von Codes von Gesundheitsdienstleistungen
|-
| colspan="2" |'''eventCodeDisplayNameListeventCodeDisplayName'''|'''R2M [1..1]'''|Liste von Gesundheitsdienstleistungen
|A/K
|Bezeichnung von Gesundheitsdienstleistungen nach APPC
|-
| colspan="2" |'''intendedRecipient'''
|'''ONP [0..0]'''| -|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.|
|-
| colspan="2" |'''languageCode'''
|'''RM [1..1]'''|Sprachcode. Fester Wert „de-AT“
|A
|Sprachcode. Fester Wert "de-AT"
|-
| colspan="2" |'''legalAuthenticator'''
|'''ONP [0..0]'''| -
|Rechtlicher Unterzeichner
|-
| colspan="2" |'''serviceStartTime'''
|'''RM [1..1]'''|K
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|-
| colspan="2" |'''serviceStopTime'''
|'''ONP [0..0]'''| -
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
|-
| colspan="2" |'''sourcePatientId'''
|'''RM [1..1]'''|Patienten ID im Informationssystem des GDA. z.B.: im RIS
|K
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|-
| colspan="2" |'''sourcePatientInfo'''
|'''RNP [0..0]'''| -|Demographische Daten des Patienten im Informationssystem des GDA (, z.B.: im RIS)|K
|-
| colspan="2" |'''Titletitle'''|'''RM [1..1]'''|A/K
|Titel des Dokuments
|-
| colspan="2" |'''typeCode'''
|'''RM [1..1]'''|A
|Objekttyp (Unterklasse)
codierter Wert
|-
| colspan="2" |'''uniqueId'''
|'''RM [1..1]'''|n K|Global eindeutige ID des Objektes.
z.B. SOP Instance UID
|-
| colspan="2" |'''referenceIdList'''
|'''RM [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'''
|'''RM [1..1]'''|E1
|Gültigkeit des Objektes
|-
| colspan="2" |'''formatCode'''
|'''RM [1..1]'''|E1
|Format des Objektes
|-
| colspan="2" |'''healthcareFacilityTypeCode'''
|'''RM [1..1]'''|E1
|Klassifizierung des GDA
|-
| colspan="2" |'''mimeType'''
|'''RM [1..1]'''|E1
|Mime Type des Dokuments
Fester Wert für KOS: „application"application/dicom“|E1dicom"
|-
| 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'''
|'''RM [1..1]'''|E1
|Fachliche Zuordnung des Dokuments
|-
| colspan="2" |'''entryUUID'''
|'''RM [1..1]'''|E1
|UUID des Metadaten-Records des Dokuments(XDS DocumentEntry)
|-
| colspan="2" |'''objectType'''
|'''RM [1..1]'''|E1|Typ des DocumentEntries.
Fester Wert „SD“|E1"SD"
|-
| colspan="2" |'''comments'''
|'''O[0..1]'''|K
|Kommentar zum Dokument/Objekt
|-
| colspan="2" |'''patientId'''
|'''RM [1..1]'''|E1
|Patienten-ID in der XDS Affinity Domain
|-
| colspan="5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|-
| colspan="2" |'''hash'''
|'''RM [1..1]'''|Hash Wert des Dokuments. Wird vom Repository befüllt.
|A
|Hash Wert des Dokuments. Wird vom Repository befüllt
|-
| colspan="2" |'''homeCommunityId'''
|'''RM [1..1]'''|Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine „Community“, die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.
|A
|Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.
|-
| colspan="2" |'''repositoryUniqueId''' |'''RM [1..1]'''|A
|Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
|-
| colspan="2" |'''size'''
|'''RM [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>-</nowiki>]][[#%20ftn1|''''''[1]''''''<nowiki/>]]|A
|Wird in XDS-I nicht verwendet
|A-
|-
| colspan="5" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|-
| colspan="2" |'''elgaFlag'''
|'''RM [1..1]'''|Kennzeichnet ein Dokument als „ELGA-Dokument“
|B
|Kennzeichnet ein Dokument als "ELGA-Dokument"
|-
| colspan="2" |'''elgaHash'''
|'''RM [1..1]'''|Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes
|B
|Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes
|}
<br />[[#%20ftn1|<nowiki/>]][[#%20ftnref1|[1]]] Dieses Element wird von XDS-I nicht verwendet und ist nur der Vollständigkeit halber angegeben.
<br />
<p style="page-break-before: always"></p>
==Überblickstabelle der XDS Metadaten für HL7 CDA Objekte==
Die folgende Tabelle gibt einen Überblick über alle XDS-Metadaten-Elemente. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in IHE bzw. ELGA für das Einbringen von Dokumenten, sowie die Quelle aus der die Informationen stammen.
In der Tabelle 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. TODO: urn:ihe:iti:xds:2015:encounterId als referenceIdList Eintrag ergänzen?
''Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
|}
''Tabelle 15: Legende zur Spalte „Quelle“ "Optionalität" der folgenden Tabelle''
{| class="wikitable" width="100%"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|RM||Verpflichtend 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”"required")''.
|- style="background:white"
|R2R||Verpflichtend wenn 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 "required if Known“known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|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"'')
|}
''Tabelle 6: Überblick XDS Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''|| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''|| rowspan="2" style="text-align:left" width="455%" |'''Beschreibung Quelle'''|| rowspan="2" style="text-align:left" width="5%" |'''QuelleBeschreibung '''
|- style="background:#CBD7F1"
|'''SD'''<sup>9</sup>||'''||ODD'''OD<sup>10</sup>'''
|- style="background:#CBD7F1"
| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''
|- style="background:white"
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''RM [1..1]'''||'''RM [1..1]'''|C||Die Person, welche das Dokument verfasst hat||-
|- style="background:white"
| ||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:white"
| ||authorPerson||'''RM [1..1]'''||'''RM [1..1]'''|C||Daten der Person. (Name, ID, etc.)||C
|- style="background:white"
| ||authorRole||'''R2R [0..1]'''||'''XNP [0..0]'''|C||Rolle der Person||C
|- style="background:white"
| ||authorSpeciality||'''R2R [0..1]'''||'''XNP [0..0]'''|C||Fachrichtung der Person||C
|- style="background:white"
| colspan="2" |'''classCode'''||'''RM [1..1]'''||'''RM [1..1]'''|C||Dokumentenklasse (Oberklasse)<br />z.B.: 18842-5 „Entlassungsbrief“||C"Entlassungsbrief"
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''RM [1..1]'''||'''XNP [0..0]'''|C||Vertraulichkeitscode des Dokuments||C
|- style="background:white"
| colspan="2" |'''creationTime'''||'''RM [1..1]'''||'''RNP [0..0]'''|C|Zeitpunkt der Dokumentenerstellung||CMedizinisch relevantes Datum, je nach Definition im speziellen Leitfaden
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R2R [0..*]'''||'''R2R [0..*]'''|C||Liste von Gesundheitsdienstleistungen||C
|-
| colspan="2" |'''formatCode'''
|'''RM [1..1]'''|'''RM [1..1]'''|C
|Format des Dokumenteninhalts
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O[0..1]'''||'''XNP [0..0]'''|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C
|- style="background:white"
| colspan="2" |'''languageCode'''||'''RM [1..1]'''||'''RM [1..1]'''|C||Sprachcode des Dokuments<br />z.B.: "de-AT"||C
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R2R [0..1]'''||'''XNP [0..0]'''|C||Rechtlicher Unterzeichner des Dokuments||C
|-
| colspan="2" |'''practiceSettingCode'''
|'''RM [1..1]'''|'''RM [1..1]'''|C
|Fachliche Zuordnung des Dokuments
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R2R [0..1]'''||'''O[0..1]'''|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R2R [0..1]'''||'''O[0..1]'''|C||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung||C
|- style="background:white"
| 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:white"
| colspan="2" |'''sourcePatientInfo'''||'''XNP [0..0]'''||'''XNP [0..0]'''|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C
|- style="background:white"
| colspan="2" |'''Title'''||'''RM [1..1]'''||'''RM [1..1]'''|C||Titel des Dokuments||C
|- style="background:white"
| colspan="2" |'''typeCode'''<sup>11</sup>||'''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:white"
| colspan="2" |'''uniqueId'''||'''RM [1..1]'''||'''RM [1..1]'''|C||Global eindeutige ID des Dokuments||C
|- style="background:white"
| 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||C
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''RM [1..1]'''||'''RM [1..1]'''|C||Klassifizierung des GDA|C
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
|- style="background:white"
| colspan="2" |'''availabilityStatus'''||'''RM [1..1]'''||'''RM [1..1]'''|E1||Gültigkeit des Dokuments||E1
|- style="background:white"
| colspan="2" |'''mimeType'''||'''RM [1..1]'''||'''RM [1..1]'''|E1||Mime Type des Dokuments<br />z.B.: „text"text/xml“ xml" für CDA||E1
|- style="background:white"
| colspan="2" |'''parentDocumentId'''<sup>12</sup>||'''O[0..1]'''||'''O[0..1]'''|E1||Verweis auf ein referenziertes Dokument||E1
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''<sup>13</sup>||'''O[0..1]'''||'''O[0..1]'''|E1||Typ der Relation zu dem referenzierten Dokument.<br />z.B.: RPLC, XFRM||E1
|- style="background:white"
| colspan="2" |'''entryUUID'''||'''RM [1..1]'''||'''RM [1..1]'''|E1||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)||E1
|- style="background:white"
| colspan="2" |'''objectType'''||'''RM [1..1]'''||'''RM [1..1]'''|E1||Typ des DocumentEntries (SD oder ODD)||E1
|- style="background:white"
| colspan="2" |'''comments'''||'''O[0..1]'''||'''O[0..1]'''|E2||Kommentar zum Dokument||E2
|- style="background:white"
| colspan="2" |'''patientId'''||'''RM [1..1]'''||'''RM [1..1]'''|E1||Patienten-ID in der XDS Affinity Domain||E1
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|- style="background:white"
| colspan="2" |'''hash'''||'''RM [1..1]'''||'''XNP [0..0]'''|A||Hash Wert des Dokuments. Wird vom Repository befüllt.||A
|- style="background:white"
| 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:white"
| 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:white"
| colspan="2" |'''size'''||'''RM [1..1]'''||'''XNP [0..0]'''|A||Größe des Dokuments in Bytes. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''URI'''<sup>14</sup>||'''-NP [0..0]'''||'''-NP [0..0]'''|A||<span style="color:red;">'''Wird in XDS nicht verwendet'''</span>||A
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|- style="background:white"
| colspan="2" |'''elgaFlag'''||'''RM [1..1]'''||'''RM [1..1]'''|B||Kennzeichnet ein Dokument als „ELGA"ELGA-Dokument“||BDokument"
|- style="background:white"
| colspan="2" |'''elgaHash'''||'''RM [1..1]'''||'''RM [1..1]'''|B||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B
|}
<sup>9</sup> SD: „Stable Document“"Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht.<br /><sup>10</sup> ODODD: „On"On-demand Document“Document": Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird. <br /><sup>11</sup> Der Inhalt des typeCodes soll mit dem contentTypeCode des SubmissionSets Submission Sets übereinstimmen.<br /><sup>12</sup> MUSS vorhanden sein, wenn eine „parentDocumentRelationship“ "parentDocumentRelationship" existiert. <br /><sup>13</sup> MUSS gemeinsam mit einer „parentDocumentId“ "parentDocumentId" angegeben sein.<br /><sup>14</sup> Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.<p style="page-break-before: always"></p>
=XDS-I Metadaten für DICOM KOS Objekte=
'''Achtung:''' Das DICOM-Tag (0008,0080), Institution Name, Dieses Attribut 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.
|- 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
'''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=====Spezifikation====="background:white"|||'''Alternativ:'''
Enthält dieses Attribut mehrere Namen, so ist der erste Name zu wählen.
siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten<nowiki/>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</ref>
|- style="background:white"
|
|eventCodeList<br />DisplayNameList
|M [1..1]
|
|
|Enthält den Display Name des APPC
(0010,0040)
|(0010,0020)
'''authorPersonAnmerkung:''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
(0040,1001) Requested Procedure ID
<br />
|(0008,0050)
<br />
|Die ID, die zur Verlinkung mit dem Befund heranzuziehen ist.
'''authorPersonAchtung:''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
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.
|}
====authorRole=Spezifikation=====Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der Dokumentation innehatte.
<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="authorSpecialityauthorInstitution">
<ValueList>
<Value>Fachärztin/Facharzt für RadiologieUnfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO </Value>
</ValueList>
</Slot>
</Classification>
</pre>
#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====Spezifikation===="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}}'''classCode (und classCodeDisplayName)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 als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br />, die die maßgeblichen Teile der Studie verantwortet.
'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
$id ===confidentialityCode===Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.Code #1 aus (0008,1052) Performing Physicians Identification Sequence
concat(<br /><span> $id</span>,"^",<br /><span> $person</span><br />)<br /><pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:f4f85eac93606bcf-e6cb9494-488343ec-b5249b4e-f2705394840fa7748d1a838d" classifiedObject="theDocumenturn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" nodeRepresentation id="Nurn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037"> <Name> <LocalizedString valuenodeRepresentation="normal"/> </Name> <Slot name="codingSchemeauthorPerson">
<ValueList>
<Value>urn:oid:2.16.840999.1.1138832.53.251375^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=====
$date = (0008Modality,0020) Study Date – oder (0008"^",0023) Content Date
$time = (0008Manufacturer,0030) Study Time - oder (0008"^",0033) Content Time +(0008,0201) Timezone Offset from UTC
$ManufacturersModelName
<pre class="ilfbox_code">
<Classification classificationScheme= "urn:uuid:2c6b8cb793606bcf-8b2a9494-405143ec-b2919b4e-b1ae6a575ef4a7748d1a838d" classifiedObject="theDocumenturn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="$code"> <Slot name="codingSchemeauthorSpeciality">
<ValueList>
<Value>urn:oid:$codeSystemFachärztin/Facharzt für Radiologie</Value>
</ValueList>
</Slot> <Name> <LocalizedString value="$displayName"/> </Name>
</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====
'''languageCodeclassCode (und classCodeDisplayName)''' wird als ebRIM Slot 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)
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82f41a5887f-054d8865-47f24c09-a032adf7-9b2a5b5186c1e362475b143a" statusclassifiedObject="theDocument" nodeRepresentation="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved$code"> id<Name> <LocalizedString value="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be$displayName"/> </Name> <Slot name="languageCodecodingScheme">
<ValueList>
<Value>de-ATurn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</ExtrinsicObjectClassification>
</pre>
===legalAuthenticatorconfidentialityCode===Dieses Das ''confidentialityCode'' Element darf für XDS-I nicht verwendet werden [NP]beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.
====Spezifikation====
<ValueList>
<Value>20100511134500urn:oid:2.16.840.1.113883.5.25</Value>
</ValueList>
</Slot>
</ExtrinsicObjectClassification></pre>{{BeginYellowBox}}Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 20160518 in 20160518000000).
====Spezifikation====
'''sourcePatientIdcreationTime''' wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />
$patientID date = (00100008,0020) Patient IDStudy Date oder (0008,0023) Content Date
$oid time = OID des lokalen Patientenidentifikators(0008,0030) Study Time oder (0008,0033) Content Time und (0008,0201) Timezone Offset from UTC
concat(
$patientIDdate,
<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="sourcePatientIdcreationTime">
<ValueList>
<Value>4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
<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="sourcePatientInfolanguageCode">
<ValueList>
<Value>PIDde-3|$id</Value><Value>PID-5|$name</Value><Value>PID-7|$birthtime</Value><Value>PID-8|$gender</Value><Value>PID-11|$addrAT</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
#Wenn die Informationen Das Erstellungsdatum der Studie (aus dem KOS Objekt oder bevorzugt der DICOM Studie verfügbar sind): Study Description#*Study Date (0008,00600020) Modality (Modality Codes aus der DICOM Studie) +#*Study Time (0008,10300030) Study Description, Datentyp LO#Wenn mehrere Modailty Codes Alle Zeiten müssen in XDS in der Studie verfügbar sindUTC konvertiert werden, soll entweder die relevante Modality verwendet daher sollte Timezone Offset From UTC berücksichtigt werden oder alle zum Titel hinzugefügt werden., falls angegeben:#Wenn Study Description nicht angegeben ist*Timezone Offset From UTC (0008, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. („CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule“0201)
====Spezifikation====
'''serviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
<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">
<NameSlot name="serviceStartTime"> <ValueList> <Value>20100511134500</Value> <LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" /ValueList> </NameSlot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
{{EndYellowBox}}
===typeCode (und typeCodeDisplayName)sourcePatientId===Das ''typeCodesourcePatientId'' Element beschreibt den Objekttyp, dem das KOS Objekt angehört. Der Objekttyp ist die Spezialisierung einer Objektklasse, jeder Objekttyp gehört zu genau einer ObjektklassePatienten ID des Patienten im lokalen Informationssystem des GDA. Für ein Mapping aus KOS steht folgendes Attribut zur Verfügung:
Eine OID zur Definition des Namensraumes des verwendeten Patientenidentifikators muss entsprechend vorhanden sein.
====Spezifikation====
'''typeCode (und typeCodeDisplayName)sourcePatientId''' wird wird als ebRIM Classification zum DocumentEntry umgesetzt und Slot gemäß folgender Vorschrift zusammengesetzt: $patientID = (0010,0020) Patient ID $oid = OID des lokalen Patientenidentifikators
<ValueList>
<Value>urn:oid:$codeSystem4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO</Value>
</ValueList>
</Slot>
</ClassificationExtrinsicObject>
</pre>
====submissionSet.contentTypeCode=sourcePatientInfo===Der contentTypeCode Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des SubmissionSets wird als ebRIM Classification umgesetzt Patienten.{{BeginYellowBox}}In ELGA werden die Elemente name, administrativeGender, birthTime und soll dieselben Werte wie typeCode addr NICHT zur Identifikation des DocumentEntry tragenPatienten 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}}
Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
#Wenn die Informationen aus der Studie verfügbar sind: Study Description#*(0008,00180060) Modality (Modality Codes aus der DICOM Studie) SOP Instance UID +#*(VR0008,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:UI''' Für den Fall, VM:1)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====
)<pre class="ilfbox_code"><ExternalIdentifierExtrinsicObject mimeType="text/xml"registryObject objectType="urn:uuid:1e2ede827edca82f-054d-857047f2-4be2a032-bd469b2a5b5186c1" status="urn:oasis:names:tc:ebxml-de986a4333beregrep:StatusType:Approved"identificationScheme id="urn:uuid:2e82c1f61e2ede82-a0858570-4c724be2-9da3bd46-8640a32e42ab"value="$valuede986a4333be">
<Name>
<LocalizedString charset="UTF-8" value="XDSDocumentEntry.uniqueIdDX Digitales Röntgen des Schädels" xml:lang="de-AT"/>
</Name>
</ExternalIdentifierExtrinsicObject></pre>{{BeginYellowBox}}Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.{{EndYellowBox}}
===referenceIdListtypeCode (und typeCodeDisplayName)===Das referenceIdList ''typeCode'' Element stellt eine Liste von internen oder externen Identifiern darbeschreibt den Objekttyp, dem das KOS Objekt angehört. Der Objekttyp ist die Spezialisierung einer Objektklasse, jeder Objekttyp gehört zu genau einer Objektklasse. Für Bilddaten sind zwei unterschiedliche Einträge in referenceIdList notwendig:
|}
$code = "55113-5"
Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
$value =====Spezifikation=====Bei der Registrierung von KOS Objekten MUSS eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden. (0008,0018) SOP Instance UID
===referenceIdList===
Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:
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.
====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:iheelga:iti:xds:20132014:accessionownDocument_setId</nowiki>", "^", "&amp;", $homeCommunityId, "&amp;ISO"
)
Wie oben angeführt wird folgender CXi Wert für <br /Value>erstellt:<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList> <Value>202011111.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^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>Siehe 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 IHE RAD TF3 4.68.4.1.2bei der Befundschreibung (''report'') verfügbar ist.4Dies trifft auf die Accession Number zu (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).1 “Linking Report to Set of DICOM Instances”
====Weitere Einträge der referenceIDList=Spezifikation=====Über 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 bereits genannten Einträge hinaus sind weitere Einträge 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 erlaubt:hat dem HL7 Datentyp CXi zu folgen (siehe oben).
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</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^^20201111^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^amp;1.2.40.0.34.99.999 <nowiki>&</nowiki>amp;amp;ISO</Value><Value>20201111^^^amp;1.2.40.0.34.99.999 <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value><Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value><Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre><br />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)=intendedRecipient===Für Durch encounterId wird die spätere Verwendung von IHE Cross Enterprise Document Workflow Verlinkung sämtlicher Bilddaten (XDWDICOM KOS-Objekte) ist , 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 ''intendedRecipient'' notwendig. Derzeit zu gruppierenden Objekte strukturiert wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die =====Spezifikation dieses Elementes=====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 ===comments===Das ''comments'' Element enthält Kommentare zum Objekt. Die Verwendung ist in ELGA optional (wird in einigen Implementierungen nicht angezeigt, Aufenthaltszahl z.B. ELGA Bürgerportal)Az123456
)<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>"/> </pre> Slot name===formatCode (und formatCodeDisplayName)===Das ''formatCode'' Element beschreibt das Format des registrierten Objekts. Es ermöglicht einem empfangenden System (''Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Dokumentenformats und somit die korrekte Darstellung und Verarbeitung. ====Spezifikation===='''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: "<br /nowiki><span>$codeurn:ihe:iti:xds:2013:referenceIdList</spannowiki> = "1.2.840.10008.5.1.4.1.1.88.59"<br /> <spanValueList>$displayName </spanValue> = "Key Object Selection Document"Az123456^^^<br /nowiki><span>$codeSystem&</spannowiki> = "amp;amp;1.2.84040.0.1000834.299.4613.63.1"4<nowiki>&<pre class="ilfbox_code"/nowiki>amp;amp;ISO^<Classification classificationScheme="nowiki>urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urnihe:uuiditi:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urnxds:uuid2015:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf" nodeRepresentation="$code"> <Name> encounterId<LocalizedString value="$displayName"/nowiki> </Name> <Slot name="codingScheme"> <ValueList> <Value>urn:oid:$codeSystem </Value> </ValueList> </Slot> </ClassificationExtrinsicObject>
</pre>
===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)=Weitere Einträge der referenceIDList====Das ''healthcareFacilityTypeCode'' Element beschreibt Über die Klassifizierung des GDA, z.B.bereits genannten Einträge hinaus sind weitere Einträge in der referenceIdList erlaubt:
*158 „Fachärztin'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</Facharzt“nowiki>. In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.*304 „Allgemeine Krankenanstalt“'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki>
====Spezifikation=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)
==XDS Metadaten 2: explizit zu setzen (ELGA relevant)=====mimeTypeavailabilityStatus===Das ''mimeType'' availabilityStatus-Element beschreibt den „Internet Media Type“ die Aktualität/Sichtbarkeit des Dokuments gemäß dem „Multipurpose Internet Mail Extensions“ (MIME) Standard. Der Standard wird beschrieben in [https://tools.ietf.org/html/rfc2045 <nowiki>RFC 2045[6]</nowiki>] und RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietfeingebrachten Objektes.org/html/rfc2045 IETF RFC 2045]</ref>
<pre class="ilfbox_code">
<ExtrinsicObject id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" mimeType="applicationtext/dicomxml" objectType="urn:uuid:34268e477edca82f-fdf5054d-41a647f2-ba33a032-82133c4652489b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>
====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:cccf5598a09d5840-8b07386c-4b7746f2-a05eb5ad-ae952c785ead9c3699a4309d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
</pre>
===objectTypehealthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===Das objectType ''healthcareFacilityTypeCode'' Element gibt den Typ beschreibt die Klassifizierung des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen „stabiles Dokument“ (stable document, SD) und „On-demand Dokument“ (on-demand documentGDA, ODD) unterschiedenz. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziertB. Für KOS Objekte wird der fixe Wert "[[urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be]]" für "Stable Document" vorgegeben:<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>
====Spezifikation====
<span>$code </span>= Klassifizierung des GDA (Code)
<span>$displayName </span>= Klartext des angegebenen Codes
<supspan>18$codeSystem </supspan> Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth= 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-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.9198b6deeddf" nodeRepresentation="$code"> <Name> <LocalizedString value="$displayName"/> </Name> <Slot name="codingScheme"> <ValueList> <Value>urn:oid:$codeSystem</Value> </ValueList> </Slot></Classification></pre>
===elgaHashmimeType===Das ''mimeType'' Element beschreibt den "Internet Media Type" des Objektes gemäß dem "Multipurpose Internet Mail Extensions" (MIME) Standard. Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-MetadatensatzesStandard wird beschrieben in RFC 2045<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools. Ein XDS Source des ELGA-Bereiches sendet eine „XDSietf.b Provide org/html/rfc2045 IETF RFC 2045]</ref> und RFC 2049<ref name="RFC2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Register Transaktion Examples [ITI-41]“, eine „XDShttp://tools.ietf.b Register Document Transaktion [ITI-42org/html/rfc2049 IETF RFC 2049]“ 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</ref>.
====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>
{{BeginYellowBox}}
{{EndYellowBox}}
====Spezifikation====
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcfcccf5598-94948b07-43ec4b77-9b4ea05e-a7748d1a838dae952c785ead"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e63134a8d-f1ed9d4c-43454fe0-acabad9b-73f59bc1d0379198b6deeddf" nodeRepresentation="$code"> <Name> <LocalizedString value="$displayName"/> </Name> <Slot name="authorInstitutioncodingScheme">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISOurn: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.
<pre class="ilfbox_code">
<Classification classificationSchemeExtrinsicObject mimeType="application/dicom" objectType="urn:uuid:93606bcf7edca82f-9494054d-43ec47f2-9b4ea032-a7748d1a838d9b2a5b5186c1" classifiedObjectstatus="urn:uuidoasis:names:tc:f0573b34ebxml-ea9a-4c6d-8556-5cffbe50f027regrep:StatusType:Approved" id="urn:uuid:33adae7e1e2ede82-f1ed8570-43454be2-acabbd46-73f59bc1d037" nodeRepresentation=de986a4333be""> <Slot name="authorInstitution"> <ValueList> <Value>Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&amp;ISO^^^^45</Value> </ValueList> </Slot> </Classification>
</pre>
====authorPerson==ELGA-spezifische Erweiterungen der XDS-Metadaten==Das Element ''authorPerson'' beschreibt die Identifikation Die folgenden Daten entsprechen nicht dem IHE-Standard und demographische Informationen der Person oder das Gerät/die Software, welche das Dokument inhaltlich erstellt hat (also nicht die Schreibkraft)werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information. Mindestens eine Person
<pre class="ilfbox_code">
<Classification classificationSchemeSlot name="urn:uuid:93606bcf-9494-43ec-9b4eelga-a7748d1a838d" classifiedObject="urnbes:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="elgaFlag"> <Slot name="authorPerson"ValueList> <ValueList> <Value>2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO true</Value> </ValueList> </Slot> </Classification></pre>{{BeginYellowBox}}Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.{{EndYellowBox}}Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
===elgaHash==Spezifikation =Der elgaHash dient als Prüfkennzeichen für Software 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 Geräte=====im Slot "ELGA-Hash" gespeichert.
<pre class="ilfbox_code">
<Classification classificationScheme="urnrim:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObjectSlot name="urn:uuid:f0573b34-ea9a-4c6d-8556elga-5cffbe50f027" id="urn:uuidbes:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="elgaHash"> <Slot name="authorPerson"> <rim:ValueList> <rim:Value>^Good Health System^Best Health Software Application3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value> </rim:ValueList> </rim:Slot></Classificationpre> =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"/pre> ==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet== ===author===Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
====authorRoleauthorInstitution====Das ''authorRoleauthorInstitution'' Element beschreibt die RolleOrganisation (GDA), die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehattein dessen Gültigkeitsbereich das Dokument erstellt wurde.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
# Laut Festlegung in den ELGA Gesundheitsdaten wird die „Rolle“ Organisation, der Personder Autor des Dokuments angehört, welche das Dokument inhaltlich erstellt hat im grundsätzlich in folgendem Element functionCode des Autors abgelegt:## ''ClinicalDocument/author/functionCodeassignedAuthor/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)# Die Angabe einer Rolle ##@extension … Eigentliche ID des Autors ist in ELGA ein verpflichtendes 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, wenn vorhanden einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''[R2]'entsprechen (im GDA-I im Tag ''"descriptor"''enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird.<br /> Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz"<br />Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung. #GDA, in deren Gültigkeitsbereich Dokumente erstellt werden können, sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.# Wenn das Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.{{BeginYellowBox}}Das AuthorInstitution-Element angegeben istvon besonderer Wichtigkeit, da es vom ELGA Berechtigungssystem bei Registrierung geprüft wird die Rolle als Text im Attribut @displayName erwartet.<br>Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden. {{EndYellowBox}}
=====Spezifikation=====
'''authorRoleauthorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: <span>$inst</span> … ClinicalDocument/author/assignedAuthor/representedOrganization *Fall 1:<br /> Element $inst/id[1] ist vorhanden<br />Attribut $inst/id[1]/@root ist vorhanden<br />Attribut $inst/id[1]/@extension ist nicht vorhanden<br />
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorRoleauthorInstitution">
<ValueList>
<Value>Diensthabender OberarztUnfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO</Value>
</ValueList>
</Slot>
</Classification>
</pre>
<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="authorSpecialityauthorInstitution">
<ValueList>
<Value>Anästhesiologie und IntensivmedizinUnfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&amp;ISO^^^^45</Value>
</ValueList>
</Slot>
</Classification>
</pre>
===classCode (und classCodeDisplayName)=authorPerson====Das Element ''classCodeauthorPerson'' Element beschreibt die Dokumentenklasse (grobe Granularität) Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche das Dokument angehört und ist relevant für das Berechtigungssysteminhaltlich erstellt hat (also nicht die Schreibkraft).
=====Spezifikationfür Personen=====
'''classCode (und classCodeDisplayName)authorPerson''' wird als ebRIM Classification Slot gemäß folgender Vorschrift zusammengesetzt:<br />
concat(<br /><span> $code = ClinicalDocumentperson</codespan>/translationid/@codeextension,"^",<br /><span> $person</span>/assignedPerson/name/family,"^",<br /><span> $displayName = ClinicalDocumentperson</span>/assignedPerson/name/given[1],"^",<br /><span> $person</span>/assignedPerson/name/given[2],"^",<br /><span> $person</span>/assignedPerson/name/suffix,"^",<br /><span> $person</span>/codeassignedPerson/translationname/prefix[@displayNamequalifier="AC"],"^^^&amp;",<br /><span> $codeSystem = ClinicalDocumentperson</codespan>/translationid/@codeSystemroot,"&amp;ISO"<br />)<br />
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:41a5887f93606bcf-88659494-4c0943ec-adf79b4e-e362475b143aa7748d1a838d" classifiedObject="theDocumenturn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" nodeRepresentation id="$codeurn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037"> <Name> <LocalizedString valuenodeRepresentation="$displayName"/> </Name> <Slot name="codingSchemeauthorPerson">
<ValueList>
<Value>urn:oid:$codeSystem2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO </Value>
</ValueList>
</Slot> </Classification></pre>{{BeginYellowBox}}Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.{{EndYellowBox}}Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/pre>.
=====Spezifikation für Software und Geräte=====
<span> $person</span> ===confidentialityCode===Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des Dokuments.ClinicalDocument/author/assignedAuthor
====SpezifikationauthorRole====Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.
ClinicalDocument/author/functionCode/@displayName<br /><pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:f4f85eac93606bcf-e6cb9494-488343ec-b5249b4e-f2705394840fa7748d1a838d" classifiedObject="theDocumenturn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" nodeRepresentation id="Nurn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037"> <Name> <LocalizedString valuenodeRepresentation="normal"/> </Name> <Slot name="codingSchemeauthorRole">
<ValueList>
<Value>urn:oid:2.16.840.1.113883.5.25Diensthabender Oberarzt</Value>
</ValueList>
</Slot> </Classification></pre> ===creationTime===Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:# Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:## ClinicalDocument/effectiveTime# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.# Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:# @value … enthält das Datum in folgenden möglichen Formen## YYYYMMDD## YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)### Bsp: 20081224082015+0100### Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
{{EndYellowBox}}
====SpezifikationauthorSpeciality====Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.
<pre class="ilfbox_code">
<Classification classificationScheme= "urn:uuid:2c6b8cb793606bcf-8b2a9494-405143ec-b2919b4e-b1ae6a575ef4a7748d1a838d" classifiedObject="theDocumenturn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="$code"> <Slot name="codingSchemeauthorSpeciality">
<ValueList>
<Value>urn:oid:$codeSystemAnästhesiologie und Intensivmedizin</Value>
</ValueList>
</Slot> <Name> <LocalizedString value="$displayName"/> </Name>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}
====Spezielle Vorschriften laut IHE PCC=classCode (und classCodeDisplayName)===Das PCC Profil definiert in Kapitel „Medical Document Bindings“ Spezialbehandlungen für gewissen Dokumenttypen ''classCode'' Element beschreibt die Dokumentenklasse (z.B.: XD-Lab, XDS-SD, BPPCgrobe Granularität)der das Dokument angehört und ist relevant für das Berechtigungssystem.
====Spezifikation====
'''languageCodeclassCode (und classCodeDisplayName)''' wird als ebRIM Slot Classification gemäß folgender Vorschrift zusammengesetzt:<br />
$code = ClinicalDocument/languageCodecode/translation/@code <br />$displayName = ClinicalDocument/code/translation/@displayName<br />$codeSystem = "de-AT"ClinicalDocument/code/translation/@codeSystem<br />
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82f41a5887f-054d8865-47f24c09-a032adf7-9b2a5b5186c1e362475b143a" statusclassifiedObject="theDocument" nodeRepresentation="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved$code"> id<Name> <LocalizedString value="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be$displayName"/> </Name> <Slot name="languageCodecodingScheme">
<ValueList>
<Value>de-ATurn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</ExtrinsicObjectClassification>
</pre>
===legalAuthenticatorconfidentialityCode===Das ''legalAuthenticatorconfidentialityCode'' Element beschreibt die Identifikation und demographische Informationen Vertraulichkeitsstufe des Dokuments. Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf Dokumente ausschließlich in der PersonELGA Infrastruktur zu verwalten, welche das Dokument rechtlich verbindlich unterzeichnet hatdementsprechend wird dieses Element vorerst nicht genutzt. Entfällt bei automatisch erstellten Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich und nicht durch natürliche Personen freigegebenen Dokumenten wird fix auf "N" (z.B. On-Demand Documents wie der „Medikationsliste“normal)gesetzt.
====Spezifikation====
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82ff4f85eac-054de6cb-47f24883-a032b524-9b2a5b5186c1f2705394840f" statusclassifiedObject="theDocument" nodeRepresentation="urn:oasis:names:tc:ebxml-regrep:StatusType:ApprovedN"> id<Name> <LocalizedString value="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333benormal"/> </Name> <Slot name="legalAuthenticatorcodingScheme">
<ValueList>
<Value>1234^Musterdoktor^Herbert^^^Drurn:oid:2.^^^&amp;116.2840.31.4113883.5.6.7.8.9&amp;ISO25</Value>
</ValueList>
</Slot>
</ExtrinsicObjectClassification></pre>Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
===serviceStartTime / serviceStopTimecreationTime===Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden. Dieses Datum kann für die Zeitpunkte des Beginns und Beendigung des Patientenkontakts/Behandlungchronologische Sortierung der Befunde bei der Anzeige der Dokumentenliste verwendet werden.
====Spezifikation====
'''serviceStartTimecreationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value = "20200511193000+0200"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="serviceStartTimecreationTime">
<ValueList>
<Value>20200511173000</Value>
</ExtrinsicObject>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.
{{BeginYellowBox}}
Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS''' diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200511173000).
{{EndYellowBox}}
===eventCodeList (und eventCodeListDisplayName)===
Im Fall eines Entlassungsbriefs beschreibt dieses Element die Liste der vollbrachten Gesundheitsdienstleistungen für den im Dokument dokumentierten Patientenkontakt.
Im allgemeinen Fall eines beliebigen CDA R2 Dokuments gilt grundsätzlich folgende Verknüpfung mit den CDA Header Elementen:
#Im CDA wird die Liste der ServiceEvents wie folgt abgelegt:
##ClinicalDocument/documentationOf/serviceEvent
#Mehrere dieser ServiceEvents können durch beliebig viele "documentationOf" Elemente ausgedrückt werden.
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines ServiceEvents verpflichtend, wenn bekannt [R].
#Ein ServiceEvent Element in CDA beinhaltet unter anderem die folgenden Elemente:
##code … ein Code-Element, welches die Art des ServiceEvents angibt
Die Vorschriften zur Befüllung der CDA R2 ServiceEvents leiten sich vom Allgemeinen und vom jeweiligen speziellen CDA Implementierungsleitfäden ab. In den speziellen Implementierungsleitfäden wird definiert, ob im ServiceEvent eine Gesundheitsdienstleistung angegeben werden muss und welche Bedeutung dieses Element hat.
====Spezifikation====
'''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />
Für jedes documentationOf Element 1..n:<br />
<pre class="ilfbox_code">
<ExtrinsicObject mimeTypeClassification classificationScheme="text/xml" objectType="urn:uuid:7edca82f2c6b8cb7-054d8b2a-47f24051-a032b291-9b2a5b5186c1b1ae6a575ef4" statusclassifiedObject="urn:oasis:names:tc:ebxml-regrep:StatusType:ApprovedtheDocument" idnodeRepresentation="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be$code"> <Slot name="serviceStopTimecodingScheme">
<ValueList>
<Value>20200516113000urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
<Name> <LocalizedString value="$displayName"/> </Name></ExtrinsicObjectClassification>
</pre>
===languageCode===
Das ''languageCode'' Element beschreibt den Sprachcode in dem das Dokument verfasst ist. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
====Spezifikation====
'''sourcePatientIdlanguageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientIdlanguageCode">
<ValueList>
<Value>4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISOde-AT</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
===sourcePatientInfolegalAuthenticator===Das ''sourcePatientInfolegalAuthenticator'' Element beschreibt die demographischen Daten des PatientenIdentifikation und demographische Informationen der Person, welche das Dokument rechtlich verbindlich unterzeichnet hat. Entfällt bei automatisch erstellten und nicht durch natürliche Personen freigegebenen Dokumenten (z.B. On-Demand Documents wie der "Medikationsliste").
Für CDA R2 Dokumente gilt folgende Verknüpfung mit den CDA Header Elementen:
#Laut Festlegung wird die Person, welche das Dokument vidiert hat, im Element "legalAuthenticator" abgelegt:
##ClinicalDocument/legalAuthenticator/assignedEntity
{{BeginYellowBox}}
{{EndYellowBox}}
====Spezifikation====
'''titlelegalAuthenticator''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" Slot gemäß folgender Vorschrift zusammengesetzt:<br /> <span> $person </span>= ClinicalDocument/legalAuthenticator/assignedEntity
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<NameSlot name="legalAuthenticator"> <LocalizedString charset="UTF-ValueList> <Value>1234^Musterdoktor^Herbert^^^Dr.^^^&amp;1.2.3.4.5.6.7.8" value="Entlassungsbrief der chirurgischen Abteilung" xml:lang="de-AT" .9&amp;ISO</Value> </ValueList> </NameSlot>
</ExtrinsicObject>
</pre>
Dies entspricht einer Transformation auf HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.
===serviceStartTime / serviceStopTime===
Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts/Behandlung.
Laut ELGA Implementierungsleitfäden ist in ELGA CDA Dokumenten die Angabe von mindestens einer Gesundheitsdienstleistung ("documentationOf/serviceEvent") verpflichtend, wenn bekannt '''''[R]'''''.
Wenn vorhanden, beinhaltet dieses Element die semantisch korrekten Informationen zu Start- und Enddatum gemäß der jeweiligen Fachdomäne (z.B.: das Aufnahme/Entlassungsdatum im Falle von Entlassungsbriefen aus stationärer Behandlung). Die relevanten Informationen dazu finden sich in den speziellen ELGA CDA Implementierungsleitfäden.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens einem ServiceEvent verpflichtend:
##ClinicalDocument/documentationOf/serviceEvent
#Das Element ServiceEvent beinhaltet unter anderem die folgenden Unterelemente:
##effectiveTime gibt das Zeitintervall an, in dem die Gesundheitsdienstleistung durchgeführt wurde
##Laut Vorgabe der ELGA Gesundheitsdaten SOLL ein Zeitintervall (HL7 IVL_TS) in wie folgt angeordnet werden:
###low … enthält das Startdatum
###high … enthält das Endedatum
###Andere im CDA möglichen Angaben (low/width, width/high, ...) sind nicht gestattet
{{BeginYellowBox}}
{{EndYellowBox}}
====Spezifikation====
'''typeCode (und typeCodeDisplayName)serviceStartTime''' wird wird als ebRIM Classification zum DocumentEntry umgesetzt und Slot gemäß folgender Vorschrift zusammengesetzt: <span > $code</span> = ClinicalDocument/codedocumentationOf/@code<brserviceEvent/><span > $displayName</span> = ClinicalDocumenteffectiveTime/codelow/@displayName<br/><span > $codeSystem</span> value = ClinicalDocument/code/@codeSystem<br/>"20200511193000+0200"
<pre class="ilfbox_code">
<ClassificationExtrinsicObject mimeType="text/xml" classificationSchemeobjectType="urn:uuid:f0306f517edca82f-975f054d-434e47f2-a61ca032-c59651d339839b2a5b5186c1" classifiedObjectstatus="theDocumenturn:oasis:names:tc:ebxml-regrep:StatusType:Approved" nodeRepresentationid="$code"> <Name> <LocalizedString value=urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"$displayName"/> </Name> <Slot name="codingSchemeserviceStartTime">
<ValueList>
<Value>urn:oid:$codeSystem20200511173000</Value>
</ValueList>
</Slot>
</ClassificationExtrinsicObject>
</pre>
{{BeginYellowBox}}
Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200511193000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS''' diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200511173000). {{EndYellowBox}} '''serviceStopTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:ClinicalDocument/documentationOf/serviceEvent/effectiveTime/high/@value ="20200516133000+0200"<pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectType=submissionSet.contentTypeCode="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"> <Slot name="serviceStopTime"> <ValueList> <Value>20200516113000</Value> </ValueList> </Slot></ExtrinsicObject></pre>{{BeginYellowBox}}Dieses Element '''MUSS''' – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein "Kürzen" auf andere Formate ist nicht zulässig. Der contentTypeCode des SubmissionSets Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragengemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200516133000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS''' diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200516113000).{{EndYellowBox}}
)
<pre class="ilfbox_code">
<ExternalIdentifierExtrinsicObject mimeType="text/xml"registryObject objectType="urn:uuid:1e2ede827edca82f-054d-857047f2-4be2a032-bd469b2a5b5186c1" status="urn:oasis:names:tc:ebxml-de986a4333beregrep:StatusType:Approved"identificationScheme id="urn:uuid:2e82c1f61e2ede82-a0858570-4c724be2-9da3bd46-8640a32e42abde986a4333be">value <Slot name="$valuesourcePatientId"> <ValueList><Value>4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO<Name/Value> <LocalizedString value="XDSDocumentEntry.uniqueId"/ValueList> </NameSlot></ExternalIdentifierExtrinsicObject></pre>Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.{{BeginYellowBox}}Ein spezieller Leitfaden kann eine abweichende Mapping-Vorschrift definieren!{{EndYellowBox}}
===referenceIdListsourcePatientInfo===Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Das referenceIdList ''sourcePatientInfo'' Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommenbeschreibt die demographischen Daten des Patienten.
{{BeginYellowBox}}
{{EndYellowBox}}
====Spezifikation====
===typeCode (und typeCodeDisplayName)===
Das ''typeCode'' Element beschreibt den Dokumententyp, dem das Dokument angehört. Der Dokumententyp ist die Spezialisierung einer Dokumentenklasse, jeder Dokumententyp gehört zu genau einer Dokumentenklasse.
Unterscheidung typeCode/classCode:{| class="wikitable"|- style="background:white"|'''typeCode'''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 Dokumentenklasse 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 vorgeschriebenfeiner Granularität (Spezialisierung).'''|- style="background:white"|classCodereferenceIdList wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt|Dokumentenklasse in grober Granularität.<br /> Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29_2|classCode]]|}
#Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:##ClinicalDocument/code#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentencodes ein verpflichtendes Element.#Ein Code-Element in CDA beinhaltet 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"#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe dieser 3 Attribute des Elements code verpflichtend.
<span> $code</span> = ClinicalDocument/code/@code<br /><span> $displayName</span> = ClinicalDocument/code/@displayName<br /><span> $codeSystem</span> = ClinicalDocument/code/@codeSystem<br /><pre class="ilfbox_code"><Classification classificationScheme="urn:elgauuid:iti:xds:2014:ownDocument_setIdf0306f51-975f-434e-a61c-c59651d33983" classifiedObject="theDocument" nodeRepresentation="$code"> <Name> <LocalizedString value="$displayName", /> </Name> <Slot name="^codingScheme", > <ValueList> <Value>urn:oid:$codeSystem</Value> </ValueList> </Slot></Classification></pre>
<pre class="ilfbox_code">
<ClinicalDocument xmlnsRegistryPackage status="urn:hl7oasis:names:tc:ebxml-orgregrep:StatusType:v3Approved">… <Classification<setId root classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500" classifiedObject="1.2.40.0.34.99.111.1.1theDocument" extension nodeRepresentation="ZZZZZZZZZZZZZZZZZZZ$code"> <Name> <LocalizedString value="$displayName"/> <versionNumber value/Name> <Slot name="2codingScheme"> <ValueList> <Value>urn:oid:$codeSystem</Value> </ValueList> </Slot> … </Classification></ClinicalDocumentRegistryPackage>
</pre>
Fall 1<br />
Attribut ClinicalDocument/id/@extension ist nicht vorhanden
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"ExternalIdentifier objectTyperegistryObject="<nowiki>urn:uuid:7edca82f1e2ede82-054d8570-47f24be2-a032bd46-9b2a5b5186c1</nowiki>" status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>de986a4333be" ididentificationScheme="<nowiki>urn:uuid:1e2ede822e82c1f6-8570a085-4be24c72-bd469da3-de986a4333be</nowiki>8640a32e42ab"> <Slot namevalue="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>$value"> <ValueListName> <Value><nowiki><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;2LocalizedString value="XDSDocumentEntry.25 <nowiki>&<uniqueId"/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> </SlotName> </ExtrinsicObjectExternalIdentifier></pre>
===intendedRecipientreferenceIdList===Für die spätere Verwendung Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE Cross Enterprise Document Workflow ITI TF-3<ref name="ITITF3"/> (XDW27 September 2013) ist der intendedRecipient notwendigDokument neu hinzugekommen. Derzeit wird dieses Element Für CDA-Befunde sind drei unterschiedliche Einträge in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes. referenceIdList vorgesehen:
Dieser Datentyp ist in IHE ITI TF-3<pre classref name="ilfbox_codeITITF3"/><ExtrinsicObject mimeType="text/xml" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urnData Types in folgender Weise spezifiziert:oasis:names:tc:ebxml-regrep:StatusType:Approved" id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/></pre>
{| class="wikitable" width==formatCode "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 (und formatCodeDisplayNamesee OID below)===must be used as Universal Id.<br />Das 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 '&'formatCodecharacter must be properly encoded in the XML content.|-|'' Element beschreibt das Format des Dokuments bezüglich seiner semantischen Interoperabilität. Es ermöglicht einem empfangenden System ('CXi'Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Dokumentenformats und somit die korrekte Darstellung und Verarbeitung des Dokuments||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers.Im CDA-Schema wurde für die HL7-Austria Domäne ein genau entsprechendes Element geschaffen, "hl7at:formatCode"Identifier type CX consists of several components.
#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
"<span >$codeSystem </spannowiki>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem <pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urnelga:uuiditi:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urnxds:uuid2014:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf" nodeRepresentation="$code"> ownDocument_setId<Name/nowiki> <LocalizedString value="$displayName, "^"/> </Name> <Slot name=, "codingScheme&amp;"> <ValueList> <Value>urn:oid:$codeSystem</Value> </ValueList> </Slot></Classification></pre>,
<pre class="ilfbox_code">
<ExtrinsicObject idClinicalDocument xmlns="urn:uuidhl7-org:f0573b34-ea9a-4c6d-8556-5cffbe50f027v3">… mimeType<setId root="text/xml1.2.40.0.34.99.111.1.1" objectTypeextension="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248ZZZZZZZZZZZZZZZZZZZ"/> status<versionNumber value="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved2"/> …</ClinicalDocument>
</pre>
Wie oben angeführt wird folgender CXi Wert erstellt:<pre class="ilfbox_code"> <ExtrinsicObject mimeType="text/xml" objectType=parentDocumentId, parentDocumentRelationship"<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;1.2.40.0.34.99.111.1.1 <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki> ^&amp;1.2.40.0.34.99.999&amp;ISO</Value> </ValueList> </Slot> </ExtrinsicObject></pre> Das ''parentDocumentId'' Element verweist auf das DokumentDie homeCommunityId ist die eindeutige OID, zu dem das eingebrachte Dokument in einer bestimmten Relation stehtunter welcher die ELGA Affinity Domäne registriert ist.
"<nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO</nowiki>"<pre class="ilfbox_code"><ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" status=Spezifikation=="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>" id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>"> <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <ValueList> <Value><nowiki>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;1.2.40.0.34.99.999&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'parentDocumentId') als auch bei der Befundschreibung ('' MUSS mit folgenden Elementen in CDA übereinstimmen: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).
Für Befunde der bildgebenden Diagnostik (diagnostic image report) KANN als Accession Number jene aus der ReferenceIdList der XDS-I Metadaten des KOS Objektes, mit dem eine Verlinkung hergestellt werden soll, genutzt werden. Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
concat
(
)<pre class="ilfbox_code"> <ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" status=Spezifikation=="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>" id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>"> <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <ValueList> <Value>20201111^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value> </ValueList> </Slot> </ExtrinsicObject></pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"<br />
<pre class="ilfbox_code">
<ClassificationExtrinsicObject mimeType="text/xml" classificationScheme objectType="<nowiki>urn:uuid:cccf55987edca82f-8b07054d-4b7747f2-a05ea032-ae952c785ead9b2a5b5186c1</nowiki>" classifiedObject status="<nowiki>urn:uuidoasis:names:tc:f0573b34ebxml-ea9a-4c6d-8556-5cffbe50f027regrep:StatusType:Approved</nowiki>" id="<nowiki>urn:uuid:63134a8d1e2ede82-9d4c8570-4fe04be2-ad9bbd46-9198b6deeddfde986a4333be</nowiki>"> nodeRepresentation <Slot name="$code<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <NameValueList> <Value>20201111^^^<nowiki>&<LocalizedString value="$displayName"/nowiki>amp;amp;1.2.40.0.34.99.999<nowiki> &</Namenowiki> amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession<Slot name="codingScheme"/nowiki> <ValueList/Value> <Value>20201112^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:oidihe:$codeSystemiti:xds:2013:accession</nowiki></Value> </ValueList> </Slot> </ClassificationExtrinsicObject></pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"<br />
===objectType =Verlinkung via Aufenthaltszahl (encounterId)====Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben Durch encounterId wird zwischen den Typen „stabiles Dokument“ die Verlinkung sämtlicher Befunde oder Bilddaten (siehe Kapitel [[ILF:XDS_Metadaten_(stable document, SDVersion_3) und „On#referenceIdList|referenceIdList]] für Dicom KOS-demand Dokument“ (onObjekte), die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-demand documentMetadaten unterstützt. Dies geschieht, ODD) unterschieden. Der objectType ist indem dieselbe Aufenthaltszahl als ebRIM ExtrinsicObjectistencounterId in den XDS-/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziertXDS-I Metadaten der zu gruppierenden Objekte strukturiert wird.
"<pre class="ilfbox_code"nowiki><Slot name="urn:elga-besihe:iti:xds:elgaFlag"> <ValueList> <Value>true2015:encounterId</Value> </ValueList></Slot></prenowiki>"
)
Bitte beachten Sie, dass die ClinicalDocument/componentOf/encompassingEncounter/id/@root
Wie oben angeführt wird folgender CXi Wert erstellt:<pre class="ilfbox_code"> <ExtrinsicObject mimeType="text/xml" objectType=elgaHash"<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>Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes <Value>Az123456^^^&amp;1.2.40.0.34. Ein XDS Source des ELGA-Bereiches sendet eine „XDS99.b Provide and Register Transaktion [ITI-41]“, eine „XDS4613.b Register Document Transaktion [ITI-42]“ oder eine „XDS Update Document [ITI-57]“ an die ZGF3. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im 4&amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki> </Value> </ValueList> </Slot „ELGA-Hash“ gespeichert.> </ExtrinsicObject></pre>
<br />
===intendedRecipient===
Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der intendedRecipient notwendig. Derzeit wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.
Der intendedRecipient entfällt bei On-Demand Documents.
==Revisionsliste=={| classSpezifikation===="wikitable"!Vers.!Datum'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:!Änderungsgrund|-<span>$code </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code|0.05|16.05.2011|Ergebnisse aus dem technischen Online-Meeting<span>$displayName </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName|-|2.00 Beta<span>$codeSystem </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem|12.08.2011 |Erster „Release candidate“ des Dokuments für internen Review innerhalb der Arbeitsgruppe.<pre class="ilfbox_code">|<Classification classificationScheme="urn:uuid:f33fb8ac-18af-42cc-|2.00 rc1|30.08.2011|Redaktionelle Überarbeitung.|ae0e-ed0b0bdb91e1"|2.00 FWGD|10.10.2011|Fertigstellung des „Final Working Group Draft“. Veröffentlicht für öffentlichen Review.| classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"|2.01 id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"|11.06.2012 nodeRepresentation="$code">|Fertigstellung der gültigen Version 2.01 „Final“. <br /Name> <LocalizedString value="$displayName"/>Abgrenzung des Geltungsbereiches (XDSDocumentEntry), Überarbeitung „PracticeSettingCode“, Hinweis zu OID eingefügt (1.2.3), Überarbeitung der „parentDocumentRelationship“, Typos ausgebessert|- </Name>|2.01 <Slot name="codingScheme">|21.12.2012 <ValueList>|Layout-Anpassung <Value>urn:oid:$codeSystem</Value>|- </ValueList> </Slot></Classification>|2.01a</pre>|07.03-2013|Zeile: 5: "und" eingefügt; 14: ===mimeType===Das ''mimeType'' Element beschreibt den "Internet Media Type"diesemdes Dokuments gemäß dem " eingefügt; 16: Multipurpose Internet Mail Extensions"dieses Dokuments“ eingefügt; 363: displayNameOf($codeMIME), „Of“ gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch „2“-> „Enhanced“ etcStandard. Der Standard wird beschrieben in RFC 2045 bis RFC 2049.) <br />Tabelle ab 357: classcode/typeCode ref name="SpalteRFC2045" eingefügt und erste Zeile eingefügt <br />Allgemein: Typos ausgebessert|-|2<ref name="RFC2046">Multipurpose Internet Mail Extensions (MIME) Part Part Two: Media Types [http://tools.02|12ietf.08.2013org/html/rfc2046 IETF RFC 2046]</ref>|2<ref name="RFC2047">Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text [http://tools.3.2 Präzisierung der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessertietf.org/html/rfc2047 IETF RFC 2047]</ref>|-|2<ref name="RFC2048">Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [http://tools.02|12ietf.08.2013|2.3.2.3 PDForg/html/rfc2048 IETF RFC 2048]</A-1a-Vorschrift hinzugefügtref>|-<ref name="RFC2049"/>|2.02|13Im Fall von CDA R2 Dokumenten ist der Mime Type laut IHE immer fix "text/xml".08.2013|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus====Spezifikation==== '''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, XDSwelches das DocumentEntry repräsentiert. Folgende Mime-Transaktionen, Größenbeschränkung, Vorschrift Types sind für PDF/A-1a-Dokumente zugelassen:<br />|-CDA R2: '''text/xml'''<br />|2.02|17.09.2013<pre class="ilfbox_code">|Typos, Formatierung und Seitenumbrüche ausgebessert<ExtrinsicObject| id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"|2.02a mimeType="text/xml"|06.02.2014|Beispiele in Tabelle 3 korrigiert| objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"|2.03|26.02.2014|Definition von ReferenceIdList eingefügt| status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>|2.03</pre>|03.03.2014|Definition von intendedRecipient eingefügt===parentDocumentId, parentDocumentRelationship===|-Das ''parentDocumentId'' Element verweist auf das Dokument, zu dem das eingebrachte Dokument in einer bestimmten Relation steht.|2.03|03Das ''parentDocumentRelationship'' Element beschreibt den Typ der Relation (Versionierung, Transformation).03.2014|Änderungen Da nicht alle lokalen und temporären Versionen eines Dokuments veröffentlicht werden müssen, können die tatsächlichen und technischen Dokumentenverweise in Tabelle 3: <br /> LegalAuthenticator – von [R] auf [XDS nicht über die parentDocumentId erfasst werden, sondern über Association-Objekte. Im Fall eines CDA R2] geändert<br /> IntendedRecipient – von "-" auf [O] geändertDokuments gilt folgende Verknüpfung mit den CDA Header Elementen: #Im CDA werden die Informationen über Dokumente, für Verwendung die mit XDW vorgesehen<br /> ReferenceIdList hinzugefügt<br dem eingebrachten Dokumenten in einer bestimmten Relation stehen, in folgendem Element abgelegt:##ClinicalDocument/> Den Namen des Value Sets von „ELGA-PracticeSettingCode“ auf „ELGA-PracticeSettingCode-vs“ geändertrelatedDocument|-#Der Typ der Relation MUSS verpflichtend in folgendem Attribut angegeben werden:|2.03.##ClinicalDocument/relatedDocument/@typeCode##Folgende Relationen sind in ELGA erlaubt (siehe "[[ILF:Allgemeiner Implementierungsleitfaden 2020|03.03.2014Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente]]" [1]):|Anhang gelöscht: <br ###Versionierung (RPLC)#Das zugrundeliegende Dokument (auf welches die Art der Relation wirkt), wird in folgendem Element angegeben:##ClinicalDocument/relatedDocument/> 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 TypesparentDocument ====Spezifikation==== '''parentDocumentId''' MUSS mit folgenden Elementen in CDA übereinstimmen:|-|2.03concat(|03.03.2014ClinicalDocument/relatedDocument/parentDocument/id/@root,"^",|Korrekturen: <br ClinicalDocument/relatedDocument/> ITI Version einheitlich geändert auf “(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)“.<br parentDocument/> 1.1.3 Hinweis auf Terminologieserver hinzugefügt<br id/> Tabelle 3 angepasst@extension) '''parentDocumentRelationship''' MUSS mit folgenden Elementen in CDA übereinstimmen:<br ClinicalDocument/> EntryUUID Beschreibung geändert<br relatedDocument/> patientId Beschreibung geändert@typeCode|-|2.03===practiceSettingCode (und practiceSettingCodeDisplayName)===|06Das ''practiceSettingCode'' Element beschreibt die fachliche Zuordnung des Dokumentes.03.2014|Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId|-|2Es SOLL den Fachbereich wiedergeben, dem der Inhalt des Dokuments am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung.03|21.03.2014|Kapitel 1.3.1Im CDA-Schema wurde für die HL7-Austria Domäne ein entsprechendes Element in den CDAs geschaffen, "hl7at:practiceSettingCode".2 Korrektur: Versionierung wird mit ITI-41 durchgeführt|-|2.03====Spezifikation====|26.03.2014|Kapitel 1.4. Korrektur von Dokumentverweisen|-'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classificationgemäß folgender Vorschrift zusammengesetzt:|2.03a|28.03.2014|Kapitel 2.1 Korrektur von Fußnotennummern<span>$code</span> = ClinicalDocument/hl7at:practiceSettingCode/@code<br />|-<span>$displayName</span> = ClinicalDocument/hl7at:practiceSettingCode/@displayName<br />|2.03a<span>$codeSystem</span> = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem<br /><pre class="ilfbox_code">|28.03.2014<Classification|Kapitel 2.2.7 und 2.2.11 classificationScheme="urn: Korrektur des Textes zur Konvertierung von Datumsformaten in UTCuuid: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000|cccf5598-8b07-4b77-a05e-ae952c785ead"|2.03b|1.7.2014|Den Namen des Value Sets von „ELGA classifiedObject="urn:uuid:f0573b34-ea9a-PracticeSetting Code4c6d-vs“ auf „ELGA_Practicesetting_VS“ korrigiert|8556-5cffbe50f027"|2.03b id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf" nodeRepresentation="$code">|11.07.2014 <Name>|2.3.2.5 OID in der Spezifikation ergänzt <LocalizedString value="$displayName"/>|- </Name>|2.03b <Slot name="codingScheme">|11.07.2014 <ValueList>|2.3.6 OID in der Spezifikation ergänzt <Value>urn:oid:$codeSystem</Value>|- </ValueList>|2.03b </Slot>|05.08.2014</Classification>|2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert</pre>|-|2.03b===objectType===|06Das objectType Element gibt den Typ des XDS DocumentEntry wieder.08.2014|2.1 Überblickstabelle: ParentDocumentId Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "stabiles Dokument" (stable document, SD) und ParentDocumentRelationship sind nur vorhanden"On-demand Dokument" (on-demand document, wenn ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine Vorversion vorliegt, daher Optionalität [R2]fixe UUID identifiziert.|-|2.03bFür "Stable Document" DocumentEntry:|06.08.2014|Referenzen auf CDA Implementierungsleitfäden aktualisiert|-| colspan<pre class="3ilfbox_code" |Version 2.05>|-|2.05|03.11.2014|EntryUUID als „ELGA-Relevant“ klassifiziert.<br ExtrinsicObject mimeType="text/> Darstellung der Übersichtstabelle geändertxml"|-|2.05|03.11.2014|2.2.15 TypeCode: ClassificationScheme im Beispiel korrigiert von "urn objectType="urn:uuid:41a5887f7edca82f-8865054d-4c0947f2-adf7a032-e362475b143a9b2a5b5186c1" (falsch) auf status="urn:uuidoasis:names:tc:f0306f51ebxml-975fregrep:StatusType:Approved" id="urn:uuid:1e2ede82-434e8570-a61c4be2-c59651d33983bd46-de986a4333be" (richtig)/>|-</pre>|2.05|19.11.2014|2.3.5. parentDocumentId, parentDocumentRelationshipFür "On-Demand Document" DocumentEntry: XFRM gelöscht|-<pre class="ilfbox_code">|2.05<ExtrinsicObject mimeType="text/xml"|19.11.2014 objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"|2.2.2. authorPerson status="urn:oasis: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.|names:tc:ebxml-regrep:StatusType:Approved"|2.05|19.11.2014|2.3.5. parentDocumentId, parentDocumentRelationship id="urn:uuid: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden|1e2ede82-8570-4be2-bd46-de986a4333be"/>|2.05</pre>|19.11.2014|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software|==ELGA-|2spezifische Erweiterungen der XDS-Metadaten==Die folgenden Daten erweitern den IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt.05|24.11.2014|2.2.1===elgaFlag===Das elgaFlag dient zur Kennzeichnung eines Dokuments als "ELGA-Dokument"<sup>18</sup>.1Ein XDS Source des ELGA-Bereiches sendet eine "XDS. Spezifikation von authorInstitution: Fall entferntb Provide and Register Transaktion [ITI-41]", in dem die ID des GDA unbekannt isteine "XDS. Die OID des GDA ist für ELGAb Register Document Transaktion [ITI-CDA [M42]|" oder eine "XDS Update Document [ITI-|2.05|26.11.2014|2.4 57]" an die ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Flag. Auch in 2.1 entsprechend angegebenZugriffssteuerungsfassade (ZGF) explizit gesetzt."elgaFlag" kann folgende Werte annehmen:|-|2.05*"true" oder|12.03.2014*"false"|Seite 2-3: Absätze „Verbindlichkeit“<sup>18</sup> Das ist für Registries notwendig, „Hinweise zur Verwendung“ und „Erarbeitung des Implementierungsleitfadens“ hinzugefügtdie sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.|-| colspan="3" |Version 2.06===Spezifikation====|-|2.06<pre class="ilfbox_code">|19.05.2015<Slot name="urn:elga-bes:elgaFlag">|1.2.2. Codesysteme und <ValueList> <Value>true</Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.>|- </ValueList>|2.06</Slot>|13.10.2015</pre>|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch|-===elgaHash===|2Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes.06|13Ein XDS Source des ELGA-Bereiches sendet eine "XDS.10.2015|1b Provide and Register Transaktion [ITI-41]", eine "XDS.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.|b Register Document Transaktion [ITI-|242]" 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.06|07.10.2015|1.4.3. Kapitel „Metadaten aus „OnDie Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Demand Documents“ Berechtigungssystems (ODDBeS)“ eingefügt|bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.|2.06|10.09.2015====Spezifikation====<pre class="ilfbox_code">|2.1 Tabelle 3 <rim: Beschreibung der entryUUID ergänzt|Slot name="urn:elga-bes:elgaHash">|2.06 <rim:ValueList>|07.10.2015|2.1 Tabelle 3 <rim: 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)Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value> </rim:ValueList>|- </rim:Slot>|2.06</pre>|30.10.2015|2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt wird, falls mehrere ID<!--Anhänge-Elemente angegeben sind.|->|2.06|19.05.2015=Anhänge=|2.2.5. und 2.2.15: Typos verbessert|-==Einzelnachweise==<references />==Literatur und Weblinks ==|2* IHE International https://www.ihe.06net/|29* HL7® International http://www.10hl7.2015org/|* Clinical Document Architcture (CDA®) Release 2.30 https://www.2hl7.5org/implement/standards/product_brief. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügtcfm?product_id=7|-|2* DICOM® — Digital Imaging and Communications in Medicine https://www.06|21dicomstandard.07.2015org/|2* Österreichische CDA Implementierungsleitfäden [https://wiki.2hl7.10. legalAuthenticator: Hinweis, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar istat/index.php?title=Implementierungsleitf%C3%A4den HL7 Austria Wiki]|-|2.06==Revisionsliste== |08===Hauptversion 3.100.20150 (2021)===|2.Diese Hauptversion wurde auf Basis der neuen Vorgaben aus dem Allgemeinen Implementierungsleitfaden 3.7 objectType hinzugefügt|0.0 grundlegend überarbeitet und umstrukturiert. Hinzugekommen sind die Vorgaben für die Registrierung von DICOM KOS-| colspan="3" |'''Version 2Objekten. Auf eine Revisionsliste mit direktem Vergleich zur Vorversion wurde daher verzichtet.06.2 (Nebenversion)'''<br /> x …betrifft Implementierung (erste Spalte)|-Die relevanten Änderungen sind:{||01.08.2016|Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.class="wikitable"|-||18.5.2016|1.2 Erklärung zur Verwendung Korrektur der Strukturierung von XDS Folder und SubmissionSet hinzugefügt."&" innerhalb der XML Beispiel-Snippets zu "&amp;"|-|"referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId|-|01.08.2016|2.1. Tabelle 3: Korrektur "Überblickstabelle der Optionalität XDS Metadaten": Optionalitäten von eventCodeList auf [R2], wie im Text bei 2.2"parentDocumentId" und "parentDocumentRelationship" zu O angepasst.8 angegeben|-|x|14.6.2016|creationTime, serviceStartTime, serviceStopTime"Spezifikation": Präzisierung der Vorgaben für Datum/Zeit, sie MUSS immer entsprechen der Angabe in CDA entweder 8 oder 14-stellig angegeben werdenVerbot von CR und LF hinzugefügt.|-|"Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.|03.08.2016-|2"sourcePatientInfo" angepasst.2.5Name, Geschlecht, 2.3.2.2, 2.3.2.5, 2.3.5, 2.3.5Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich|-|"legalAuthenticator" angepasst.Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[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;"|-||y|Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId|] in die XDS-||y|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasstübernommen.
|-
||y|Kapitel 1.11.1 "SpezifikationcreationTime": Verbot Bedeutung von CR und LF hinzugefügtClinicalDocument.effectiveTime präzisiert
|-
|||Kapitel 4.1 "Überblickstabelle der XDS MetadatenhealthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Optionalität von "sourcePatientInfo" zu X angepasst.|-|||Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich|Ableitungsvorschrift aus dem CDA-|||Kapitel Header Element "4.2.7 legalAuthenticatorhealthCareFacility" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommenhinzugefügt.
|-
|||Kapitel "4.2.4 creationTimeformatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at: Bedeutung von ClinicalDocumentformatCode" hinzugefügt.effectiveTime präzisiert
|-
||y|Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacilityClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
|-
||y|Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDAXDS-Header Element "hl7at:formatCodeI Metadaten für DICOM KOS Objekte" hinzugefügt.
|-
|||Kapitel "4.2.2.1 SpezifikationreferenceIdList": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.Ergänzung der Verwendung der encounterId
|}
===Hauptversion 2.06===
Eine Liste vorherigen Revisionen findet sich auf der '''[[ILF_Diskussion:XDS_Metadaten_(Version_3)|Diskussionsseite]]'''.
==Erratum==
Weitere Probleme und allfällige Korrekturen werden auf der [[ILF_Diskussion:XDS_Metadaten_(Version_3)|Diskussionsseite]] im Wiki gesammelt.
