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<br/>ImplementierungsleitfädenImplementierungsleitfaden XDS-Metadaten (XDSDocumentEntry)|Title = Leitfaden zur Registrierung von CDA Dokumenten für ELGA mit IHE Cross-Enterprise Document Sharing: <br/>XDS Metadaten in ELGA (XDSDocumentEntryVersion 3)|Subtitle = Zur Anwendung im österreichischen<br/>Gesundheitswesen [1.2.40.0.34.7.16.69.23]|Short = XDS -Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 23.060.2+20240715|Submitted = HL7 AustriaELGA GmbH|Date = 2001.10. März 20172021|Copyright = 20172011-2021|Status = EntwurfNormativ
|Period = n.a.
|OID = n1.n2.40.0.34.7.6.9.3|Realm = ÖsterreichAustria
}}
{{TOC limit|4}}
<!--
{{Infobox Ballot Begin}}
{{Infobox Ballot End}}
-->
<!--
{{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) und Bilddaten (DICOM KOS) in der ELGA Infrastruktur notwendig sind und wie sie aus den zugrundeliegenden Informationsobjekten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden [https://wiki.hl7.at/index.php?title=ILF:XDS_Metadaten_Guide XDS-Metadaten-Guide] im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für die Registrierung elektronischer Dokumente in der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012)<ref name="GTelG">Gesundheitstelematikgesetz 2012 [https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20008120 https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20008120]</ref>. Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti https://www.ihe.net/resources/technical_frameworks/#iti]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref> sowie DICOM Key Object Selection Documents (in Folge KOS)<ref name="DICOM">NEMA PS3 / ISO 12052, Digital Imaging and Communications in Medicine (DICOM®) Standard, National Electrical Manufacturers Association, Rosslyn, VA, USA. Unter ständiger Weiterentwicklung, die aktuelle Version ist frei verfügbar auf http://dicom.nema.org/).</ref>.
=Informationen über dieses Dokument=
<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">= Allgemeines =Impressum==<div class="mw-collapsible-content">Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur''Medieneigentümer, Herausgeber, Hersteller, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "Verleger:''<br />ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012)GmbH, Treustraße 35-43, Wien, aber auch für medizinische Dokumente im österreichischen GesundheitswesenÖsterreich. Telefon: +43.1.2127050<br />Internet: [http://www.elga.gv.at www.elga.gv.at]Email: [mailto:cda@elga.gv.at cda@elga.gv.at]<br/>Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch
== Zielgruppe Sprachliche Gleichbehandlung==Anwender dieses Dokuments <div class="mw-collapsible-content">Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind Softwareentwickler , beziehen sie sich auf Männer, Frauen und Beraterandere Geschlechtsidentitäten in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, die allgemein mit Implementierungen Kunden und Integrationen im Umfeld der ELGAKlienten zusammengefasst, insbesondere der ELGAwelche an einem Behandlungs-Gesundheitsdatenoder Pflegeprozess teilnehmen als auch gesunde Bürger, betraut sinddie derzeit nicht an einem solchen teilnehmen.Eine weitere Zielgruppe sind alle an Es wird ebenso darauf hingewiesen, dass umgekehrt der Erstellung von CDA-Dokumenten beteiligten PersonenBegriff Bürger auch Patienten, einschließlich der Endbenutzer der medizinischen Softwaresysteme Kunden und der Angehörigen von GesundheitsberufenKlienten mit einbezieht.</div></div>
== Hinweis auf verwendete Grundlagen Lizenzinformationen==Der vorliegende Leitfaden wurde unter Die Verwendung dieses Leitfadens für die Zwecke der nachstehend beschriebenen Dokumente erstellt. Das Urheberrecht an allen genannten Dokumenten wird im vollen Umfang respektiertErstellung, 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 />
== Bedienungshinweise für die PDFVerwendete Grundlagen und Bezug zu anderen Standards==Grundlage dieses Implementierungsleitfadens ist der internationale Standard IHE ITI Cross-Version enterprise Document Sharing <ref name="IHE ITI"></ref> von Integrating the Healthcare Enterprise (IHE)<ref name=Nutzen Sie die bereitgestellten Links im Dokument "IHE">Integrating the Healthcare Enterprise (z.B. im InhaltsverzeichnisIHE)International, um direkt in der PDF-Version dieses Dokuments zu navigierenIncorporated [http://www.ihe. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichternnet http://www.ihe.net]</ref>.
==ImpressumWichtige unterstützende Materialien==''Medieneigentümer, Herausgeber, Hersteller, Verleger{{BeginYellowBox}}Auf der Website: [[ILF:''<br />XDS_Metadaten_Guide|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, Treustraße 35-43, Wien, Österreich. Telefon: 01. 2127050. Internet: ([http://www.elga.gv.at. Email: [mailto:cda@elga.gv.at cda@elga.gv.at/CDA Website der ELGA GmbH]. <br />Geschäftsführer) weitere Dateien und Dokumente zur Unterstützung bereitgestellt: DI Dr. Günter Rauchegger, DI (FH) Dr. Franz Leisch
==Bedienungshinweise=====Farbliche Hervorhebungen===''Abbildungen<u>Themenbezogene Hinweise zur besonderen Beachtung:</u>'' © {{BeginYellowBox}}'''<Hinweis>'''<br/>authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:{{EndYellowBox}}''<u>Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):</u>''<pre class="ilfbox_code"><BEISPIEL><languageCode code="de-AT" /></pre>''<u>Verweis auf ELGA GmbH Value Set:</u>''{{BeginILFBox}}'''<Verweis>'''<br/>Zulässige Werte gemäß Value Set '''"ELGA_FormatCode".'''{{EndILFBox}}
=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="2" style="text-align:left" |Autoren|- |CodeWerk Software Services and Development GmbH||Jürgen Brandstätter|-|DICOM Austria|Emmanuel Helm|-|DICOM Austria|Silvia Winkler|- |ELGA GmbH, HL7 Austria||Stefan Sabutsch|- |ELGA GmbH||Oliver Kuttin|-|ELGA GmbH|Stefan Repas|- |Wiener Krankenanstaltenverbund||Konrad Hölzl|} <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-Dokumenten in ELGA''' über IHE XDS, unter dem Aspekt der Ableitung von XDS Metadaten aus CDA Dokumenten und der Etablierung von einheitlichen Vokabularen. Eine IHE XDS Registry verwaltet Dokumente und macht diese zugänglich. Sie erlaubt die Suche und das Filtern nach den Dokumenten über die Metadaten der Dokumente (Metadaten sind Daten, die andere Daten definieren und beschreiben). Werden, wie für ELGA, mehrere Registries gemeinsam genutzt, müssen die Metadaten übergreifend harmonisiert werden und Metadatenstandards bereitgestellt werden: Wertebereiche, Abhängigkeiten, Zuständigkeit, Abbildungsregeln, Versionierung und Policies. Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.
==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten<sup>2</sup> beim Einbringen von CDA-Dokumentenin Form von Befunden<supref name="ALF">3</supref> oder Bilddaten in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<supref name="IHE ITI">4</supref>. Die hier definierten Regeln sind von den folgenden „Technical Frameworks“ "Technical Frameworks" der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten Dokumente (Metadaten der XDSDocumentEntry Objekte)** : ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 1012.0 (2722.94.20132016) Final Text''* Darüber hinaus gehende Spezifikation speziell für CDA Dokumente** ''Patient Care Coordination <ref name="ITITF3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 12.0 (PCC2016)[https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf], Volume 2''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 ELGAzuletzt besucht am 25.01.2021</ref>
Ausgehend von obiger Basis definiert das vorliegende Dokument die genaue Spezifikation der Befüllung der XDS Metadaten speziell für die Anwendung im Rahmen der österreichischen Gesundheitsakte ELGA. Die Spezifikation wurde im Zusammenhang mit dem "Allgemeinen Implementierungsleitfaden"<ref name="ALF"></ref>, den "ELGA CDA Implementierungsleitfäden" und dem Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch<ref name="KOS-Leitfaden">DICOM Austria: Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch [https://collab.dicom-austria.at/pages/viewpage.action?pageId=27033635 DICOM Austria KOS Leitfaden], zuletzt besucht am 19.02.2021</ref> erstellt.
===XDS Folder===
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
===XDS Submission Sets===
Mit Ausnahme der Kapitel "5.1.12.2 submissionSet.contentTypeCode" und "6.1.12.2 submissionSet.contentTypeCode" wird keine weitere Profilierung des XDS Submission Sets gegenüber dem XDS Standard in ELGA vorgenommen.
==Hinweise zur Verwendung des Dokuments=====Codesysteme und Value Sets===Die vorliegende Spezifikation wurde im Zusammenhang mit den „ELGA CDA Implementierungsleitfäden“ erstelltin diesem Dokument erwähnten Codesysteme bzw. Zum Zeitpunkt der Erstellung liegen folgende Implementierungsleitfäden vorValue Sets werden am Terminologieserver (https:* ELGA CDA Implementierungsleitfäden (HL7 Implementation Guide for CDA® R2//www.gesundheit.gv.at/gesundheitssystem/professional/it-services/terminologieserver-doku):** „[[ILF:Allgemeiner Implementierungsleitfaden|Allgemeiner Implementierungsleitfaden für und auf der Website der ELGA CDA Dokumente]] [1]** „[[ILF:Entlassungsbrief (Ärztlich)|Entlassungsbrief GmbH (Ärztlich)]]“ [2]** „[[ILFhttp:Entlassungsbrief (Pflege//www.elga.gv.at)|Pflegerischer Entlassungsbrief]]“ [3]** „[[ILF:Laborbefund|Laborbefund]]“ [4]veröffentlicht.** „[[ILF:Befund bildgebende Diagnostik|Befund bildgebende Diagnostik]]“ [5]** „[[ILF:EWenn 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-Medikation|e-Medikation]]“ [6]** „[[ILF:Pflegesituationsbericht|Pflegesituationsbericht]]“ [7]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-Portal für das Österreichische 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") festgelegt. Zur Verwendung in ELGA werden diese Dokumente in standardisierte XML-Dateien im Format HL7 CDA R2 umgesetzt.
===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="ITITF3"/>.
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“ IT Infrastructure Technical Framworks(ITI) Technical Frameworks , Volume 3, Revision 10.0 – Final Text (27. 09.2013)<sup>6</sup>. <sup>6<ref name="ITITF3"/sup> http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3.pdf, zuletzt besucht am 26.3.2014
===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 911.0, Volume 2 , Kapitel XDSDocumentEntry Metadata beschrieben.<ref name="IHEPCC">IHE "Patient Care Coordination" (4PCC) Technical Frameworks Revision 11.0, Volume 2 [https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf https://www.10ihe.2013)<sup>7net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf]</supref>, Kapitel XDSDocumentEntry Metadata beschrieben.
===Metadaten aus "On-Demand Documents" (ODD) ===
Über XDS können auch Dokumente abgerufen werden, die zum Abfragezeitpunkt automatisch generiert werden. Für diese Dokumente werden Verweise in der Registry eingetragen, damit sie bei der Abfrage auch gefunden werden können. Die Metadaten von ODD unterscheiden sich notwendigerweise von den Metadaten der "stabilen Dokumente" (SD), da sie erst bei Generierung des Dokuments vorhanden sind.
Die genaue Beschreibung für On-Demand Documents findet sich IT Infrastructure Technical Framwork (ITI), Volume 3<ref name="ITITF3"/>.
===XDS Metadaten im Vergleich IHE vs. ELGA===
Die vollständige Liste der XDS Metadaten Elemente kann man in folgende Arten von Elementen unterteilen:
{| class="wikitable" width="100%"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|CK||Aus CDAKOS-Inhalt abgeleitet (direkt oder indirekt, gilt nicht für On-Demand-Documents)
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
|}
''Tabelle 12: 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 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''{|- styleclass="background:whitewikitable"| colspan="62" style|'''Metadaten Element'''|'''Optionalität'''|'''Quelle'''|'''Beschreibung'''|-| colspan="text-align:center2" |'''author'''Explizit zu setzende Metadaten(besteht aus den folgenden Komponenten)|'''M [1..1]'''|<nowiki>- style</nowiki>|Die Person oder das Gerät, welche(s) das Dokument verfasst hat|-| rowspan="background:white4"|| colspan="2" authorInstitution|'''availabilityStatusM [1..1]'''|E1/K|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)|-|authorPerson|'''R[0..1]'''|K|Daten der Person (Name, ID, etc.)|-|authorRole|'''R[0..1]'''|K|Gültigkeit des DokumentsRolle der Person|-|authorSpeciality|'''R [0..1]'''|E1/K|Fachrichtung der Person|- style| colspan="background2" |'''classCode'''|'''M [1..1]'''|A|Dokumenten/Objektklasse (Oberklasse) z.B.:white55113-5 "Key images Document Radiology"|-| colspan="2" |'''formatCodeconfidentialityCode'''|'''M [1..1]'''|A|Vertraulichkeitscode. Fester Wert "N"|-| colspan="2" |'''RcreationTime'''||'''RM [1..1]'''|K|Format Zeitpunkt der Erstellung des Dokumenteninhalts||E1registrierten Dokuments oder Objektes|- style="background:white"| colspan="2" |'''mimeTypeeventCodeList'''||'''RM [1..*]'''|A/K|Liste von Codes von Gesundheitsdienstleistungen|-||'''ReventCodeDisplayName'''||Mime Type des Dokuments<br />z'''M [1.B.: „text1]'''|A/xml“ für CDAK|Bezeichnung von Gesundheitsdienstleistungen nach APPC|E1-|- stylecolspan="background:white2"|'''intendedRecipient'''|'''NP [0..0]'''| -|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung|-| colspan="2" |'''parentDocumentIdlanguageCode'''||'''O<sup>12</sup>M [1..1]'''|A|Sprachcode. Fester Wert "de-AT"|-| colspan="2" |'''OlegalAuthenticator'''|'''NP [0..0]'''|Verweis auf ein referenziertes Dokument|-|E1Rechtlicher Unterzeichner|- style="background:white"| colspan="2" |'''parentDocumentRelationshipserviceStartTime'''|'''M [1..1]'''|K|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung|-| colspan="2" |'''O<sup>13</sup>serviceStopTime'''||'''ONP [0..0]'''|-|Typ Ende-Datum der Relation zu dem referenzierten Dokument.<br />Gesundheitsdienstleistung, z.B.: RPLC, XFRM||E1Ende der Untersuchung|- style="background:white"| colspan="2" |'''practiceSettingCodesourcePatientId'''|'''M [1..1]'''|K|Patienten ID im Informationssystem des GDA, z.B.: im RIS|-| colspan="2" |'''RsourcePatientInfo'''||'''RNP [0..0]'''|-|Fachliche Zuordnung Demographische Daten des Patienten im Informationssystem des Dokuments||E1GDA, z.B.: im RIS|- style="background:white"| colspan="2" |'''entryUUIDtitle'''|'''M [1..1]'''|A/K|Titel des Dokuments|-| colspan="2" |'''RtypeCode'''||'''RM [1..1]'''|A|UUID des Metadaten-Records des Dokuments Objekttyp (XDS DocumentEntryUnterklasse)||E1 codierter Wert|- style="background:white"| colspan="2" |'''objectTypeuniqueId'''|'''M [1..1]'''|K|Global eindeutige ID des Objektes z.B. SOP Instance UID|-| colspan="2" |'''RreferenceIdList'''||'''RM [1..*]'''|K/E1|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ des DocumentEntries (SD oder ODD)CXi codiert||E1-|- stylecolspan="background:white5"|'''''Explizit zu setzende Metadaten'''''|-| colspan="2" |'''commentsavailabilityStatus'''||'''OM [1..1]'''|E1|Gültigkeit des Objektes|-| colspan="2" |'''OformatCode'''|'''M [1..1]'''|Kommentar zum DokumentE1||E2Format des Objektes|- style="background:white"| colspan="2" |'''patientIdhealthcareFacilityTypeCode'''||'''RM [1..1]'''|E1|Klassifizierung des GDA|-|colspan="2" |'''RmimeType'''|'''M [1..1]'''|Patienten-ID in der XDS Affinity DomainE1||E1Mime Type des Dokuments
Fester Wert für KOS: "application/dicom"|- style| colspan="background:white2"|'''parentDocumentId'''|'''O [0..1]'''|E1|Verweis auf ein referenziertes Objekt|-| colspan="62" style|'''parentDocumentRelationship'''|'''O [0..1]'''|E1|Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC, XFRM|-| colspan="text2" |'''practiceSettingCode'''|'''M [1..1]'''|E1|Fachliche Zuordnung des Dokuments|-align:center| colspan="2" |'''entryUUID''Von Registry oder Repository automatisch gesetzte Metadaten'|'''M [1..1]'''|E1|UUID des Metadaten- styleRecords des Dokuments(XDS DocumentEntry)|-| colspan="background:white2" |'''objectType'''|'''M [1..1]'''|E1|Typ des DocumentEntries Fester Wert "SD"|-| colspan="2" |'''hashcomments'''||'''RO [0..1]'''|K|Kommentar zum Dokument/Objekt|-|colspan="2" |'''XpatientId'''||Hash Wert des Dokuments'''M [1. Wird vom Repository befüllt.1]'''|E1|APatienten-ID in der XDS Affinity Domain|- style| colspan="background:white5"|'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''|-| colspan="2" |'''homeCommunityIdhash'''|'''M [1..1]'''|A|Hash Wert des Dokuments. Wird vom Repository befüllt|-| colspan="2" |'''RhomeCommunityId'''||'''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 '''||'''R'''||'''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'''||'''R'''||'''XM [1..1]'''|A|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository befüllt.||A<br />|- style="background:white"| colspan="2" |'''URI'''||'''-NP [0..0]'''[[#%20ftn1|<supnowiki/>14]][[#%20ftn1|<nowiki/sup>''']]|A|'''-'''||<span style="color:red;">'''Wird in XDS -I nicht verwendet'''</span>||A-|- style="background:white"| colspan="6" style="text-align:center5" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''|- style="background:white"| colspan="2" |'''elgaFlag'''||'''R'''||'''RM [1..1]'''|B|Kennzeichnet ein Dokument als „ELGA"ELGA-Dokument“||BDokument"|- style="background:white"| colspan="2" |'''elgaHash'''||'''R'''||'''RM [1..1]'''|B|Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B
|}
<br />
<p style="page-break-before: always"></p>
''Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle''{| class="wikitable" width="100%"|- style=author"background:#CBD7F1"! style="text-align:left" |Code|| style="text-align:left" |Bedeutung|- style="background:#CBD7F1"Die Personen und/|C||Aus CDA-Inhalt abgeleitet (direkt oder Maschinenindirekt, die das Dokument erstellt haben. Dieses Attribut enthält die Subattributegilt nicht für On-Demand-Documents)|- style="background: authorInstitution, authorPerson, authorRole, authorSpecialty #white"|E1||Explizit gesetzt (ELGA relevant)|- style="background:#white"|E2||Explizit gesetzt (und authorTelecommunicationnicht ELGA relevant).|- style="background:#white"|A||Von Registry oder Repository automatisch gesetzt|- style="background:#white"|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt|}
''Tabelle 5: Legende zur Spalte "Optionalität" der folgenden Tabelle ''
{| class="wikitable" width="100%"|- ! style="text-align:left" |Code|| style=authorInstitution==="text-align:left" |Bedeutung|- style="background:CBD7F1"|M||Das ''authorInstitution'Element''' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurdeMUSS mit einem korrekten "echten" Wert angegeben werden. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:# Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, "Dummy"-Werte sind NICHT ERLAUBT. Entspricht der der Autor des Dokuments angehört grundsätzlich in folgendem Element abgelegt:## ClinicalDocument/author/assignedAuthor/representedOrganization# Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:## älteren Leitfäden gebräuchlichen Notation [R] ''("required")'id'''[1] … ID der Organisation mit den folgenden Attributen:.### @root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension|-Attribut)style="background:white"### @extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)## |R||Das '''nameElement''' … Name SOLL in der Organisation als String<br /> Da manche offiziellen Bezeichnungen von GDA sehr lang werden könnenInstanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, soll das name Element SOLL einer möglichst eindeutigen Kurzbezeichnung darf es nicht in der Organisation entsprechen (im GDA-I im Tag description enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben Instanz codiert sein und muss weggelassen werden, damit die Zuordnung für den Leser einfacher wird.<br /> Beispiel: Statt "Allgemeines Krankenhaus Entspricht der Stadt Wien-Medizinischer Universitätscampusin älteren Leitfäden gebräuchlichen Notation [R2] ''(" → required if known"Wien AKH)''.|- style=" bzw background:white"Wien AKH |O||Optional|- Augenambulanzstyle="background:white" # GDAs, |NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente „GDA Index“ mit einer eindeutigen OID ausgestattet. # Falls mehrere ID-Elemente angegeben sind, ist idälteren Leitfäden gebräuchlichen Notation [1X] (die erste ID''"prohibited"'') zu verwenden. |}
''Tabelle 6: Überblick XDS Metadaten und deren Quellen (alphabetisch)'authorInstitution'{| class="wikitable" width="100%"|- style="background:#CBD7F1"| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''| rowspan="2" style="text-align:left" |'''Beschreibung '''|- style="background:#CBD7F1"|'''SD'''<span sup>$inst9</spansup> … ClinicalDocument||'''ODD'''<sup>10</sup>|- style="background:#CBD7F1"| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''|- style="background:white"| colspan="2" |'''author/assignedAuthor/representedOrganization''' (besteht aus den folgenden Komponenten)||'''M [1..1]'''||'''M [1..1]'''|C||Die Person, welche das Dokument verfasst hat|- style="background:white"* Fall | ||authorInstitution||'''M [1..1]'''||'''M [1..1]'''|C||ID und Name der Organisation (Kurzbezeichnung), der die Person angehört, wie im GDA-Index angegeben.|- style="background:<br/>white"Element $inst/id| ||authorPerson||'''M [1..1]'''||'''M [1..1] ist vorhanden<br/>'''|C||Daten der Person (Name, ID, etc.)|- style="background:white"Attribut $inst/id| ||authorRole||'''R [0..1]/@root ist vorhanden<br/>'''||'''NP [0..0]'''|C||Rolle der Person|- style="background:white"Attribut $inst/id| ||authorSpeciality||'''R [0..1]/@extension ist nicht vorhanden<br/>'''||'''NP [0..0]'''|C||Fachrichtung der Person|- style="background:white"| colspan="2" |'''classCode'''||'''M [1..1]'''||'''M [1..1]'''concat|C||Dokumentenklasse (Oberklasse)<br/>z.B.: 18842-5 "Entlassungsbrief"<span>$inst</span>/name,|- style="^^^^^^^^^background:white",<br/><span>$inst</span>/id| colspan="2" |'''confidentialityCode'''||'''M [1..1]'''||'''NP [0..0]/@root<br/>'''|C||Vertraulichkeitscode des Dokuments)<br/>|- style="background:white"<pre class| colspan="ILFgreen2">|'''creationTime'''||'''M [1..1]'''||'''NP [0..0]'''|C||Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden<Classification classificationScheme|- style="urnbackground:uuid:93606bcfwhite"| colspan="2" |'''eventCodeList'''||'''R [0..*]'''||'''R [0..*]'''|C||Liste von Gesundheitsdienstleistungen|-9494| colspan="2" |'''formatCode'''|'''M [1..1]'''|'''M [1..1]'''|C|Format des Dokumenteninhalts|-43ecstyle="background:white"| colspan="2" |'''intendedRecipient'''||'''O [0..1]'''||'''NP [0..0]'''|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.|-9b4e-a7748d1a838dstyle="background:white" classifiedObject| colspan="urn2" |'''languageCode'''||'''M [1..1]'''||'''M [1..1]'''|C||Sprachcode des Dokuments<br />z.B.:uuid:f0573b34"de-ea9aAT"|-4c6dstyle="background:white"| colspan="2" |'''legalAuthenticator'''||'''R [0..1]'''||'''NP [0..0]'''|C||Rechtlicher Unterzeichner des Dokuments|-8556| colspan="2" |'''practiceSettingCode'''|'''M [1..1]'''|'''M [1..1]'''|C|Fachliche Zuordnung des Dokuments|-5cffbe50f027style="background:white" id| colspan="urn2" |'''serviceStartTime'''||'''R [0..1]'''||'''O [0..1]'''|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.:uuidDatum der Aufnahme|- style="background:33adae7ewhite"| colspan="2" |'''serviceStopTime'''||'''R [0..1]'''||'''O [0..1]'''|C||Ende-f1edDatum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung|-4345style="background:white"| colspan="2" |'''sourcePatientId'''||'''M [1..1]'''||'''M [1..1]'''|C||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH|-acabstyle="background:white"| colspan="2" |'''sourcePatientInfo'''||'''NP [0..0]'''||'''NP [0..0]'''|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)|-73f59bc1d037style=" nodeRepresentationbackground:white"| colspan="2" |'''Title'''||'''M [1..1]'''||'''M [1..1]'''|C||Titel des Dokuments|- style="background:white"> <Slot name| colspan="authorInstitution2"|'''typeCode'''<sup> 11<ValueList/sup>||'''M [1..1]'''||'''M [1..1]''' |C||Dokumententyp (Unterklasse) <Valuebr />Unfallkrankenhaus Neusiedl^^^^^^^^^1codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"|- style="background:white"| colspan="2" |'''uniqueId'''||'''M [1.3.41]'''||'''M [1.5.61]'''|C||Global eindeutige ID des Dokuments|- style="background:white"| colspan="2" |'''referenceIdList'''||'''M [1.7.81]'''||'''O [0.9.17891]'''|C||Liste von Identifikatoren.45&amp;ISO</Value>Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert </ValueList>|- style="background:white" </Slot> </Classification>| colspan="2" |'''healthcareFacilityTypeCode'''||'''M [1..1]'''||'''M [1..1]'''</pre>|C||Klassifizierung des GDA
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
|- style="background:white"
| colspan="2" |'''availabilityStatus'''||'''M [1..1]'''||'''M [1..1]'''
|E1||Gültigkeit des Dokuments
|- style="background:white"
| colspan="2" |'''mimeType'''||'''M [1..1]'''||'''M [1..1]'''
|E1||Mime Type des Dokuments<br />z.B.: "text/xml" für CDA
|- style="background:white"
| colspan="2" |'''parentDocumentId'''<sup>12</sup>||'''O [0..1]'''||'''O [0..1]'''
|E1||Verweis auf ein referenziertes Dokument
|- 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
|- style="background:white"
| colspan="2" |'''entryUUID'''||'''M [1..1]'''||'''M [1..1]'''
|E1||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)
|- style="background:white"
| colspan="2" |'''objectType'''||'''M [1..1]'''||'''M [1..1]'''
|E1||Typ des DocumentEntries (SD oder ODD)
|- style="background:white"
| colspan="2" |'''comments'''||'''O [0..1]'''||'''O [0..1]'''
|E2||Kommentar zum Dokument
|- style="background:white"
| colspan="2" |'''patientId'''||'''M [1..1]'''||'''M [1..1]'''
|E1||Patienten-ID in der XDS Affinity Domain
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|- style="background:white"
| colspan="2" |'''hash'''||'''M [1..1]'''||'''NP [0..0]'''
|A||Hash Wert des Dokuments. Wird vom Repository befüllt.
|- style="background:white"
| colspan="2" |'''homeCommunityId'''||'''M [1..1]'''||'''M [1..1]'''
|A||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.
|- style="background:white"
| colspan="2" |'''repositoryUniqueId '''||'''M [1..1]'''||'''M [1..1]'''
|A||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
|- style="background:white"
| colspan="2" |'''size'''||'''M [1..1]'''||'''NP [0..0]'''
|A||Größe des Dokuments in Bytes. Wird vom Repository befüllt.
|- style="background:white"
| colspan="2" |'''URI'''||'''NP [0..0]'''||'''NP [0..0]'''
|A||'''Wird in XDS nicht verwendet'''
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|- style="background:white"
| colspan="2" |'''elgaFlag'''||'''M [1..1]'''||'''M [1..1]'''
|B||Kennzeichnet ein Dokument als "ELGA-Dokument"
|- style="background:white"
| colspan="2" |'''elgaHash'''||'''M [1..1]'''||'''M [1..1]'''
|B||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes
|}
''Tabelle 7: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet''{| class="wikitable" width="100%"|- style="background:#CBD7F1"| colspan="2" |'''authorPersonXDS-I Metadaten Element'''|'''Opt.'''|'''Attribut in''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
'''authorRoleAchtung:''' Die Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird , die die maßgeblichen Teile der Studie verantwortet.|- style="background:white"| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als ebRIM Slot gemäß folgender Vorschrift zusammengesetztauthor angegeben werden:|- style="background:white"|author.authorPerson|R [0..1]|(0008,0060) + (0008,0070) + (0008,1090)||Modality Code + Manufacturer + Manufacturer's Model Name
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===authorSpeciality===="background:white"||eventCodeList<br />DisplayNameListDas ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat|M [1..1]|||Enthält den Display Name des APPC
|- style="background:white"
| '''''classCode'''''| '''''Dokumentenklasse in grober Granularität'''''|-stylecolspan="background:white2"| ''typeCode''title| Dokumentenklasse in feiner Granularität.<br/> Siehe Kapitel [M [ILF:XDS Metadaten 2020#typeCode_1.28und_typeCodeDisplayName.291]|(0008,0060) + (0008,1030)|4.2.15]]|}Der relevante Modality Code der Studie oder alle Modality Codes der Studie und die Study Description.
|- style="background:white"
|''' 0-S'''colspan="2" |referenceIdList|''' 18842-5'''M [1..1]| Discharge summary| Entlassungsbrief| '''classCode'''Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente|-style="background:white"| 1-Lrowspan="2" | 11490-0| Physician Discharge summary| Entlassungsbrief Ärztlich| typeCode|-stylevalue mit CXi.5 =<br />"background<nowiki>urn:elga:iti:xds:2014:whiteOwnDocument_setId</nowiki>"| M [1..1-L]| 34745-0(0020,000D) oder ein vergleichbares Attribut| Nurse Discharge summary| Entlassungsbrief Pflege(0020,000D) oder ein vergleichbares Attribut| typeCode|}Als typeCode wird 11490-0 oder 34745-0 angegeben, als classCode entsprechend 18842-5. Die setId zur Klammerung aller Versionen eines KOS
Diese kann von jedem Bereich frei gewählt werden, sie ist mit dem Datentyp '''<supnowiki>15urn:elga:iti:xds:2014:OwnDocument_setId</supnowiki> Die deutsche Sprachvariante wird im SVS Format als Attribut „deutsch“ geführt, im CSV-Export als Spalte „meaning“''' anzugeben.
Eine mögliche Wahl der setId ist die Study Instance UID. Die geeignete Wahl der setId hängt auch vom implementierten Stornoworkflow ab, siehe KOS Leitfaden (Kapitel 8.2.2.)<ref name="KOS-Leitfaden" />|- style="background:white"|value mit CXi.5 ==Spezifikation====<br />"<nowiki>urn:ihe:iti:xds:2013: accession</nowiki>"|R [0..1]|(0008,0050) oder ein vergleichbares Attribut wie z.B.
Diese ist mit dem Datentyp '''<span nowiki>$typeCode urn:ihe:iti:xds:2013:accession</span>= ClinicalDocument/code/@code<br/nowiki>''' anzugeben.
Welche ID dazu geeignet ist, die Verlinkung mit dem zugehörigen Befund herzustellen, ist vom jeweils implementierten Workflow abhängig.
{{EndYellowBox}}
=====Spezifikation===== '''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: <span>$name</span> … Name der Organisation, die die Studie erstellt hat <span>$oid ... OID der Organisation aus dem GDA-Index</span>
<ValueList>
<Value>20200511173000Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO </Value>
</ValueList>
</Slot> </ExtrinsicObjectClassification>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 DTM XON Datentyp gemäß [IHE ITITF-TF3]3<ref name="ITITF3" />. ====authorPerson====Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche die Bilddaten inhaltlich erstellt hat. Im Fall eines DICOM Objektes gilt eine Verknüpfung mit folgenden (optionalen) DICOM Attributen: #Die Person kann aus den DICOM Attributen der Studie abgeleitet werden#*Identifikator: Code aus Attribut "Performing Physicians Identification Sequence", (0008,1052), Datentyp SQ, wenn vorhanden. Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence.#*Name: Attribut "Performing Physicians Name", (0008,1050), Datentyp PN (entspricht den ersten 5 Feldern von HL7 V2 Datentyp XPN. Maximum 64 Zeichen pro component group, ohne zusätzliche ideographische und phonetische Zeichen). Wenn mehrere Namen vorhanden sind, ist der erste zu übernehmen.#*Root: OID-Unterknoten für Personen (entsprechend der Organisations-OID aus dem GDA-Index)#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den folgenden DICOM Attributen abgleitet werden#*Modalität: Attribut "Modality", (0008,0060), erlaubte Werte siehe DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality <ref name="DICOMModality">DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</ref>#*Hersteller: Attribut "Manufacturer", (0008,0070)#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090)
{{BeginYellowBox}}
{{EndYellowBox}}
===eventCodeList (und eventCodeListDisplayName)==Spezifikation für Personen=====Im Fall eines Entlassungsbriefs beschreibt dieses Element die Liste der vollbrachten Gesundheitsdienstleistungen für den im Dokument dokumentierten Patientenkontakt. '''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
$id ====Spezifikation====Code #1 aus (0008,1052) Performing Physicians Identification Sequence
concat(<br /><span >$code id</span>= ClinicalDocument/documentationOf[n]/serviceEvent/code/@code,"^",<br/><span >$displayNameperson</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName,"^",<br/><span >$codeSystem</span> = ClinicalDocumentroot,"&amp;ISO"<br /documentationOf[n]/serviceEvent/code/@codeSystem>)<br/><pre class="ILFgreenilfbox_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="codingSchemeauthorPerson"> <ValueList> <Value>urn:oid:$codeSystem11375^Musterdoc^Josef^Maria^Msc^DIDr^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO </Value>
</ValueList>
</Slot> <Name> <LocalizedString value="$displayName"/> </Name> </Classification></pre>
concat(<br /><span> $id</span>,"^",<br /><span> $person</span><br />)<br /><pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d" classifiedObject=languageCode"urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027" id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation=""> <Slot name="authorPerson"> <ValueList> <Value>2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value> </ValueList> </Slot> Das ''languageCode'' Element beschreibt den Sprachcode </Classification></pre>Dies folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf die XCN Komponenten wie in dem das Dokument verfasst istIHE 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. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen3-3:====Spezifikation====XCN Data type mapping" vorgegeben.
=====Spezifikation für Software und Geräte===== '''languageCodeauthorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
$Manufacturer ===legalAuthenticator===Das ''legalAuthenticator'' Element beschreibt die Identifikation und demographische Informationen der PersonManufacturer (0008, 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“0070).
$Modality,"^",
<ValueList>
<Value>1234^MusterdoktorCT^HerbertGeräthersteller^^^Dr.^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISOGerätename</Value>
</ValueList>
</Slot>
</ExtrinsicObjectClassification></pre> Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITITF-3<ref name="ITITF3" />. ====authorRole====Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-TF3]Objekt Erzeugung innehatte.
=====Spezifikation===== '''serviceStartTimeauthorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:ClinicalDocumentBsp: Fachärztin/documentationOfFacharzt für Radiologie<br /serviceEvent/effectiveTime/low/@value = "20200511193000+0200"><pre class="ILFgreenilfbox_code"><ExtrinsicObject mimeType="text/xml" objectTypeClassification classificationScheme="urn:uuid:7edca82f93606bcf-054d9494-47f243ec-a0329b4e-9b2a5b5186c1a7748d1a838d" statusclassifiedObject="urn:oasisuuid:names:tc:ebxmlf0573b34-ea9a-4c6d-8556-regrep:StatusType:Approved5cffbe50f027" id="urn:uuid:1e2ede8233adae7e-8570f1ed-4be24345-bd46acab-de986a4333be73f59bc1d037" nodeRepresentation=""> <Slot name="serviceStartTimeauthorSpeciality">
<ValueList>
<Value>20200511173000Fachärztin/Facharzt für Radiologie</Value>
</ValueList>
</Slot> </ExtrinsicObjectClassification>
</pre>
{{BeginYellowBox}}
{{EndYellowBox}}
===classCode (und classCodeDisplayName)===
Das ''classCode'' Element klassifiziert (grobe Granularität) das registrierte Objekt und ist relevant für das Berechtigungssystem.
Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Objektklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Objektklasse in feiner Granularität.<br /> Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#typeCode_.28und_typeCodeDisplayName.29|typeCode]]
|}
====Spezifikation====
'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br />
<ValueList>
<Value>20200516113000urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</ExtrinsicObjectClassification>
</pre>
====Spezifikation====
<ValueList>
<Value>4711^^^&amp;1.urn:oid:2.316.4840.51.6113883.7.85.9&amp;ISO25</Value>
</ValueList>
</Slot>
</ExtrinsicObjectClassification></pre>Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß [IHE ITI-TF3].
===sourcePatientInfocreationTime===Das creationTime Element beschreibt den Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes. Es soll die Zeit angegeben werden, die diese Erstellungszeit am besten beschreibt:
$patientRole/id[1]/@rootdate = (0008, "&amp;ISO"0020) Study Date oder (0008,0023) Content Date
$time = (0008,0030)Study Time oder (0008,0033) Content Time und (0008,0201) Timezone Offset from UTC
)<pre class="ILFgreenilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientInfocreationTime">
<ValueList>
<Value>PID-3|$id</Value> <Value>PID-5|$name</Value> <Value>PID-7|$birthtime</Value> <Value>PID-8|$gender</Value> <Value>PID-11|$addr20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).
In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name====Optionale Spezifikation (mit demografischen Patientendaten)===="ITITF3" />.{{EndYellowBox}}
<span>$patientRolecode </id[span>= APPC code (alle Achsen) z.B. "2.4.0.5-3-3"<br /><span>$displayName</span> = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule"<br /><span>$codeSystem</span> = OID des Codesystems APPC: 1].2.40.0.34.5.38<br /><pre class="ilfbox_code"><Classification classificationScheme= "urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4" classifiedObject="theDocument" nodeRepresentation="$code"> <Slot name="codingScheme"> <ValueList> <Value>urn:oid:$codeSystem</@root, Value> </ValueList> </Slot> <Name> <LocalizedString value="&amp;ISO$displayName"/> </Name></Classification></pre>
Fester Wert "de-AT"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="languageCode">
<ValueList>
<Value>de-AT</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
)
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="serviceStartTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).
Für ein Mapping aus KOS steht folgendes Attribut zur Verfügung:
$patientRole/addr/state,"^"patientID = (0010,0020) Patient ID
$patientRole/addr/postalCode,"^",oid = OID des lokalen Patientenidentifikators
concat(
$patientRole/addr/streetNamepatientID," ",$patientRole/addr/houseNumber
$patientRole/addr/city,"^"oid,
)
<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="sourcePatientInfosourcePatientId">
<ValueList>
<Value>PID-4711^^^&amp;1.2.3|$id</Value> <Value>PID-.4.5|$name</Value> <Value>PID-.6.7|$birthtime</Value> <Value>PID-.8|$gender</Value> <Value>PID-11|$addr.9&amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.
===sourcePatientInfo===Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.{{BeginYellowBox}}In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.{{EndYellowBox}} ===title===Das ''title'' Element beschreibt den lesbaren Titel des Dokumentsregistrierten Objektes. Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
====Spezifikation====
'''title''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Name>
<LocalizedString charset="UTF-8" value="Entlassungsbrief der chirurgischen AbteilungDX Digitales Röntgen des Schädels" xml:lang="de-AT" />
</Name>
</ExtrinsicObject>
===typeCode (und typeCodeDisplayName)===
Das ''typeCode'' Element beschreibt den DokumententypObjekttyp, dem das Dokument KOS Objekt angehört. Der Dokumententyp Objekttyp ist die Spezialisierung einer DokumentenklasseObjektklasse, jeder Dokumententyp Objekttyp gehört zu genau einer DokumentenklasseObjektklasse.
Unterscheidung typeCode/classCode:
{| class="wikitable"
|- style="background:white"
| '''typeCode'''| '''Dokumentenklasse Objektklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
| classCode| Dokumentenklasse Objektklasse in grober Granularität.<br/> Siehe Kapitel [[ILF:XDS Metadaten 2020(Version 3)#classCode_.28und_classCodeDisplayName.29|classCode]]
|}
Es wird ein fester Wert gesetzt: '''typeCode (und typeCodeDisplayName)55113-5''' wird wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:"Key images Document Radiology"
<span > $code</span> = ClinicalDocument/code/@code"55113-5"<br/><span > $displayName</span> = ClinicalDocument/code/@displayName"Key images Document Radiology"<br/><span > $codeSystem</span> = ClinicalDocument/code/@codeSystem"2.16.840.1.113883.6.1"<br/><pre class="ILFgreenilfbox_code">
<Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="theDocumentKeyImageObject"
nodeRepresentation="$code">
<Name>
</Classification>
</pre>
====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets Submission Sets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.
$code = ClinicalDocument/code/@code"55113-5"
$displayName = ClinicalDocument/code/@displayName"Key images Document Radiology"
$codeSystem = ClinicalDocument/code/@codeSystem "2.16.840.1.113883.6.1"<pre class="ILFgreenilfbox_code"><RegistryPackage
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
<Classification
classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
classifiedObject="theDocumentKeyImageObject"
nodeRepresentation="$code">
<Name>
</Classification>
</RegistryPackage>
</pre>Jeder Container darf dementsprechend nur 1 Objekt enthalten.
===uniqueId===
Das ''uniqueId'' Element beschreibt den global eindeutigen Identifier des DokumentsObjektes. Dieser Identifier wird entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.uniqueId wird als ebRIM
Im Fall eines CDA R2 Dokuments KOS-Objektes gilt folgende Verknüpfung mit den CDA Header ElementenMetadaten:# Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer ID für das Dokument verpflichtend:## ClinicalDocument/id
(0008,0018) SOP Instance UID (VR:UI, VM:1)
====Spezifikation====
uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:<br/> Fall 1<br/>Attribut ClinicalDocument/id/@extension ist nicht vorhanden
$value = concat(ClinicalDocument/id/@root0008,0018)SOP Instance UID
<ExternalIdentifier
registryObject="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"
===referenceIdList===
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
Dieser Datentyp ist in IHE_ITI_TF_Rev10.0_Vol3_FT_2013-09-27 in der Table 4.2.3.1.7-2: 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
Therefore, Universal Id Type is always ISO. The required format is: <br />IdNumber^^^&OIDofAA&ISO<br />No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above.<br />An explicit example is:<br />543797436^^^&1.2.840.113619.6.197&ISO<br />Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||'''This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.''' *'''CXi.1 shall be present and hold the identifier value.'''*'''CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.'''*'''CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.'''*'''When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.'''*'''No other components shall be present.'''
|}
{{BeginYellowBox}}
'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.
{{EndYellowBox}}
====Versionierung bzw. Versionsklammer (ownDocument_setId)====
Um eine eindeutige Identifikation aller registrierten Versionen eines Objektes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Es kann ein beliebiger Identifikator verwendet werden, solange er die Anforderung erfüllt, alle registrierten Versionen eines KOS-Objektes mit derselben ID eindeutig zu kennzeichnen. Als Best Practice für KOS wird die Verwendung von ''StudyInstanceUID'' vorgeschlagen.
$id = (0020,000D) VR=UI Study Instance UID, z.B. 1.2.40.0.34.99.111.1.1
"<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>", "^",
<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>ZZZZZZZZZZZZZZZZZZZ^^^&amp;amp;1.2.40.0.34.99.111.1.1 <nowiki>&</nowiki>amp;amp;ISO^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki> ^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.
====Referenz zwischen Dokument und Studie (Accession Number)====
Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (''acquisition, store'') als auch bei der Befundschreibung (''report'') verfügbar ist. Dies trifft auf die Accession Number zu (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).
$root, "&amp;ISO", "^",
)<pre class="ilfbox_code"<nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"
<ExtrinsicObject mimeType="text/xml"
objectType="<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><nowiki><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB220201111^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;1.2.25 40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elgaihe:iti:xds:20142013:ownDocument_setId^accession</nowiki> &amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"
===intendedRecipient=Referenz zwischen Aufenthaltszahl und Studie (encounterId)====Für Durch encounterId wird die spätere Verwendung von IHE Cross Enterprise Document Workflow Verlinkung sämtlicher Bilddaten (XDWDICOM KOS-Objekte) ist der intendedRecipient notwendig, die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-I Metadaten unterstützt. Derzeit wird dieses Element Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen den XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird, folgt die Spezifikation dieses Elementes.
encounterId wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
</pre>
===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)=Weitere Einträge der referenceIDList====Das ''healthcareFacilityTypeCode'' Element beschreibt Über die Klassifizierung des GDA.Es wird bereits genannten Einträge hinaus sind weitere Einträge in der Code aus dem CDA Header Element "healthCareFacility" genutzt.referenceIdList erlaubt:
==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==Spezifikation===availabilityStatus===Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Objektes.
availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>
===parentDocumentId, parentDocumentRelationshipformatCode (und formatCodeDisplayName)===Das ''parentDocumentIdformatCode'' Element verweist auf beschreibt das Dokument, zu dem das eingebrachte Dokument in einer bestimmten Relation stehtFormat des registrierten Objekts. Das Es ermöglicht einem empfangenden System (''parentDocumentRelationshipDocument Consumer Actor'' Element beschreibt den Typ der Relation (Versionierung, Transformation). Da nicht alle lokalen die Identifizierung des für die Weiterverarbeitung zu erwartenden Objektformats und temporären Versionen eines Dokuments veröffentlicht werden müssen, können somit die tatsächlichen korrekte Darstellung und technischen Dokumentenverweise in XDS nicht über die parentDocumentId erfasst werden, sondern über Association-Objekte. Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen: # Im CDA werden die Informationen über Dokumente, die mit dem eingebrachten Dokumenten in einer bestimmten Relation stehen, in folgendem Element abgelegt:## ClinicalDocument/relatedDocument# Der Typ der Relation MUSS verpflichtend in folgendem Attribut angegeben werden:## ClinicalDocument/relatedDocument/@typeCode## Folgende Relationen sind in ELGA erlaubt (siehe „[[ILF:Allgemeiner Implementierungsleitfaden 2020|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente]]“ [1]):### Versionierung (RPLC)# Das zugrundeliegende Dokument (auf welches die Art der Relation wirkt), wird in folgendem Element angegeben:## ClinicalDocument/relatedDocument/parentDocument <sup>16</sup> http://tools.ietf.org/html/rfc2045 <br/><sup>17</sup> http://tools.ietfVerarbeitung.org/html/rfc2049
====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
*158 "Fachärztin/Facharzt"
*300 "Allgemeine Krankenanstalt"
Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]".
{{EndYellowBox}}
====Spezifikation====
'''parentDocumentRelationshiphealthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' MUSS mit folgenden Elementen in CDA übereinstimmenwird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
<span>$displayName </span>= Klartext des angegebenen Codes
<span>$codeSystem </span>= OID der ausgebenden Stelle
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>
===mimeType===
Das ''mimeType'' Element beschreibt den "Internet Media Type" des Objektes gemäß dem "Multipurpose Internet Mail Extensions" (MIME) Standard. Der Standard wird beschrieben in RFC 2045<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref> und RFC 2049<ref name="RFC2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>.
====Spezifikation====
'''practiceSettingCode (und practiceSettingCodeDisplayName)mimeType''' wird gemäß folgender Vorschrift zusammengesetzt:im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, welches das DocumentEntry repräsentiert.
*application/dicom<rim:Classificationbr /> classificationScheme<pre class="ilfbox_code"> <ExtrinsicObject id="urn:uuid:cccf5598f0573b34-8b07ea9a-4b774c6d-a05e8556-ae952c785ead5cffbe50f027" classifiedObject mimeType="theDocumentapplication/dicom" nodeRepresentation objectType="$code"> <rimurn:Name> <rimuuid:LocalizedString value=34268e47-fdf5-41a6-ba33-82133c465248"$displayName"/> </rim:Name> <rim:Slot name status="codingScheme"> <rimurn:ValueList> <rimoasis:Value>urnnames:oidtc:$codeSystem</rimebxml-regrep:Value> </rimStatusType:ValueList> <Approved"/rim:Slot></rim:Classificationpre>
===practiceSettingCode (und practiceSettingCodeDisplayName)===
Das ''practiceSettingCode'' Element beschreibt die fachliche Zuordnung des Objektes. Es soll den Fachbereich wiedergeben, dem der Inhalt des Objektes am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung, z.B.:
*F044 "Radiologie"
*F052 "Unfallchirurgie"
==ELGA-spezifische Erweiterungen der XDS-Metadaten==
===elgaFlag===
Das elgaFlag dient zur Kennzeichnung eines Dokuments Objektes als „ELGA"ELGA-Dokument“Objekt"<sup>18</sup>. Ein XDS Source des ELGA-Bereiches sendet eine „XDS"XDS.b Provide and Register Transaktion [ITI-41]“", eine „XDS"XDS.b Register Document Transaktion [ITI-42]“ " oder eine „XDS "XDS Update Document [ITI-57]“ " an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut „elgaFlag“ "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. „elgaFlag“ "elgaFlag" kann folgende Werte annehmen:* "true" oder* "false"
====Spezifikation====
<suppre class="ilfbox_code">18<Slot name="urn:elga-bes:elgaFlag"> <ValueList> <Value>true</supValue> </ValueList></Slot></pre> Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.
===elgaHash===
Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine „XDS"XDS.b Provide and Register Transaktion [ITI-41]“", eine „XDS"XDS.b Register Document Transaktion [ITI-42]“ " oder eine „XDS "XDS Update Document [ITI-57]“ " an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot „ELGA"ELGA-Hash“ Hash" gespeichert.
Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.
====Spezifikation====
<pre class="ilfbox_code">
<rim:Slot name="urn:elga-bes:elgaHash">
<rim:ValueList>
</rim:ValueList>
</rim:Slot>
</pre>
=XDS Metadaten für CDA Dokumente=
Die folgenden Kapitel spezifizieren die XDS-Metadaten von HL7 CDA-Dokumenten für deren Verwendung in ELGA. Nicht angegebene Metadaten sind nicht weiter eingeschränkt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol. 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.<ref name="ITITF3"/>
==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==
|}
====Spezifikation====
'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br />
$code = ClinicalDocument/code/translation/@code<br />
$displayName = ClinicalDocument/code/translation/@displayName<br />
$codeSystem = ClinicalDocument/code/translation/@codeSystem<br />
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
classifiedObject="theDocument" nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>
===confidentialityCode===
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des Dokuments.
Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf Dokumente ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt.
Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich und wird fix auf "N" (normal) gesetzt.
Es wird der Vertraulichkeitscode aus dem CDA Header Element gemäß folgender Spezifikation übernommen:
====Spezifikation====
confidentialityCode wird als ebRIM Slot gemäß folgendem Beispiel abgebildet:<br />
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="theDocument" nodeRepresentation="N">
<Name>
<LocalizedString value="normal"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:2.16.840.1.113883.5.25</Value>
</ValueList>
</Slot>
</Classification></pre>
===creationTime===
Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden. Dieses Datum kann für die chronologische Sortierung der Befunde bei der Anzeige der Dokumentenliste verwendet werden.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
#Im CDA wird dieser Zeitpunkt wie folgt abgelegt:<br />ClinicalDocument/effectiveTime
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe verpflichtend.
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert.
#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:<br />@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)<br />Bsp: 20081224082015+0100<br />Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
# Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.
{{BeginYellowBox}}
CreationTime entfällt bei On-Demand Documenten.
{{EndYellowBox}}
Das Aktualisierungsdatum von Dokumenten (Update-Datum) kann über submissionTime (in XDS.submissionSet) erkannt werden.
====Spezifikation====
'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />
ClinicalDocument/effectiveTime/@value = "20200511193000+0200"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="creationTime">
<ValueList>
<Value>20200511173000</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.
{{BeginYellowBox}}
creationTime '''MUSS''' – entsprechend der tatsächlichen Angabe in CDA – entweder mit 8 Stellen (YYYYMMDD) oder 14 Stellen (YYYYMMDDhhmmss) angegeben werden. Ein "Kürzen" auf andere Formate ist nicht zulässig.
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 />
<span>$code </span>= ClinicalDocument/documentationOf[n]/serviceEvent/code/@code<br />
<span>$displayName</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName<br />
<span>$codeSystem</span> = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem<br />
<pre class="ilfbox_code">
<Classification
classificationScheme=
"urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
classifiedObject="theDocument"
nodeRepresentation="$code">
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
<Name>
<LocalizedString value="$displayName"/>
</Name>
</Classification>
</pre>
====Spezielle Vorschriften laut IHE PCC====
Das IHE Patient Care Coordination (PCC) Technical Framework vol. 2<ref name="IHEPCC"/> definiert in Kapitel "Medical Document Binding" Spezialbehandlungen für gewisse Dokumenttypen (z.B.: XD-Lab, XDS-SD, BPPC).
Diese speziellen Vorschriften werden in ELGA '''nicht''' angewandt.
===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====
'''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/languageCode/@code = "de-AT"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="languageCode">
<ValueList>
<Value>de-AT</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
===legalAuthenticator===
Das ''legalAuthenticator'' Element beschreibt die Identifikation und demographische Informationen der Person, welche das Dokument rechtlich verbindlich unterzeichnet hat. Entfällt bei automatisch erstellten und nicht durch natürliche Personen freigegebenen Dokumenten (z.B. On-Demand Documents wie der "Medikationsliste").
Für CDA R2 Dokumente gilt folgende Verknüpfung mit den CDA Header Elementen:
#Laut Festlegung wird die Person, welche das Dokument vidiert hat, im Element "legalAuthenticator" abgelegt:
##ClinicalDocument/legalAuthenticator/assignedEntity
{{BeginYellowBox}}
'''ACHTUNG:''' Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste Element (ClinicalDocument/LegalAuthenticator[1]) übernommen werden.
{{EndYellowBox}}
Ein Personenelement in CDA beinhaltet unter anderem die folgenden Unterelemente
#id … ID der Person mit den folgenden Attributen:
##@root … Root OID des ID Pools, oder direkt die OID der Person (ohne @extension-Attribut)
##@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
#assignedEntity
##Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
###Name
====Spezifikation====
'''legalAuthenticator''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:<br />
<span> $person </span>= ClinicalDocument/legalAuthenticator/assignedEntity
concat(<br />
<span> $person</span>/id/@extension,"^",<br />
<span> $person</span>/assignedPerson/name/family,"^",<br />
<span> $person</span>/assignedPerson/name/given[1],"^",<br />
<span> $person</span>/assignedPerson/name/given[2],"^",<br />
<span> $person</span>/assignedPerson/name/suffix,"^",<br />
<span> $person</span>/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;",<br />
<span> $person</span>/id/@root,"&amp;ISO"<br />
)<br />
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="legalAuthenticator">
<ValueList>
<Value>1234^Musterdoktor^Herbert^^^Dr.^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO</Value>
</ValueList>
</Slot>
</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}}
Es soll jeweils das erste '''serviceEvent''' für das Mapping verwendet werden.
{{EndYellowBox}}
====Spezifikation====
'''serviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/documentationOf/serviceEvent/effectiveTime/low/@value = "20200511193000+0200"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="serviceStartTime">
<ValueList>
<Value>20200511173000</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.
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="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.
Wenn Datumselemente in CDA mit Zeit angegeben sind, so wird gemäß ELGA Leitfaden ebenfalls eine Zeitzone mit angegeben (z.B. 20200516133000+0200). In den XDS Metadaten können jedoch keine Zeitzonen abgebildet werden. Falls eine Zeit angegeben ist, '''MUSS''' diese zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! (z.B. in 20200516113000).
{{EndYellowBox}}
===sourcePatientId===
Das ''sourcePatientId'' Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
#Im CDA wird die ID des Patienten in folgendem Element abgelegt:
##ClinicalDocument/recordTarget/patientRole/id
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe von mindestens den folgenden zwei IDs des Patienten im CDA verpflichtend bzw. verpflichtend, wenn bekannt:
##id[1] … ID des Patienten vom einbringenden (lokalen) System
##id[2] … Österreichische Sozialversicherungsnummer (nur wenn bekannt)<br /><span style="color:red;">Achtung: Diese ID gelangt nicht in die Metadaten!</span>
====Spezifikation====
'''sourcePatientId''' wird gemäß folgender Vorschrift zusammengesetzt:
concat(
ClinicalDocument/recordTarget/patientRole/id[1]/@extension,
"^^^&amp;",
ClinicalDocument/recordTarget/patientRole/id[1]/@root,
"&amp;ISO"
)
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientId">
<ValueList>
<Value>4711^^^&amp;1.2.3.4.5.6.7.8.9&amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.
{{BeginYellowBox}}
Ein spezieller Leitfaden kann eine abweichende Mapping-Vorschrift definieren!
{{EndYellowBox}}
===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.
{{BeginYellowBox}}
In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
{{EndYellowBox}}
===title===
Das ''title'' Element beschreibt den lesbaren Titel des Dokuments.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumententitels verpflichtend:
##ClinicalDocument/title
====Spezifikation====
'''title''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:
ClinicalDocument/title
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Name>
<LocalizedString charset="UTF-8" value="Entlassungsbrief der chirurgischen Abteilung" xml:lang="de-AT" />
</Name>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
{{EndYellowBox}}
===typeCode (und typeCodeDisplayName)===
Das ''typeCode'' Element beschreibt den 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'''
|'''Dokumentenklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
|classCode
|Dokumentenklasse in grober Granularität.<br /> Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29_2|classCode]]
|}
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
#Im CDA wird die Klassifizierung des Dokuments wie folgt abgelegt:
##ClinicalDocument/code
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe 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.
====Spezifikation====
'''typeCode (und typeCodeDisplayName)''' wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:
<span> $code</span> = ClinicalDocument/code/@code<br />
<span> $displayName</span> = ClinicalDocument/code/@displayName<br />
<span> $codeSystem</span> = ClinicalDocument/code/@codeSystem<br />
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="theDocument"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>
====submissionSet.contentTypeCode====
Der contentTypeCode des Submission Sets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.
$code = ClinicalDocument/code/@code
$displayName = ClinicalDocument/code/@displayName
$codeSystem = ClinicalDocument/code/@codeSystem
<pre class="ilfbox_code">
<RegistryPackage
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
<Classification
classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
classifiedObject="theDocument"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</RegistryPackage>
</pre>
===uniqueId===
Das ''uniqueId'' Element beschreibt den global eindeutigen Identifier des Dokuments. Dieser Identifier wird entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer ID für das Dokument verpflichtend:
##ClinicalDocument/id
====Spezifikation====
uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:<br />
Fall 1<br />
Attribut ClinicalDocument/id/@extension ist nicht vorhanden
$value = concat(ClinicalDocument/id/@root)
Fall 2<br />
Attribut ClinicalDocument/id/@extension ist vorhanden
$value = concat(
ClinicalDocument/id/@root, "^",
ClinicalDocument/id/@extension
)
<pre class="ilfbox_code">
<ExternalIdentifier
registryObject="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"
identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab"
value="$value">
<Name>
<LocalizedString value="XDSDocumentEntry.uniqueId"/>
</Name>
</ExternalIdentifier></pre>
===referenceIdList===
Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE ITI TF-3<ref name="ITITF3"/> (27 September 2013) Dokument neu hinzugekommen. Für CDA-Befunde sind drei unterschiedliche Einträge in referenceIdList vorgesehen:
#eindeutige Identifikation aller Dokumente eines Dokumentenstammes, d.h. vorhergehende und auch zukünftige Versionen (ownDocument_setId, M [1..1])
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number, O [0..*])
#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).
{{BeginYellowBox}}
Im Rahmen von ELGA MUSS die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten strukturiert sein.
{{EndYellowBox}}
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.
Dieser Datentyp ist in IHE ITI TF-3<ref name="ITITF3"/> Data Types in folgender Weise spezifiziert:
{| class="wikitable" width="100%"
!Data Type||Source Standard||Encoding Specification
|-
|CX||HL7 V2.5 Identifier||This is an identifier. HL7 Identifier type CX consists of several components, but this specification restricts them to the use of two components, the Id Number, and the Assigning Authority (AA). The Assigning Authority identifies the "domain" over which the Id Number represents a unique entity. Furthermore, the AA is characterized by a Universal Id and Universal Id Type. In Document Sharing profiles, ISO Object Identifiers (see OID below) must be used as Universal Id.<br />
Therefore, Universal Id Type is always ISO. The required format is: <br />IdNumber^^^&OIDofAA&ISO<br />No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above.<br />An explicit example is:<br />543797436^^^&1.2.840.113619.6.197&ISO<br />Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.
*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}
{{BeginYellowBox}}
'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt, wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.{{EndYellowBox}}
====Versionierung bzw. Versionsklammer (ownDocument_setId)====
Um eine eindeutige Identifikation aller registrierten Versionen eines CDA R2 Dokumentes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Es kann ein beliebiger Identifikator verwendet werden, solange er die Anforderung erfüllt, alle registrierten Versionen eines CDA R2 Dokuments mit derselben ID eindeutig zu kennzeichnen. Für ELGA wird dazu ownDocument_setId definiert, die auf dem CDA Header-Element "setId" basiert.
Aus dem "Allgemeinen Implementierungsleitfaden" [1]: "''Die setId bezeichnet das Set von Dokumenten, die zu einer Reihe von Versionen gehören. Sie bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten).''"
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
#Laut Vorgabe der ELGA Dokumenten Leitfäden ist die Angabe einer setId für das Dokument verpflichtend:
#*ClinicalDocument/setId [M]
=====Spezifikation=====
ownDocument-SetId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
concat
(
ClinicalDocument/setId/@extension, "^^^", "&amp;",
ClinicalDocument/setId/@root, "&amp;ISO", "^",
"<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>", "^", "&amp;",
homeCommunityId, "&amp;ISO"
)
Bitte beachten Sie, dass sowohl die ClinicalDocument/setId/@root als auch die homeCommunityId in der Schreibweise "&", OID-Wert, "&ISO" anzugeben sind.
Beispiel 1: setId/@root und setId/@extension sind im CDA strukturiert. In /@extension wird KEINE UUID angegeben.
<pre class="ilfbox_code">
<ClinicalDocument xmlns="urn:hl7-org:v3">
…
<setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZZZZZ"/>
<versionNumber value="2"/>
…
</ClinicalDocument>
</pre>
Wie oben angeführt wird folgender CXi Wert erstellt:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList> <Value>ZZZZZZZZZZZZZZZZZZZ^^^&amp;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>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.
Beispiel 2: in setId/@extension im CDA wird eine UUID geführt
<pre class="ilfbox_code">
<ClinicalDocument xmlns="urn:hl7-org:v3">
…
<setId root="2.25" extension="urn:uuid:19FEE6C3-6B35-4C5B-B1CC-2B5B4001AB2"/>
<versionNumber value="2"/>
…
</ClinicalDocument>
</pre>
Wie oben angeführt wird folgender CXi Wert erstellt:
"<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="<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'') als auch bei der Befundschreibung (''report'') verfügbar ist. Dies trifft auf die Accession Number zu (bzw. ein vergleichbares Element, das im implementierten Workflow zur Verknüpfung von Studie und Befund verwendet wird).
=====Spezifikation=====
Für Befunde der bildgebenden Diagnostik (diagnostic image report) KANN als Accession Number jene aus der ReferenceIdList der XDS-I Metadaten des KOS Objektes, mit dem eine Verlinkung hergestellt werden soll, genutzt werden. Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
$id = Accession Number z.B. 20201111
$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1
concat
(
$id, "^^^", "&amp;"
$root, "&amp;ISO", "^",
"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>20201111^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"
<br />
Zwei oder mehre Accession Number werden beispielsweise wie folgt zusammengesetzt:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>20201111^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
<Value>20201112^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"
<br />
====Verlinkung via Aufenthaltszahl (encounterId)====
Durch encounterId wird die Verlinkung sämtlicher Befunde oder Bilddaten (siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#referenceIdList|referenceIdList]] für Dicom KOS-Objekte), die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-Metadaten unterstützt. Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-/XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird.
<br />
=====Spezifikation=====
encounterId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:
concat
(
ClinicalDocument/componentOf/encompassingEncounter/id/@extension, "^^^", "&amp;",
ClinicalDocument/componentOf/encompassingEncounter/id/@root, "&amp;ISO", "^",
"<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"
)
Bitte beachten Sie, dass die ClinicalDocument/componentOf/encompassingEncounter/id/@root
in der Schreibweise "&", OID-Wert, "&ISO" anzugeben ist.
Wie oben angeführt wird folgender CXi Wert erstellt:<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>Az123456^^^&amp;1.2.40.0.34.99.4613.3.4&amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>
</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
<br />
===intendedRecipient===
Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der intendedRecipient notwendig. Derzeit wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.
Der intendedRecipient entfällt bei On-Demand Documents.
==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
===availabilityStatus===
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Dokuments.
Mögliche Werte laut IHE sind:
*Approved
*Deprecated
Dieses Attribut wird im Zuge des Einbringens von neuen Dokumenten ("Submission") durch die empfangende XDS Registry immer auf "'''Approved'''" gesetzt.
availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>
===formatCode (und formatCodeDisplayName)===
Das ''formatCode'' Element beschreibt das Format des Dokuments bezüglich seiner semantischen Interoperabilität. Es ermöglicht einem empfangenden System (''Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Dokumentenformats und somit die korrekte Darstellung und Verarbeitung des Dokuments.
Im CDA-Schema wurde für die HL7-Austria Domäne ein genau entsprechendes Element geschaffen, "hl7at:formatCode".
====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:<br />
<span>$code</span> = ClinicalDocument/hl7at:formatCode/@code <br />
<span>$displayName</span> = ClinicalDocument/hl7at:formatCode/@displayName <br />
<span>$codeSystem</span> = ClinicalDocument/hl7at:formatCode/@codeSystem
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>
===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA.
Es wird der Code aus dem CDA Header Element "healthCareFacility" genutzt.
====Spezifikation====
'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:
<span>$code </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code
<span>$displayName </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName
<span>$codeSystem </span>= ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@codeSystem
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>
===mimeType===
Das ''mimeType'' Element beschreibt den "Internet Media Type" des Dokuments gemäß dem "Multipurpose Internet Mail Extensions" (MIME) Standard. Der Standard wird beschrieben in RFC 2045 bis RFC 2049.<ref name="RFC2045"/>
<ref name="RFC2046">Multipurpose Internet Mail Extensions (MIME) Part Part Two: Media Types [http://tools.ietf.org/html/rfc2046 IETF RFC 2046]</ref>
<ref name="RFC2047">Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text [http://tools.ietf.org/html/rfc2047 IETF RFC 2047]</ref>
<ref name="RFC2048">Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures [http://tools.ietf.org/html/rfc2048 IETF RFC 2048]</ref>
<ref name="RFC2049"/>
Im Fall von CDA R2 Dokumenten ist der Mime Type laut IHE immer fix "text/xml".
====Spezifikation====
'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, welches das DocumentEntry repräsentiert.
Folgende Mime-Types sind für Dokumente zugelassen:<br />
CDA R2: '''text/xml'''<br />
<pre class="ilfbox_code">
<ExtrinsicObject
id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
mimeType="text/xml"
objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>
</pre>
===parentDocumentId, parentDocumentRelationship===
Das ''parentDocumentId'' Element verweist auf das Dokument, zu dem das eingebrachte Dokument in einer bestimmten Relation steht.
Das ''parentDocumentRelationship'' Element beschreibt den Typ der Relation (Versionierung, Transformation).
Da nicht alle lokalen und temporären Versionen eines Dokuments veröffentlicht werden müssen, können die tatsächlichen und technischen Dokumentenverweise in XDS nicht über die parentDocumentId erfasst werden, sondern über Association-Objekte.
Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:
#Im CDA werden die Informationen über Dokumente, die mit dem eingebrachten Dokumenten in einer bestimmten Relation stehen, in folgendem Element abgelegt:
##ClinicalDocument/relatedDocument
#Der Typ der Relation MUSS verpflichtend in folgendem Attribut angegeben werden:
##ClinicalDocument/relatedDocument/@typeCode
##Folgende Relationen sind in ELGA erlaubt (siehe "[[ILF:Allgemeiner Implementierungsleitfaden 2020|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente]]" [1]):
###Versionierung (RPLC)
#Das zugrundeliegende Dokument (auf welches die Art der Relation wirkt), wird in folgendem Element angegeben:
##ClinicalDocument/relatedDocument/parentDocument
====Spezifikation====
'''parentDocumentId''' MUSS mit folgenden Elementen in CDA übereinstimmen:
concat(
ClinicalDocument/relatedDocument/parentDocument/id/@root,"^",
ClinicalDocument/relatedDocument/parentDocument/id/@extension
)
'''parentDocumentRelationship''' MUSS mit folgenden Elementen in CDA übereinstimmen:
ClinicalDocument/relatedDocument/@typeCode
===practiceSettingCode (und practiceSettingCodeDisplayName)===
Das ''practiceSettingCode'' Element beschreibt die fachliche Zuordnung des Dokumentes. Es SOLL den Fachbereich wiedergeben, dem der Inhalt des Dokuments am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung.
Im CDA-Schema wurde für die HL7-Austria Domäne ein entsprechendes Element in den CDAs geschaffen, "hl7at:practiceSettingCode".
====Spezifikation====
'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classificationgemäß folgender Vorschrift zusammengesetzt:
<span>$code</span> = ClinicalDocument/hl7at:practiceSettingCode/@code<br />
<span>$displayName</span> = ClinicalDocument/hl7at:practiceSettingCode/@displayName<br />
<span>$codeSystem</span> = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem<br />
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>
===objectType===
Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "stabiles Dokument" (stable document, SD) und "On-demand Dokument" (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.
Für "Stable Document" DocumentEntry:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>
Für "On-Demand Document" DocumentEntry:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>
==ELGA-spezifische Erweiterungen der XDS-Metadaten==
Die folgenden Daten erweitern den IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt.
===elgaFlag===
Das elgaFlag dient zur Kennzeichnung eines Dokuments als "ELGA-Dokument"<sup>18</sup>. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:
*"true" oder
*"false"
<sup>18</sup> Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.
====Spezifikation====
<pre class="ilfbox_code">
<Slot name="urn:elga-bes:elgaFlag">
<ValueList>
<Value>true</Value>
</ValueList>
</Slot>
</pre>
===elgaHash===
Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot "ELGA-Hash" gespeichert.
Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.
====Spezifikation====
<pre class="ilfbox_code">
<rim:Slot name="urn:elga-bes:elgaHash">
<rim:ValueList>
<rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>
</rim:ValueList>
</rim:Slot>
</pre>
<!--Anhänge-->
=Anhänge=
==Einzelnachweise==
<references />
==Literatur und Weblinks ==
* IHE International https://www.ihe.net/
* HL7® International http://www.hl7.org/
* Clinical Document Architcture (CDA®) Release 2.0 https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
* DICOM® — Digital Imaging and Communications in Medicine https://www.dicomstandard.org/
* Österreichische CDA Implementierungsleitfäden [https://wiki.hl7.at/index.php?title=Implementierungsleitf%C3%A4den HL7 Austria Wiki]
==Revisionsliste==
===Hauptversion 3.0.0 (2021)===
Diese Hauptversion wurde auf Basis der neuen Vorgaben aus dem Allgemeinen Implementierungsleitfaden 3.0.0 grundlegend überarbeitet und umstrukturiert. Hinzugekommen sind die Vorgaben für die Registrierung von DICOM KOS-Objekten. Auf eine Revisionsliste mit direktem Vergleich zur Vorversion wurde daher verzichtet.
Die relevanten Änderungen sind:
{| class="wikitable"
|-
|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;"
|-
|"referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
|-
|"Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
|-
|"Spezifikation": Verbot von CR und LF hinzugefügt.
|-
|"Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
|-
|"sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
|-
|"legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
|-
|"creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
|-
|"healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
|-
|"formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
|-
|"Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
|-
|"XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.
|-
|"referenceIdList": Ergänzung der Verwendung der encounterId
|}
===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.
