Änderungen

|title=XDS Metadaten 3.0.01

{{#customtitle:XDS -Metadaten (Version 3.0.01+20211001)}}

Implementierungsleitfaden "XDS -Metadaten (Version 3.0.0)"

|Group = ELGA CDA Implementierungsleitfäden|Title = ELGA Implementierungsleitfaden XDS -Metadaten (XDSDocumentEntry)|Subtitle Title = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA (Version 3)|Subtitle = Zur Anwendung im österreichischen Gesundheitswesen [1.2.40.0.34.7.6.9.3]|Short = XDS -Metadaten

|Version = 3.0.01+20211001

|Date = Februar 01.10.2021

|Status = KommentierungNormativ

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

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 (GTelG)https://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=Bundesnormen&Gesetzesnummer=20008120]</ref> . Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti (IHE 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>.

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

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

Grundlage dieses Implementierungsleitfadens ist der internationale Standard IHE ITI Cross-enterprise Document Sharing <ref name="IHE ITI"></ref> von Integrating the Healthcare Enterprise (IHE)<ref name="IHE">Integrating the Healthcare Enterprise (IHE) International, Incorporated [http://www.ihe.net http://www.ihe.net]</ref>.

Weiters bezieht sich dieser Leitfaden auf den internationalen Standard "HL7® Clinical Document Architecture, Release 2.0" (CDA ®)<ref name="CDA"></ref> , für die das Copyright © von Health Level Seven International<ref name="HL7">Health Level Seven International [http://www.hl7.org www.hl7.org]</ref> gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert<ref name="ISO CDA">ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical Document Architecture, Release 2 [https://www.iso.org/standard/44429.html https://www.iso.org/standard/44429.html]</ref>. CDA definiert die Struktur und Semantik von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und Patienten. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen. Die Dokumentmetadaten für CDA Dokumente im Österreichischen Gesundheitswesen werden grundsätzlich vom "Allgemeinen CDA Implementierungsleitfaden" <ref name="ALF">Allgemeiner Implementierungsleitfaden für CDA Dokumente [[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_(Version_3) https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_2020]Allgemeiner_Implementierungsleitfaden_(Version_3)]</ref> definiert.Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at]). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.

Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020Version 3]''' und gilt entsprechend für alle CDA-Dokumente, die auf Basis des Leitfadens erstellt werden.

*ELGA-Gesamtarchitektur<ref name="ELGA-Gesamtarchitektur">ELGA-Gesamtarchitektur 2.30a [http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ ELGA Gesamtarchitektur 2http://www.elga.gv.30aat/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>

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

! colspan="2" style="text-align:left" |Autoren|- ! style="text-align:left" width="10%" |Organisation|| style="text-align:left" width="60%" |Person¹|- style="background:#FFEBAD"| colspan="2" style="text-align:left" |Herausgeber, Projektleiter, CDA-Koordinator|- |ELGA GmbH||Stefan Sabutsch|- style="background:#FFEBAD"| colspan="32" style="text-align:left"| Autoren

! style="text-align:left" width="10%" | Kürzel CodeWerk Software Services and Development GmbH||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person¹Jürgen Brandstätter|- style="background:#FFEBAD"| style="text-align:left" colspan="3" | Herausgeber, Projektleiter, CDA-Koordinator|- style="background:#FFFFFF"| SSA || ELGA GmbH || Stefan SabutschDICOM Austria|- style="background:#FFEBAD"Emmanuel Helm| style="text-align:left" colspan="3" | Autoren |- style="background:#FFFFFF"DICOM Austria| JB|| CodeWerk Software Services and Development GmbH|| Jürgen BrandstätterSilvia Winkler|- style="background:#FFFFFF"| SSA|| ELGA GmbH, HL7 Austria||Stefan Sabutsch|- style="background:#FFFFFF"| OKU|| ELGA GmbH|| Oliver Kuttin|- style="background:#FFFFFF"| KHOELGA GmbH|Stefan Repas|- | Wiener Krankenanstaltenverbund|| Konrad Hölzl

Dieses Dokument definiert die Metadaten für beim Einbringen von Dokumenten in Form von Befunden<ref name="ALF"></ref> oder Bilddaten in der die ELGA-Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet:* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumente (Metadaten der XDSDocumentEntry Objekte): ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 1712.0 (1622.94.20202016) Final Text ''<ref name="IHE ITI TF-3ITITF3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 1712.0 (20202016) [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol3IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf IHE https://www.ihe.net/uploadedFiles/Documents/ITI TF Vol/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.3pdf], zuletzt besucht am 25.01.2021</ref>

Ausgehend von obiger Basis definiert das vorliegende Dokument die genaue Spezifikation der Befüllung der XDS Metadaten speziell für die Anwendung im Rahmen der österreichischen Gesundheitsakte ELGA. Die Spezifikation wurde im Zusammenhang mit dem "Allgemeinen Implementierungsleitfaden"<ref name="ALF"></ref>, den "ELGA CDA Implementierungsleitfäden" und dem Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch <ref name="KOS-Leitfaden">DICOM Austria: Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch [https://collab.dicom-austria.at/pages/viewpage.action?pageId=27033635 DICOM Austria KOS Leitfaden], zuletzt besucht am 19.02.2021</ref> erstellt.

Eine Mit Ausnahme der Kapitel "5.1.12.2 submissionSet.contentTypeCode" und "6.1.12.2 submissionSet.contentTypeCode" wird keine weitere Profilierung des XDS SubmissionSets Submission Sets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.  Etwaige, Service-spezifische, Vorgaben auf Schnittstellen-Ebene sind in den entsprechenden Schnittstellenspezifikationen (u.a. Schnittstellen Berechtigungssystem, Schnittstellenspezifikation zur Anbindung des elektronischen Impfpasses) angeführt und im Rahmen konkreter System-Anbindungen zu berücksichtigen.

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

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

Dokumente werden "storniert", indem der Dokumentstatus auf "deprecated" gesetzt wird und keine neue Dokumentenversion registriert wird. Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde. ====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"<ref name="OrgaHandb">Organisationshandbuch ELGA-Bereiche und Krankenanstalten [https://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ https://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>.

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

Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE "IT-Infrastructure" (ITI) Technical Framework, Volume 3 festgelegt (IHE ITITF-TF33).<ref name="IHE ITI TF-3ITITF3"></ref>.

'''Hinweis:''' Siehe auch Vorschriften zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3ITITF3"></ref>.

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

Die genaue Beschreibung der einzelnen XDS Metadaten Bindings sind im IHE "Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2, Kapitel XDSDocumentEntry Metadata beschrieben.<ref name="IHEPCC">IHE ITI">Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2 [https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf]</ref>

Die genaue Beschreibung für On-Demand Documents findet sich IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3ITITF3"></ref>.

# '''Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können(XDS Document Source)'''

|Die Personoder das Gerät, welche (s) das Dokument verfasst hat

|AE1/K

|AE1/K

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

|Zeitpunkt der DokumentenerstellungErstellung des registrierten Dokuments oder Objektes

| colspan="2" |'''eventCodeDisplayName'''

|'''M NP [10..10]'''|K-

| colspan="2" |'''Titletitle'''

|K/E1

|'''NP [0..0]'''[[#%20ftn1|<nowiki/>]][[#%20ftn1|<nowiki/>]]

In der Tabelle 4 6 werden die XDS-Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität), jeweils für Stable Documents (SD) und On-Demand-Documents (ODD) angegeben.  ToDo: @oliver EncounterID wird zu ID, optional lassen

| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''|

| rowspan="2" style="text-align:left" |'''Beschreibung '''

|'''SD'''⁹||'''||ODD'''OD¹⁰'''

| colspan="2" |'''creationTime'''||'''M [1..1]'''||'''M NP [10..10]'''|C||Zeitpunkt der DokumentenerstellungMedizinisch relevantes Datum, je nach Definition im speziellen Leitfaden

|A||<span style="color:red;">'''Wird in XDS nicht verwendet'''</span>

¹⁰ ODODD: "On-demand Document": Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird. <br />¹¹ Der Inhalt des typeCodes soll mit dem contentTypeCode des SubmissionSets Submission Sets übereinstimmen.<br />

Die folgenden Kapitel spezifizieren die XDS-I Metadaten von DICOM KOS-Objekten für deren Verwendung in ELGA. Nicht weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, vol3, rev. 17, Vol 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.<ref name="IHE ITI TF-3ITITF3"></ref>.

''Tabelle 67: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet''

| colspan="2" |'''XDS-I Metadaten Element'''

| colspan="2" |author

||colspan="3" |

|(0008,0080)

| colspan="2" |creationTime

| colspan="2" |eventCodeList

|Enthält den eine Liste von Codes von Gesundheitsdienstleistungen nach APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten[https:<nowiki//collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten >https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten]</ref>

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom"/>

| colspan="2" |serviceStartTime

| colspan="2" |sourcePatientId

| colspan="2" |sourcePatientInfo

| colspan="2" |title

| colspan="2" |uniqueId

| colspan="2" |referenceIdList

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

|O R [0..1]

|Die IdID, die zur Verlinkung mit dem Befund heranzuziehen ist.

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

| colspan="2" |comments

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

<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;amp;ISO </Value>

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

#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den folgenden DICOM Attribut Modality der Studie 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 http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1]</ref>

<Value>2323^MusterDoc^&amp;amp;1.2.40999.01.34.99.46132.3.3&amp;amp;ISO 1375^Welby^Marcus^^MD^Dr</Value>

Dies entspricht einer Transformation folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf den HL7 v2 die XCN Datentyp gemäß [Komponenten wie in IHE ITIRAD TF-TF32 Rev.19 2020<ref name="IHERADTF2">IHE Radiology (RAD) Technical Framework Volume 2x Rev.19, 2020 [https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf]</ref>, "Table 4.68.4.1.2.3-3: XCN Data type mapping" vorgegeben. 

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

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

Zulässige Werte gemäß Value Set "[ELGA_Confidentiality" <ref name="ConfVS">Value Set "ELGA_Confidentiality" https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]"</ref>.

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

#Sollten Sollte das zuvor genannte Attribut nicht verfügbar sein, muss alternativ das Erstellungsdatum des KOS Objektes verwendet werden:

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

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

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

#Das Erstellungsdatum des DICOM Objektes der Studie (aus den Attributen des dem KOS ObjektesObjekt oder bevorzugt der DICOM Studie):

<br /><pre class="ilfbox_code">

<Value>4711^^^&amp;amp;1.2.3.4.5.6.7.8.9&amp;amp;ISO</Value>

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

Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel [[ILF:XDS_Metadaten_(Version_3)#sourcePatientId|SourcePatientId]] gemappt und verwendet.

====Spezifikation (empfohlene Variante)=title===Das '''sourcePatientInfo'title'' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:Element beschreibt den lesbaren Titel des registrierten Objektes.

$patientID, "^^^&amp;amp;", $oid, "&amp;amp;ISO" ) Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO $name = ""  $birthtime = ""  $gender = ""  $addr = "" <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="sourcePatientInfo"> <ValueList><Value>PID-3|$id</Value><Value>PID-5|$name</Value><Value>PID-7|$birthtime</Value><Value>PID-8|$gender</Value><Value>PID-11|$addr</Value> </ValueList> </Slot></ExtrinsicObject></pre> ===title===Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes. Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten: #Wenn die Informationen aus der Studie verfügbar sind: Study Description#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +#*(0008,1030) Study Description, Datentyp LO

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

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

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

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

Dieser Datentyp ist in IHE ITI Data Types in folgender Weise spezifiziert:<ref name="IHE ITI TFITITF3"/><!-- Seitenumbruch -3-><p style="page-break-before: always"></refp> 

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

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

"<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>", "^",

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

<ValueList> <Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999 <nowiki>&</nowiki>amp;amp;ISO</Value>

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

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

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

<ValueList> <Value>Az123456^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.4613.3.4 <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki> </Value>

<ValueList> <Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^amp;1.2.40.0.34.99.999 <nowiki>&</nowiki>amp;amp;ISO</Value> <Value>20201111^^^amp;1.2.40.0.34.99.999 <nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value> <Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value> <Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>

Der intendedRecipient entfällt bei der Registrierung von KOS Objekten via XDS-I.

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 [httpshttp://tools.ietf.org/html/rfc2045 <nowiki>IETF RFC 2045[6]</nowikiref>] und RFC 2049.<ref name="RFC2045RFC2049">Multipurpose Internet Mail Extensions (MIME) Part OneFive: Format of Internet Message Bodies Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2045 rfc2049 IETF RFC 20452049]</ref>.

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

Für KOS Objekte wird der fixe Wert "[[<nowiki>urn:uuid:1e2ede827edca82f-8570054d-4be247f2-bd46a032-de986a4333be]]9b2a5b5186c1</nowiki>" für "Stable Document" vorgegeben:

<ExtrinsicObject mimeType="textapplication/xmldicom"

Die folgenden Kapitel spezifizieren die XDS-Metadaten von HL7 CDA-Dokumenten für deren Verwendung in ELGA. Nicht weiter eingeschränkte angegebene Metadaten sind nicht angeführtweiter eingeschränkt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, vol3, revVol. 17, 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.<ref name="IHE ITI TF-3ITITF3"></ref>

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

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

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

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

#Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R2R]'''''.

#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R2R]'''''.

======Spezifikation======

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

#Im CDA wird der dieser Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:##<br />ClinicalDocument/effectiveTime#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Elementverpflichtend.#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:#<br />@value … enthält das Datum in folgenden möglichen Formen

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

CreationTime entfällt bei On-Demand DocumentsDocumenten.

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

#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines ServiceEvents verpflichtend, wenn bekannt [R2R].

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

#Die vidierende Person##Ein Personenelement in CDA beinhaltet unter anderem die folgenden Unterelemente:###id … ID der Person mit den folgenden Attributen:####@root … Root OID des ID Pools, oder 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

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

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

##id[1] … Lokale ID des Patienten vom einbringenden (lokalen) System

Dies entspricht einer Transformation auf den HL7 v2 CX Datentyp gemäß [IHE ITITF-TF3]3<ref name="ITITF3"/>.{{BeginYellowBox}}Ein spezieller Leitfaden kann eine abweichende Mapping-Vorschrift definieren!{{EndYellowBox}}

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

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 IHE ITI TF-3<ref name="ITITF3"/> (27 September 2013) Dokument neu hinzugekommen. Für CDA-Befunde sind zwei 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..1])#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinichen medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).

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

Dieser Datentyp ist in IHE ITI TF vol3 -3<ref name="ITITF3"/> Data Types in folgender Weise spezifiziert:

"<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>", "^", "&amp;amp;",

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

====Verlinkung via Aufenthaltszahl Referenz zwischen Dokument und Studie (encounterIdAccession Number)====Durch encounterId Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird die Verlinkung sämtlicher Befunde oder Bilddaten ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (siehe [[ILF:XDS_Metadaten_''acquisition, store'') als auch bei der Befundschreibung (Version_3''report'')#referenceIdList|hier]] für Dicom KOS-Objekte), verfügbar ist. Dies trifft auf die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-Metadaten unterstütztAccession Number zu (bzw. Dies geschiehtein vergleichbares Element, indem dieselbe Aufenthaltszahl als encounterId in den XDS-/XDS-I Metadaten der zu gruppierenden Objekte strukturiert das im implementierten Workflow zur Verknüpfung von Studie und Befund verwendet wird).

ClinicalDocument/componentOf/encompassingEncounter/$id/@root, "&amp;amp;ISO", "^", = Accession Number z.B. 20201111

concat ( $id, "^^^", "&amp;amp;" $root, "&amp;amp;ISO", "^", "<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>" )<pre class="ilfbox_code"> <ExtrinsicObject mimeType="text/xml" objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>" id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>"> <Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>"> <ValueList> <Value>20201111^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value> </ValueList> </Slot> </ExtrinsicObject></pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"<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;amp;",  ClinicalDocument/componentOf/encompassingEncounter/id/@root, "&amp;amp;ISO", "^",  "<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"  )

<ValueList> <Value>Az123456^^^&amp;amp;1.2.40.0.34.99.4613.3.4&amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki> </Value> </ValueList>

Das ''mimeType'' Element beschreibt den "Internet Media Type" des Dokuments gemäß dem "Multipurpose Internet Mail Extensions" (MIME) Standard. Der Standard wird beschrieben in RFC 2045 bis RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>

<ref name="RFC2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>

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

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

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

|||Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId

|||Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.

|||Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.

|||Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.

|||Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich

|||Kapitel "4.2.7 legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.

|||Kapitel "4.2.4 creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert

|||Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.

|||Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.

|||Kapitel "4.2.2.1 Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.

|||Kapitel "XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.

|||Kapitel "5.1.14 referenceIdList" und "6.1.14 referenceIdList": Ergänzung der Verwendung der encounterId