HL7 Austria MediaWiki - Benutzerbeiträge [de]

ILF Diskussion:EMS Labor Arzt

2022-07-15T12:16:11Z

Kuttin: /* Ausblick */

=Erratum=
 
{| class="wikitable sortable"
|+
!Ticket
!Template / Element
!Beschreibung
!Status
!Datum
!Lösungs-Version
|-
|
| Reihenfolge der Header Elemente in Arzt- und Labormeldung
| Das "informationRecipient-Element" befand sich in der Spezifikation an der falschen Stelle. Dieses Element gehört vor den legalAuthenticator.
|behoben
|28.01.2021
|2020
|-
|
| Auflistung der Header-Element ohne speziellen Anforderungen
| Das "informationRecipient-Element" befand sich in der Auflistung, obwohl hier die allgemeinen Spezifikationen des allgemeinen Leitfadens weiter eingeschränkt wurden.
|behoben
|28.01.2021
|2020
|-
|
| Use Case Beschreibung "Gatewayapplikation" für Arztmeldung.
| Dieses Kapitel (6.8 Anwendungsfall EMS08: Arztmeldung "Gatewayapplikation") wurde gelöscht da der Anwendungsfall nicht mehr gültig ist.
|behoben
|16.12.2020
|2020
|-
| CSD-925
| ValueSets im Wiki nicht ausreichend referenziert
| Ein Kapitel "Terminologien" wurde ergänzt welches die Referenzen auf die notwendigen ArtDecor ValueSets enhält.
|behoben
|07.12.2020
|2020
|-
|
|[https://art-decor.org/art-decor/decor-templates--epims-?section=templates&id=1.2.40.0.34.6.0.11.1.37&effectiveDate=2020-02-20T10:55:54&language=de-DE Documentation Of Service Event - Physician Note]
|Das service Event für die Arztmeldung (Documentation Of Service Event -Physician Note) erfordert nun die Angabe eines Performers. Dieses Element entspricht dem performer-Element der Labormeldung (Documentation Of Service Event - Laboratory Report).
|behoben
|24.11.2020
|2020
|-
|
|[https://art-decor.org/art-decor/decor-templates--epims-?section=templates&id=1.2.40.0.34.6.0.11.3.60&effectiveDate=2020-11-10T14:38:39&language=de-DE EMS Hospitalisierung]
|Fixer act/code wurde durch ein ValueSet getauscht. Vorher war nur die Ausprägung Hospitalisierung möglich, nun kann auch angegeben werden, dass der Patient auf einer Intensivstation aufgenommen wurde.
|behoben
|10.11.2020
|2020

|}
==Ausblick==
{| class="wikitable sortable"
|+
!Ticket
!Template / Element
!Beschreibung
!Datum
!Geplante Lösungsversion
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1078 ELGA-1078]
|[https://art-decor.org/art-decor/decor-templates--epims-?section=templates&id=1.2.40.0.34.6.0.11.9.22&effectiveDate=2021-05-26T13:50:41&language=de-DE Assigned Entity 1.2.40.0.34.6.0.11.9.22]
|Der Assert, der verlangte, dass das Attribut telecom/@use generell bei mehreren "telecom"-Elementen angegeben werden MUSS, wurde entfernt.
|26.05.2021
|nächste Version
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1243 ELGA-1243]
|[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.9.32&effectiveDate=2022-07-12T08:54:29&language=en-US Vaccine Product]
[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.9.32&effectiveDate=2022-07-12T08:54:29&language=en-US 1.2.40.0.34.6.0.11.9.32]
|Klarstellung zur Verwendung des Handels- und Zulassungsnamens
|14.07.2022
|Patch
|}

=Bekannte Probleme=
==Fehler in der Übersichtstabelle der administrativen Daten==
* In der Tabelle [[ILF:EMS_Labor_Arzt#.C3.9Cbersicht_.C3.BCber_die_administrativen_Daten_.28CDA-Header-Elemente.29|7.1.1 Übersicht über die administrativen Daten (CDA-Header-Elemente)]] Für das "Meldende Labor" muss es richtig heißen "ClinicalDocument/documentationOf[2]/serviceEvent/performer" (statt falsch: "ClinicalDocument/documentationOf/serviceEvent[0]/performer")
* Im Wiki gehören die beiden DLTs eingebunden
* Falsche OID auf dem PDF-Titelblatt

=Diskussion=
==Header-Version==

ILF Diskussion:Ambulanzbefund (Version 1)

2022-07-15T12:07:59Z

Kuttin: /* Ausblick */

=Release-Log=
Korrekturen den Header betreffend, befinden sich auf der Diskussionsseite des [[ILF_Diskussion:Allgemeiner_Implementierungsleitfaden_2020|Allgemeinen Implementierungsleitfadens]].

{| class="wikitable sortable"
|+
!Ticket
!Template / Element
!Beschreibung
!Datum
!Änderungslevel
|-
|CSD-2083
|DLT Ambulanzbefund 1.2.40.0.34.6.0.11.0.5
|Neue Patchversion aufgrund von Anpassungen von Problem Entry
|03.06.2022
|1.3.1
|-
|CSD-2083
|Problem Entry 1.2.40.0.34.6.0.11.3.6
|Fehlerkorrektur: observation/effectiveTime/low geändert von 1..1 M zu 1..1 R, da der Nullflavor "UNK" zugelassen ist
|03.06.2022
|1.3.1
|-
|
|Konsultationsgrund Problem Entry 1.2.40.0.34.6.0.11.3.31
|Fehlerkorrektur: observation/effectiveTime/low geändert von 1..1 M zu 1..1 R, da der Nullflavor "UNK" zugelassen ist
|03.06.2022
|1.3.1
|-
|
|DLT Ambulanzbefund 1.2.40.0.34.6.0.11.0.5
|Neue Nebenversion aufgrund von Anpassungen des Implementierungsleitfadens e-Impfpass
|09.02.2022
|1.3.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1199 CSD-1199]
|DocumentLevelTemplate [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.0.5&effectiveDate=2021-10-27T13:18:25&language=de-DE 1.2.40.0.34.6.0.11.0.5]
|Anpassung ELGA-Dokumentenklasse: Diese ist nicht mehr aus dem Value Set ELGA_Dokumentenklasse_Ambulanzbefund zu entnehmen, sondern aus dem Unterknoten 75476-2 "Physician note" des Value Sets "ELGA_Dokumentenklassen"
|27.10.2021
|1.3.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1170 ELGA-1170]
|Konsultationsgrund Problem Entry [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.3.31&effectiveDate=2021-08-10T08:43:36&language=de-DE 1.2.40.0.34.6.0.11.3.31]
|Beschreibung von observation/code wurde korrigiert. Als "vocabulary" wird jetzt das neu benannte Value Set ELGA_TypeOfProblem_VS verlangt.
|10.08.2021
|1.2.1
|-
|
|Participant Fachlicher Ansprechpartner [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.20&effectiveDate=2021-08-03T11:02:47&language=de-DE 1.2.40.0.34.6.0.11.1.20]

Participant Auskunftsberechtigte Person (Notfallkontakt) [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.27&effectiveDate=2021-08-03T11:25:19&language=de-DE 1.2.40.0.34.6.0.11.1.27]
|Korrektur von "Telefon-Nummer" auf "Telefonnummer".
|03.08.2021
|1.2.1
|-
|
|Participant Hausarzt [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.23&effectiveDate=2021-08-03T11:32:38&language=de-DE 1.2.40.0.34.6.0.11.1.23]

Participant Auskunftsberechtigte Person (Notfallkontakt) [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.27&effectiveDate=2021-08-03T11:25:19&language=de-DE 1.2.40.0.34.6.0.11.1.27]

Participant Angehoerige [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.25&effectiveDate=2021-08-03T11:17:27&language=de-DE 1.2.40.0.34.6.0.11.1.25]
|Korrektur von Kardinalitäten bei "associatedPerson"-Element.
|03.08.2021
|1.2.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1071 ELGA-1071]
|Document Confidentiality Code [https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.1.12&effectiveDate=2021-02-19T10:35:04&language=de-DE 1.2.40.0.34.6.0.11.1.12]

Document Replacement - Related Document [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.14&effectiveDate=2021-06-28T13:42:15&language=de-DE 1.2.40.0.34.6.0.11.1.14]

In Fulfillment Of [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.9&effectiveDate=2021-06-28T13:42:25&language=de-DE 1.2.40.0.34.6.0.11.1.9]

Criticality Observation [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.3.35&effectiveDate=2021-06-28T13:44:02&language=de-DE 1.2.40.0.34.6.0.11.3.35]

Organization Name Compilation [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.27&effectiveDate=2021-06-28T14:00:14&language=de-DE 1.2.40.0.34.6.0.11.9.27]

Address Compilation Minimal [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.10&effectiveDate=2021-06-28T13:44:14&language=de-DE 1.2.40.0.34.6.0.11.9.10]

Device Compilation [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.18&effectiveDate=2021-06-28T13:57:36&language=de-DE 1.2.40.0.34.6.0.11.9.18]

Organization Compilation with id, name [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.5&effectiveDate=2021-06-28T13:57:53&language=de-DE 1.2.40.0.34.6.0.11.9.5]

Time Interval Information minimal [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.15&effectiveDate=2021-06-28T14:02:29&language=de-DE 1.2.40.0.34.6.0.11.9.15]

Organization Compilation with name, addr minimal [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.20&effectiveDate=2021-06-28T13:58:02&language=de-DE 1.2.40.0.34.6.0.11.9.20]
|Nur die in den Templates modellierten Elemente/Attribute sind künftig erlaubt.
|28.06.2021
|1.2.1
|-
|
|Brieftext [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.2.69&effectiveDate=2021-06-28T11:19:35&language=de-DE 1.2.40.0.34.6.0.11.2.69]

Übersetzung [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.2.8&effectiveDate=2021-06-28T11:28:05&language=de-DE 1.2.40.0.34.6.0.11.2.8]

Abschließende Bemerkung [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.2.70&effectiveDate=2021-06-28T11:25:03&language=de-DE 1.2.40.0.34.6.0.11.2.70]

Beilagen [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.2.71&effectiveDate=2021-06-28T11:22:40&language=de-DE 1.2.40.0.34.6.0.11.2.71]
|Korrektur von "Sektion" auf "Section".
|28.06.2021
|1.2.1
|-
|
|Logo Entry [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.3.53&effectiveDate=2021-06-28T11:08:49&language=de-DE 1.2.40.0.34.6.0.11.3.53]

Eingebettetes Objekt Entry [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.3.19&effectiveDate=2021-06-28T11:13:27&language=de-DE 1.2.40.0.34.6.0.11.3.19]
|Korrektur von "kodiert" auf "codiert".
|28.06.2021
|1.2.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1078 ELGA-1078]
|Assigned Entity [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.22&effectiveDate=2021-05-26T13:50:41&language=de-DE 1.2.40.0.34.6.0.11.9.22]
|Das Assert, das verlangte, dass das Attribut telecom/@use generell bei mehreren "telecom"-Elementen angegeben werden MUSS, wurde entfernt.
|26.05.2021
|1.2.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1134 ELGA-1134]
|Korrektur der "Übersichtstabelle der Header-Elemente für dokumenten-relevante Zeitpunkte/Zeitspannen"
|ELGA-Spalte: documentationOf statt 1..* R nun 0..* O, componentOf statt 0..1 R nun 0..1 O
e-Health-Spalte: hl7at:terminologyDate statt 1..1 M nun 0..1 O, documentationOf statt 1..* R nun 0..* O, componentOf statt 0..1 R nun 0..1 O
|04.05.2021
|1.2.1
|-
|[https://jira-neu.elga.gv.at/browse/CSD-1107 CSD-1107]
|DocumentLevelTemplate [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.0.5&effectiveDate=2021-02-08T13:01:55&language=de-DE 1.2.40.0.34.6.0.11.0.5] & Document PracticeSettingCode [https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.1.44&effectiveDate=2021-03-01T15:37:20&language=de-DE 1.2.40.0.34.6.0.11.1.44]
|Fehler in hl7at:practiceSettingCode und hl7at:formatCode mit fehlenden Elementen verhinderte die direkte Daten-Übernahme in XDS
|03.03.2021
|1.2.0
|-
|
|DLT Ambulanzbefund 1.2.40.0.34.6.0.11.0.5
|Von "ClinicalDocument/code" und "ClinicalDocument/code/translation" waren die Beschreibung bezüglich der Übernahme in die XDS-Metadaten sowie die Inhalte der Elemente vertauscht.
|03.03.2021
|1.2.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1041 ELGA-1041]
|Diagnose - kodiert [https://art-decor.org/art-decor/decor-templates--elgatgd-?section=templates&id=1.2.40.0.34.6.0.11.2.96&effectiveDate=2020-10-06T09:34:46&language=de-DE 1.2.40.0.34.6.0.11.2.96] & Diagnose - unkodiert [https://art-decor.org/art-decor/decor-templates--elgagab-?section=templates&id=1.2.40.0.34.6.0.11.2.83&effectiveDate=2021-02-23T06:25:26&language=de-DE 1.2.40.0.34.6.0.11.2.83]
|Im Template wurde die Beschreibung im Sinne des Ambulanzbefundes geändert, jedoch wurde nicht beachtet das dadurch auch die Beschreibung im TmE geändert wird, welcher dieselbe Sektion benutzt.
Die Beschreibung wurde in den zwei Sektionen wieder "generischer" umgeschrieben und die spezielle Beschreibung ("Informationen zu den diagnostischen Methoden oder Befunden, auf welchen die Diagnose beruht, können in der Sektion "Diagnostik und Befunde" angegeben werden und sind nicht Bestandteil dieser Sektion.") für den Ambulanzbefund wurde in der Anwendung der Sektion im DLT hinzugegeben.
|23.02.2021
|1.2.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1052 ELGA-1052]
|Bisherige Schwangerschaften Entry 1.2.40.0.34.6.0.11.3.46
|IPS-Anpassungen: neue TemplateId; code: Datentyp-Änderung (optional: originalText-reference, translation, ips:designation), ergänzt Narrative Text Reference, External Document Entry statt 0..1 R nun 0..* R; Template geschlossen
|08.02.2021
|1.2.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1051 ELGA-1051]
|Erwartetes Geburtsdatum Entry 1.2.40.0.34.6.0.11.3.45
|IPS-Anpassungen: neue TemplateId; code: Datentyp-Änderung (optional: originalText-reference, translation, ips:designation), ergänzt Narrative Text Reference, External Document Entry statt 0..1 R nun 0..* R; Template geschlossen
|08.02.2021
|1.2.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1050 ELGA-1050]
|Aktuelle Schwangerschaft Entry 1.2.40.0.34.6.0.11.3.44
|IPS-Anpassungen: neue TemplateId; neuer code (neuer Datentyp, optional: originalText-reference, translation, ips:designation), ergänzt Narrative Text Reference, value (neues Value Set 1.2.40.0.34.6.0.10.52 elgagab_PregnancyStatus_VS); author, informant statt 1..R nun 0.. R; External Document Entry statt 0..1 R nun 0..* R; Template geschlossen
|08.02.2021
|1.2.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1049 ELGA-1049]
|Schwangerschaften 1.2.40.0.34.6.0.11.2.48
|IPS-Anpassungen (neue TemplateId, Template geschlossen)
|08.02.2021
|1.2.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-985 ELGA-985]
|DLT 1.2.40.0.34.6.0.11.0.5
|bei components fehlen typeCodes und contextConductionInd
|17.11.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-991 ELGA-991]
|Zusätzliche Medikation - kodiert 1.2.40.0.34.6.0.11.2.90
|entry.contextConductionInd Änderung von 1..1 F auf 0..1 F
|09.11.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-998 ELGA-998]
|Allergy or Intolerance 1.2.40.0.34.6.0.11.3.33
|observation.negationInd: Datentyp bl statt cs
|09.11.2020
|2020.1
|-
|
|Konsultationsgurnd Problem Entry 1.2.40.0.34.6.0.11.3.31
|ANPASSUNG AN ALLGEMEINES Problem Entry: observation/id von 0..1 auf 1..*, Erweiterung VS von observation/code, Anpassung von observation/effectiveTime, qualifier für Diagnoseart in observation/value hinzugefügt, targetSiteCode hinzugefügt, es sind nun performer/author/informant/participant erlaubt, comment hinzugefügt
|05.11.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-995 ELGA-995]
|Frühere Erkrankungen ICD-10 und Maßnahmen - kodiert 1.2.40.0.34.6.0.11.2.74
|Korrektur Beispiel
|05.11.2020
|2020.1
|-
|
|Konsultationsgrund Entry (alt), Konsultationsgrund Problem Concern Entry (neu) 1.2.40.0.34.6.0.11.3.30
|ANPASSUNG AN ALLGEMEINES Problem Concern Entry: Name des templates angepasst; neuer Name "Konsultationsgrund Problem Concern Entry", act/id von 0..1 [O] auf 1..1 [M], act/code fix auf nullFlavor "NA", Anpassung von act/effectiveTime (high-Element ist nicht mehr erlaubt), act/entryRelationship von 1..* auf 1..1, act/performer und act/participant nun erlaubt
|05.11.2020
|2020.1
|-
|
|Konsultations- oder Überweisungsgrund - kodiert 1.2.40.0.34.6.0.11.2.47
|Anpassung von section/code (displayName und codeSystemName von 1..1 auf 0..1), translation und ips:designation dem section/code hinzugefügt, Konformanz für section/entry (Konsultationsgrund Problem Concern Entry) von 1..1 auf 1..* geändert
|04.11.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-992 ELGA-992]
|Lebensstil - kodiert 1.2.40.0.34.6.0.11.2.55
|templateId[2].root: 1..1 F statt 0..1 F
|23.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-988 ELGA-988]
|DLT Ambulanzbefund 1.2.40.0.34.6.0.11.0.5
|doppelte Elemente entfernt: ConfidentialityCode + languageCode
|22.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-990 ELGA-990]
|Änderung bestehender Medikation - kodiert 1.2.40.0.34.6.0.11.2.89
|typeCode und contextConductionInd ergänzt
|22.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-978 ELGA-978]
|Lebensstil Alkoholkonsum Nominal Entry 1.2.40.0.34.6.0.11.3.43
|Fehler im Bsp-Snippet: führendes Leerzeichen bei value.codesystem entfernt
|12.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-977 ELGA-977]
|DLT 1.2.40.0.34.6.0.11.0.5
|Anamnese-Beschreibung enthielt noch Subsektion "Willenserklärungen", ist aber eine eigene Sektion
|9.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-975 ELGA-975]
|1.2.40.0.34.6.0.11.3.41 Lebensstil Tabakkonsum Nominal Entry,
1.2.40.0.34.6.0.11.3.40 Lebensstil Tabakkonsum Quantitativ Entry
|Element: effectiveTme korrigiert durch effectiveTime, Bsp-Snippet
|8.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-968 ELGA-968]
|Willenserklärungen und andere juridische Dokumente 1.2.40.0.34.6.0.11.2.61
|fehlende Kardinalitäten bei 1.2.40.0.34.6.0.11.2.62 Willenserklärungen und andere juridische Dokumente - Subsektion und 1.2.40.0.34.6.0.11.2.8 Übersetzung mit 0..* ergänzt
|7.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/CSD-806 CSD-806]
|[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.2.96 Diagnose - kodiert] 1.2.40.0.34.6.0.11.2.96
|Änderung Problem Concern Entry von [1..1] M auf [1..*] M

Problem Entry 1.2.40.0.34.6.0.11.3.6
|6.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-959 ELGA-959]
|Problem Entry 1.2.40.0.34.6.0.11.3.6
|text/text/reference statt text/reference modelliert
|6.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/CSD-806 CSD-806]
|Diagnose Ambulanzbefund - unkodiert 1.2.40.0.34.6.0.11.2.83
|Umbenannt auf Diagnose - unkodiert bzw. atcdabbr_section_DiagnoseUnkodiert.
|6.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-955 ELGA-955]
|Organization Compilation: representedOrganization/telecom
[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.9.5&effectiveDate=2019-03-25T13:43:57&language=de-DE 1.2.40.0.34.6.0.11.9.5]
[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.9.7&effectiveDate=2019-02-12T15:42:02&language=de-DE 1.2.40.0.34.6.0.11.9.7]
[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.9.9&effectiveDate=2019-02-13T10:30:51&language=de-DE 1.2.40.0.34.6.0.11.9.9]
[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.9.20&effectiveDate=2019-04-18T11:28:59&language=de-DE 1.2.40.0.34.6.0.11.9.20]
[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.1.2&effectiveDate=2019-02-13T09:50:17&language=de-DE 1.2.40.0.34.6.0.11.1.2]
|Das Schematron Assert in allen „Organization Compilation“ Templates und dem "Author" Template ist strenger als sein narrativer Constraint ihn beschreibt. Deswegen wurden das Assert dort jeweils entfernt.
|22.9.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-954 ELGA-954]
|Fachspezifische Anamnese [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.2.98&effectiveDate=2020-09-25T10:33:00&language=de-DE 1.2.40.0.34.6.0.11.2.98]
|Section Fachspezifische Anamnese ergänzt.
|25.9.2020
|2020.1
|}

Bearbeiten von „Testseite“ (Abschnitt)
Zur Navigation springen
Zur Suche springen
Erweitert
Sonderzeichen
Hilfe
=Ausblick=

{| class="wikitable sortable"
|+
!Ticket
!Template / Element
!Beschreibung
!Datum
!Änderungslevel
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1221 ELGA-1221]
|Aktuelle Schwangerschaft Entry 1.2.40.0.34.6.0.11.3.44
|Korrektur Beispielsnippet: observation/value xsi:type="CE" wurde ergänzt
|14.03.2022
|Patch
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1243 ELGA-1243]
|Vaccine Product
1.2.40.0.34.6.0.11.9.32
|Klarstellung zur Verwendung des Handels- und Zulassungsnamens
|14.07.2022
|Patch
|}

=Bekannte Probleme=
keine

=Diskussion=
''Zu diesen Punkten besteht noch Diskussionsbedarf.''

Diskussionsbeiträge bitte an [mailto:office@hl7.at office@hl7.at] senden.

Derzeit keine

ILF Diskussion:Ambulanzbefund (Version 1)

2022-07-15T12:07:00Z

Kuttin: /* Ausblick */

=Release-Log=
Korrekturen den Header betreffend, befinden sich auf der Diskussionsseite des [[ILF_Diskussion:Allgemeiner_Implementierungsleitfaden_2020|Allgemeinen Implementierungsleitfadens]].

{| class="wikitable sortable"
|+
!Ticket
!Template / Element
!Beschreibung
!Datum
!Änderungslevel
|-
|CSD-2083
|DLT Ambulanzbefund 1.2.40.0.34.6.0.11.0.5
|Neue Patchversion aufgrund von Anpassungen von Problem Entry
|03.06.2022
|1.3.1
|-
|CSD-2083
|Problem Entry 1.2.40.0.34.6.0.11.3.6
|Fehlerkorrektur: observation/effectiveTime/low geändert von 1..1 M zu 1..1 R, da der Nullflavor "UNK" zugelassen ist
|03.06.2022
|1.3.1
|-
|
|Konsultationsgrund Problem Entry 1.2.40.0.34.6.0.11.3.31
|Fehlerkorrektur: observation/effectiveTime/low geändert von 1..1 M zu 1..1 R, da der Nullflavor "UNK" zugelassen ist
|03.06.2022
|1.3.1
|-
|
|DLT Ambulanzbefund 1.2.40.0.34.6.0.11.0.5
|Neue Nebenversion aufgrund von Anpassungen des Implementierungsleitfadens e-Impfpass
|09.02.2022
|1.3.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1199 CSD-1199]
|DocumentLevelTemplate [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.0.5&effectiveDate=2021-10-27T13:18:25&language=de-DE 1.2.40.0.34.6.0.11.0.5]
|Anpassung ELGA-Dokumentenklasse: Diese ist nicht mehr aus dem Value Set ELGA_Dokumentenklasse_Ambulanzbefund zu entnehmen, sondern aus dem Unterknoten 75476-2 "Physician note" des Value Sets "ELGA_Dokumentenklassen"
|27.10.2021
|1.3.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1170 ELGA-1170]
|Konsultationsgrund Problem Entry [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.3.31&effectiveDate=2021-08-10T08:43:36&language=de-DE 1.2.40.0.34.6.0.11.3.31]
|Beschreibung von observation/code wurde korrigiert. Als "vocabulary" wird jetzt das neu benannte Value Set ELGA_TypeOfProblem_VS verlangt.
|10.08.2021
|1.2.1
|-
|
|Participant Fachlicher Ansprechpartner [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.20&effectiveDate=2021-08-03T11:02:47&language=de-DE 1.2.40.0.34.6.0.11.1.20]

Participant Auskunftsberechtigte Person (Notfallkontakt) [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.27&effectiveDate=2021-08-03T11:25:19&language=de-DE 1.2.40.0.34.6.0.11.1.27]
|Korrektur von "Telefon-Nummer" auf "Telefonnummer".
|03.08.2021
|1.2.1
|-
|
|Participant Hausarzt [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.23&effectiveDate=2021-08-03T11:32:38&language=de-DE 1.2.40.0.34.6.0.11.1.23]

Participant Auskunftsberechtigte Person (Notfallkontakt) [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.27&effectiveDate=2021-08-03T11:25:19&language=de-DE 1.2.40.0.34.6.0.11.1.27]

Participant Angehoerige [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.25&effectiveDate=2021-08-03T11:17:27&language=de-DE 1.2.40.0.34.6.0.11.1.25]
|Korrektur von Kardinalitäten bei "associatedPerson"-Element.
|03.08.2021
|1.2.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1071 ELGA-1071]
|Document Confidentiality Code [https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.1.12&effectiveDate=2021-02-19T10:35:04&language=de-DE 1.2.40.0.34.6.0.11.1.12]

Document Replacement - Related Document [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.14&effectiveDate=2021-06-28T13:42:15&language=de-DE 1.2.40.0.34.6.0.11.1.14]

In Fulfillment Of [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.1.9&effectiveDate=2021-06-28T13:42:25&language=de-DE 1.2.40.0.34.6.0.11.1.9]

Criticality Observation [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.3.35&effectiveDate=2021-06-28T13:44:02&language=de-DE 1.2.40.0.34.6.0.11.3.35]

Organization Name Compilation [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.27&effectiveDate=2021-06-28T14:00:14&language=de-DE 1.2.40.0.34.6.0.11.9.27]

Address Compilation Minimal [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.10&effectiveDate=2021-06-28T13:44:14&language=de-DE 1.2.40.0.34.6.0.11.9.10]

Device Compilation [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.18&effectiveDate=2021-06-28T13:57:36&language=de-DE 1.2.40.0.34.6.0.11.9.18]

Organization Compilation with id, name [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.5&effectiveDate=2021-06-28T13:57:53&language=de-DE 1.2.40.0.34.6.0.11.9.5]

Time Interval Information minimal [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.15&effectiveDate=2021-06-28T14:02:29&language=de-DE 1.2.40.0.34.6.0.11.9.15]

Organization Compilation with name, addr minimal [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.20&effectiveDate=2021-06-28T13:58:02&language=de-DE 1.2.40.0.34.6.0.11.9.20]
|Nur die in den Templates modellierten Elemente/Attribute sind künftig erlaubt.
|28.06.2021
|1.2.1
|-
|
|Brieftext [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.2.69&effectiveDate=2021-06-28T11:19:35&language=de-DE 1.2.40.0.34.6.0.11.2.69]

Übersetzung [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.2.8&effectiveDate=2021-06-28T11:28:05&language=de-DE 1.2.40.0.34.6.0.11.2.8]

Abschließende Bemerkung [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.2.70&effectiveDate=2021-06-28T11:25:03&language=de-DE 1.2.40.0.34.6.0.11.2.70]

Beilagen [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.2.71&effectiveDate=2021-06-28T11:22:40&language=de-DE 1.2.40.0.34.6.0.11.2.71]
|Korrektur von "Sektion" auf "Section".
|28.06.2021
|1.2.1
|-
|
|Logo Entry [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.3.53&effectiveDate=2021-06-28T11:08:49&language=de-DE 1.2.40.0.34.6.0.11.3.53]

Eingebettetes Objekt Entry [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.3.19&effectiveDate=2021-06-28T11:13:27&language=de-DE 1.2.40.0.34.6.0.11.3.19]
|Korrektur von "kodiert" auf "codiert".
|28.06.2021
|1.2.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1078 ELGA-1078]
|Assigned Entity [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.9.22&effectiveDate=2021-05-26T13:50:41&language=de-DE 1.2.40.0.34.6.0.11.9.22]
|Das Assert, das verlangte, dass das Attribut telecom/@use generell bei mehreren "telecom"-Elementen angegeben werden MUSS, wurde entfernt.
|26.05.2021
|1.2.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1134 ELGA-1134]
|Korrektur der "Übersichtstabelle der Header-Elemente für dokumenten-relevante Zeitpunkte/Zeitspannen"
|ELGA-Spalte: documentationOf statt 1..* R nun 0..* O, componentOf statt 0..1 R nun 0..1 O
e-Health-Spalte: hl7at:terminologyDate statt 1..1 M nun 0..1 O, documentationOf statt 1..* R nun 0..* O, componentOf statt 0..1 R nun 0..1 O
|04.05.2021
|1.2.1
|-
|[https://jira-neu.elga.gv.at/browse/CSD-1107 CSD-1107]
|DocumentLevelTemplate [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.0.5&effectiveDate=2021-02-08T13:01:55&language=de-DE 1.2.40.0.34.6.0.11.0.5] & Document PracticeSettingCode [https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.1.44&effectiveDate=2021-03-01T15:37:20&language=de-DE 1.2.40.0.34.6.0.11.1.44]
|Fehler in hl7at:practiceSettingCode und hl7at:formatCode mit fehlenden Elementen verhinderte die direkte Daten-Übernahme in XDS
|03.03.2021
|1.2.0
|-
|
|DLT Ambulanzbefund 1.2.40.0.34.6.0.11.0.5
|Von "ClinicalDocument/code" und "ClinicalDocument/code/translation" waren die Beschreibung bezüglich der Übernahme in die XDS-Metadaten sowie die Inhalte der Elemente vertauscht.
|03.03.2021
|1.2.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1041 ELGA-1041]
|Diagnose - kodiert [https://art-decor.org/art-decor/decor-templates--elgatgd-?section=templates&id=1.2.40.0.34.6.0.11.2.96&effectiveDate=2020-10-06T09:34:46&language=de-DE 1.2.40.0.34.6.0.11.2.96] & Diagnose - unkodiert [https://art-decor.org/art-decor/decor-templates--elgagab-?section=templates&id=1.2.40.0.34.6.0.11.2.83&effectiveDate=2021-02-23T06:25:26&language=de-DE 1.2.40.0.34.6.0.11.2.83]
|Im Template wurde die Beschreibung im Sinne des Ambulanzbefundes geändert, jedoch wurde nicht beachtet das dadurch auch die Beschreibung im TmE geändert wird, welcher dieselbe Sektion benutzt.
Die Beschreibung wurde in den zwei Sektionen wieder "generischer" umgeschrieben und die spezielle Beschreibung ("Informationen zu den diagnostischen Methoden oder Befunden, auf welchen die Diagnose beruht, können in der Sektion "Diagnostik und Befunde" angegeben werden und sind nicht Bestandteil dieser Sektion.") für den Ambulanzbefund wurde in der Anwendung der Sektion im DLT hinzugegeben.
|23.02.2021
|1.2.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1052 ELGA-1052]
|Bisherige Schwangerschaften Entry 1.2.40.0.34.6.0.11.3.46
|IPS-Anpassungen: neue TemplateId; code: Datentyp-Änderung (optional: originalText-reference, translation, ips:designation), ergänzt Narrative Text Reference, External Document Entry statt 0..1 R nun 0..* R; Template geschlossen
|08.02.2021
|1.2.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1051 ELGA-1051]
|Erwartetes Geburtsdatum Entry 1.2.40.0.34.6.0.11.3.45
|IPS-Anpassungen: neue TemplateId; code: Datentyp-Änderung (optional: originalText-reference, translation, ips:designation), ergänzt Narrative Text Reference, External Document Entry statt 0..1 R nun 0..* R; Template geschlossen
|08.02.2021
|1.2.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1050 ELGA-1050]
|Aktuelle Schwangerschaft Entry 1.2.40.0.34.6.0.11.3.44
|IPS-Anpassungen: neue TemplateId; neuer code (neuer Datentyp, optional: originalText-reference, translation, ips:designation), ergänzt Narrative Text Reference, value (neues Value Set 1.2.40.0.34.6.0.10.52 elgagab_PregnancyStatus_VS); author, informant statt 1..R nun 0.. R; External Document Entry statt 0..1 R nun 0..* R; Template geschlossen
|08.02.2021
|1.2.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1049 ELGA-1049]
|Schwangerschaften 1.2.40.0.34.6.0.11.2.48
|IPS-Anpassungen (neue TemplateId, Template geschlossen)
|08.02.2021
|1.2.0
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-985 ELGA-985]
|DLT 1.2.40.0.34.6.0.11.0.5
|bei components fehlen typeCodes und contextConductionInd
|17.11.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-991 ELGA-991]
|Zusätzliche Medikation - kodiert 1.2.40.0.34.6.0.11.2.90
|entry.contextConductionInd Änderung von 1..1 F auf 0..1 F
|09.11.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-998 ELGA-998]
|Allergy or Intolerance 1.2.40.0.34.6.0.11.3.33
|observation.negationInd: Datentyp bl statt cs
|09.11.2020
|2020.1
|-
|
|Konsultationsgurnd Problem Entry 1.2.40.0.34.6.0.11.3.31
|ANPASSUNG AN ALLGEMEINES Problem Entry: observation/id von 0..1 auf 1..*, Erweiterung VS von observation/code, Anpassung von observation/effectiveTime, qualifier für Diagnoseart in observation/value hinzugefügt, targetSiteCode hinzugefügt, es sind nun performer/author/informant/participant erlaubt, comment hinzugefügt
|05.11.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-995 ELGA-995]
|Frühere Erkrankungen ICD-10 und Maßnahmen - kodiert 1.2.40.0.34.6.0.11.2.74
|Korrektur Beispiel
|05.11.2020
|2020.1
|-
|
|Konsultationsgrund Entry (alt), Konsultationsgrund Problem Concern Entry (neu) 1.2.40.0.34.6.0.11.3.30
|ANPASSUNG AN ALLGEMEINES Problem Concern Entry: Name des templates angepasst; neuer Name "Konsultationsgrund Problem Concern Entry", act/id von 0..1 [O] auf 1..1 [M], act/code fix auf nullFlavor "NA", Anpassung von act/effectiveTime (high-Element ist nicht mehr erlaubt), act/entryRelationship von 1..* auf 1..1, act/performer und act/participant nun erlaubt
|05.11.2020
|2020.1
|-
|
|Konsultations- oder Überweisungsgrund - kodiert 1.2.40.0.34.6.0.11.2.47
|Anpassung von section/code (displayName und codeSystemName von 1..1 auf 0..1), translation und ips:designation dem section/code hinzugefügt, Konformanz für section/entry (Konsultationsgrund Problem Concern Entry) von 1..1 auf 1..* geändert
|04.11.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-992 ELGA-992]
|Lebensstil - kodiert 1.2.40.0.34.6.0.11.2.55
|templateId[2].root: 1..1 F statt 0..1 F
|23.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-988 ELGA-988]
|DLT Ambulanzbefund 1.2.40.0.34.6.0.11.0.5
|doppelte Elemente entfernt: ConfidentialityCode + languageCode
|22.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-990 ELGA-990]
|Änderung bestehender Medikation - kodiert 1.2.40.0.34.6.0.11.2.89
|typeCode und contextConductionInd ergänzt
|22.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-978 ELGA-978]
|Lebensstil Alkoholkonsum Nominal Entry 1.2.40.0.34.6.0.11.3.43
|Fehler im Bsp-Snippet: führendes Leerzeichen bei value.codesystem entfernt
|12.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-977 ELGA-977]
|DLT 1.2.40.0.34.6.0.11.0.5
|Anamnese-Beschreibung enthielt noch Subsektion "Willenserklärungen", ist aber eine eigene Sektion
|9.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-975 ELGA-975]
|1.2.40.0.34.6.0.11.3.41 Lebensstil Tabakkonsum Nominal Entry,
1.2.40.0.34.6.0.11.3.40 Lebensstil Tabakkonsum Quantitativ Entry
|Element: effectiveTme korrigiert durch effectiveTime, Bsp-Snippet
|8.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-968 ELGA-968]
|Willenserklärungen und andere juridische Dokumente 1.2.40.0.34.6.0.11.2.61
|fehlende Kardinalitäten bei 1.2.40.0.34.6.0.11.2.62 Willenserklärungen und andere juridische Dokumente - Subsektion und 1.2.40.0.34.6.0.11.2.8 Übersetzung mit 0..* ergänzt
|7.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/CSD-806 CSD-806]
|[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.2.96 Diagnose - kodiert] 1.2.40.0.34.6.0.11.2.96
|Änderung Problem Concern Entry von [1..1] M auf [1..*] M

Problem Entry 1.2.40.0.34.6.0.11.3.6
|6.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-959 ELGA-959]
|Problem Entry 1.2.40.0.34.6.0.11.3.6
|text/text/reference statt text/reference modelliert
|6.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/CSD-806 CSD-806]
|Diagnose Ambulanzbefund - unkodiert 1.2.40.0.34.6.0.11.2.83
|Umbenannt auf Diagnose - unkodiert bzw. atcdabbr_section_DiagnoseUnkodiert.
|6.10.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-955 ELGA-955]
|Organization Compilation: representedOrganization/telecom
[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.9.5&effectiveDate=2019-03-25T13:43:57&language=de-DE 1.2.40.0.34.6.0.11.9.5]
[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.9.7&effectiveDate=2019-02-12T15:42:02&language=de-DE 1.2.40.0.34.6.0.11.9.7]
[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.9.9&effectiveDate=2019-02-13T10:30:51&language=de-DE 1.2.40.0.34.6.0.11.9.9]
[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.9.20&effectiveDate=2019-04-18T11:28:59&language=de-DE 1.2.40.0.34.6.0.11.9.20]
[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates&id=1.2.40.0.34.6.0.11.1.2&effectiveDate=2019-02-13T09:50:17&language=de-DE 1.2.40.0.34.6.0.11.1.2]
|Das Schematron Assert in allen „Organization Compilation“ Templates und dem "Author" Template ist strenger als sein narrativer Constraint ihn beschreibt. Deswegen wurden das Assert dort jeweils entfernt.
|22.9.2020
|2020.1
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-954 ELGA-954]
|Fachspezifische Anamnese [https://art-decor.org/art-decor/decor-templates--elgaambbef-?section=templates&id=1.2.40.0.34.6.0.11.2.98&effectiveDate=2020-09-25T10:33:00&language=de-DE 1.2.40.0.34.6.0.11.2.98]
|Section Fachspezifische Anamnese ergänzt.
|25.9.2020
|2020.1
|}

Bearbeiten von „Testseite“ (Abschnitt)
Zur Navigation springen
Zur Suche springen
Erweitert
Sonderzeichen
Hilfe
=Ausblick=

{| class="wikitable sortable"
|+
!Ticket
!Template / Element
!Beschreibung
!Datum
!Änderungslevel
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1221 ELGA-1221]
|Aktuelle Schwangerschaft Entry 1.2.40.0.34.6.0.11.3.44
|Korrektur Beispielsnippet: observation/value xsi:type="CE" wurde ergänzt
|14.03.2022
|Patch
|-
|[https://jira-neu.elga.gv.at/browse/ELGA-1243 ELGA-1243]
|Vaccine Product
1.2.40.0.34.6.0.11.9.32
|Klarstellung zur Verwendung des Handels- und Zulassungsnamens
|14.07.2022
|Patch
|}
Zusammenfassung:
Nur Kleinigkeiten wurden verändert
Diese Seite beobachten

Bitte beachte, dass alle Beiträge zu ELGA Test-Wiki von anderen Mitwirkenden bearbeitet, geändert oder gelöscht werden können. Reiche hier keine Texte ein, falls du nicht willst, dass diese ohne Einschränkung geändert werden können.

Du bestätigst hiermit auch, dass du diese Texte selbst geschrieben hast oder diese von einer gemeinfreien Quelle kopiert hast (weitere Einzelheiten unter ELGA Test-Wiki:Urheberrechte). ÜBERTRAGE OHNE GENEHMIGUNG KEINE URHEBERRECHTLICH GESCHÜTZTEN INHALTE!
Navigationsmenü

Kuttin
Diskussion
Einstellungen
Beobachtungsliste
Beiträge
Abmelden

Seite
Diskussion

Lesen
Bearbeiten
Versionsgeschichte
Nicht mehr beobachten

Mehr

Suche

Hauptseite
Letzte Änderungen
Zufällige Seite
Hilfe zu MediaWiki

Werkzeuge

Links auf diese Seite
Änderungen an verlinkten Seiten
Spezialseiten
Seiteninformationen

Datenschutz
Über ELGA Test-Wiki
Haftungsausschluss

Powered by MediaWiki

=Bekannte Probleme=
keine

=Diskussion=
''Zu diesen Punkten besteht noch Diskussionsbedarf.''

Diskussionsbeiträge bitte an [mailto:office@hl7.at office@hl7.at] senden.

Derzeit keine

ILF:E-Impfpass

2022-07-12T07:28:27Z

Kuttin: /* Revisionsliste */

{{#seo:
|title=e-Impfpass
|titlemode=append
|keywords= e-Impfpass
|description=Der e-Impfpass definiert einen technischen und semantischen Standard für den elektronischen und strukturierten Austausch von Impfungen und Daten zur Immunisierungsstatus einer Person.
}}
{{#customtitle:e-Impfpass}}



{{#css:
@media Screen{
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.toc{
width: 20%;
float: right !important;
margin: 10px 0px 10px 30px !important;
border: 1px solid #AAA;
background-color: #F9F9F9;
display: table;
padding: 7px !important;
}
}
}}



{{Infobox Dokument
|Group = CDA Implementierungsleitfaden
|Title = HL7 Implementation Guide for CDA® R2: e-Impfpass (Version 1)
|Subtitle = Zur Anwendung im österreichischen Gesundheitswesen [1.2.40.0.34.7.19.1]
|Short = e-Impfpass
|Namespace = ILF
|Type = Implementierungsleitfaden
|Version = 1.3.0+20220127
|Submitted = ELGA GmbH
|Date = 2022-01-27
|Copyright = © HL7 Austria 2018-2022
|Status = Finale Version (normative Nebenversion)
|Verfahren = Normativ
|Period = Produktiveinsatz
|OID = 1.2.40.0.34.7.19.1
|Realm = Österreich
}}
{{TOC limit|5}}


=Zusammenfassung=
{{BeginYellowBox}}
Dieser Leitfaden beschreibt die Datenaustauschformate für den [https://www.elga.gv.at/e-impfpass/e-impfpass/index.html e-Impfpass] in Österreich.

Die Grundlage der Datenaustauschformate ist der internationale [[CDA-Grundlagen|CDA-Standard]], der sich in ELGA bereits bewährt hat. Er erlaubt es Sender und Empfänger, sich ohne vorherige Absprache zu verstehen. Als Basisspezifikation wurde das "Immunization Content (IC)" Inhaltsprofil aus dem IHE Technical Framework "Patient Care Coordination (PCC)" ausgewählt, das auch im Schweizerischen [http://e-health-wiki.ch/index.php/CDA-CH-VACD_(project) eImpfdossier] <ref name=ImpfdossierCH>Elektronisches Impf- und Immunschutzdossier der Schweiz [Online 2019]. http://e-health-wiki.ch/index.php/Ehscda:CDA-CH-VACD_(specification)</ref> verwendet wird.

Als Datenaustauschformate dienen zwei unterschiedliche CDA-Dokument-Templates:

* '''[[ILF:E-Impfpass#.C3.9Cbersicht_CDA_Struktur_.22Kompletter_Immunisierungsstatus.22|Kompletter Immunisierungsstatus]]''': Das von der zentralen Anwendung abrufbare Datenaustauschformat. Es enthält alle verfügbaren Informationen zum Immunisierungsstatus einer Person (Impfungen, impfrelevante Erkrankungen, Antikörper-Bestimmungen) und Impfempfehlungen.
* '''[[ILF:E-Impfpass#.C3.9Cbersicht_CDA_Struktur_.22Update_Immunisierungsstatus.22|Update Immunisierungsstatus]]''': Das Datenaustauschformat, das an die zentrale Anwendung gesendet wird, um Änderungen am Immunisierungsstatus einer Person zu dokumentieren (Impfungen, impfrelevante Erkrankungen, Antikörper-Bestimmungen) sowie individuell angepasste Impfempfehlungen, die durch den impfenden Arzt festgelegt werden.

Die Notation der Spezifikation der Datenaustauschformate folgt der "Art-Decor"-Schreibweise, die auf einer eigenen Seite ([[Hilfe:Art-Decor-Tabellen_verstehen|Art-Decor-Tabellen verstehen]]) erläutert wird.

Der vorgesehene Ablauf des Datenaustausches wird im Kapitel [[ILF:E-Impfpass#Anwendungsf.C3.A4lle|Anwendungsfälle]] beschrieben.
{{EndYellowBox}}

{{BeginYellowBox}}
Die gesetzliche Grundlage für den e-Impfpass ist das Gesundheitstelematikgesetz (GTelG 5. Abschnitt: eHealth-Anwendungen, 2. Unterabschnitt: § 24b bis § 24g) und die zugehörige eHealth-Verordnung (eHealthV 2020). 
Dieser Leitfaden ist ein nationaler HL7©-Standard, der technisch und inhaltlich im Rahmen des Abstimmungsverfahrens 2019-1 ("Ballot") normiert wurde.
Kommentare zu diesem Leitfaden können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden.
{{EndYellowBox}}
<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">


==Impressum==
<div class="mw-collapsible-content">
''Medieneigentümer, Herausgeber, Hersteller, Verleger:'' 
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: 01. 2127050. 
Internet: [http://www.elga.gv.at www.elga.gv.at]
Email: [mailto:cda@elga.gv.at cda@elga.gv.at]. 
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch

''Redaktion, Projektleitung, Koordination: '' 
Mag. Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]

''Abbildungen:'' © ELGA GmbH

''Nutzung'': Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria, Franckstrasse 41/5/14, 8010 Graz; [http://www.hl7.at www.hl7.at]. 
Die Nutzung ist zum Zweck der Erstellung medizinischer Dokumente ohne Lizenz- und Nutzungsgebühren ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter [https://www.gesundheit.gv.at www.gesundheit.gv.at] und [https://www.elga.gv.at/cda www.elga.gv.at/cda]
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">
== Haftungsausschluss ==
<div class="mw-collapsible-content">
Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht. Die ELGA GmbH weist ausdrücklich darauf hin, dass es sich bei dem vorliegenden Leitfaden um unverbindliche Arbeitsergebnisse handelt, die zur Anwendung empfohlen werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls unerwünscht und von den Erstellern des Dokumentes nicht beabsichtigt.

Die Nutzung des vorliegenden Leitfadens erfolgt in ausschließlicher Verantwortung der Anwender. Aus der Verwendung des vorliegenden Leitfadens können keinerlei Rechtsansprüche gegen die ELGA GmbH erhoben und/oder abgeleitet werden.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">
== Sprachliche Gleichbehandlung ==
<div class="mw-collapsible-content">
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer und Frauen in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
</div></div>

{{ILF:Lizenzinformationen}}

<div class="toccolours mw-collapsible mw-collapsed" style="width:50%; overflow:auto;">
==PDF-Bedienungshinweise==
<div class="mw-collapsible-content">
Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

* Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
* Seitenweise blättern: "Bild" Tasten
* Scrollen: Pfeil nach oben bzw. unten
* Zoomen: Strg + Mouserad drehen
* Suchen im Dokument: Strg + F
</div></div>



=Einleitung=
==Ausgangslage und Motivation==
Im österreichischen Impfwesen wird der papierbasierte Impfpass als zentrales Instrument für die Dokumentation und den Nachweis von Impfungen verwendet. Obwohl sich der papierbasierte Impfpass über viele Jahre bewährt hat, so erfüllt er nicht mehr die Anforderungen an ein modernes Gesundheitsvorsorgeinstrument. Der Papierimpfpass geht oft verloren, die teilweise handschriftlichen Aufzeichnungen sind schwierig zu entziffern und nicht vollständig bzw. über mehrere Impfpässe verteilt. Hier soll der e-Impfpass ansetzen und valide und übersichtliche Daten schaffen. Zudem sollen auf Basis des nationalen Impfplans persönliche Impfempfehlungen ausgegeben werden.
Auf Beschluss der Bundeszielsteuerungskommission wurde daher die Umsetzung der Pilotierung des elektronischen Impfpasses (e-Impfpass) durch die ELGA GmbH beschlossen.
Mit dem Ziel einer optimierten Impfversorgung der österreichischen Bevölkerung ist der Impfausweis der Zukunft ein elektronisches Dokument (e-Impfpass). Um den Austausch dieser Informationen zwischen allen beteiligten Institutionen und Personen zu unterstützen, muss ein einheitliches Austauschformat geschaffen und definiert werden, welches in diesem Dokument beschrieben wird.

==Zweck des Dokuments==
Das vorliegende Dokument beschreibt die einheitlichen Austauschformate und Inhalte für den Informationsaustausch für den "e-Impfpass" für das Österreichische Gesundheitswesen. Diese Spezifikation ist das Resultat einer Harmonisierungsarbeit mit dem Ziel, Impfeinträge innerhalb der österreichischen "Elektronischen Gesundheitsakte" (ELGA) als abgestimmte und einheitlich strukturierte Dokumente darzustellen. Der vorliegende Implementierungsleitfaden beinhaltet daher Spezifikationen für die semantische Interoperabilität von Systemen rund um den e-Impfpass inkl. der elektronische Anfragen von Impfempfehlungen.
Die Grundlage der Datenaustauschformate ist der internationale CDA-Standard, der sich in ELGA bereits bewährt hat. Als Basisspezifikation wurde das "Immunization Content (IC)" Inhaltsprofil aus dem IHE Technical Framework "Patient Care Coordination (PCC)" ausgewählt, das auch im Schweizerischen eImpfdossier verwendet wird. Das vorliegende Dokument wurde von einer Arbeitsgruppe von Vertretern des Gesundheitswesens, der Wissenschaft und der Wirtschaft sowie von der Health Level 7 (HL7) Anwendergruppe Österreich erstellt. Der Leitfaden basiert auf den vorangegangenen Erfahrungen in der Erstellung von Implementierungsleitfäden für ELGA CDA Dokumente. Die Header enthalten zum einen administrative Daten (allgemeine Angaben zum Dokument, Daten zum Patienten, usw.) und dienen zum anderen auch als Quelle für die Metadaten, die bei der Registrierung des Dokuments in ELGA verwendet werden. Der Header orientiert sich am bestehenden "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente", enthält aber Verallgemeinerungen, da es sich um ein e-Health-Dokument und nicht um ein ELGA-Dokument handelt. Die medizinisch relevanten Anteile zur Erfassung des Immunisierungsstatus sind im so genannten "Body" enthalten.

==Zielgruppe==
Anwender dieses Dokuments sind Softwareentwickler und Berater, die allgemein mit Implementierungen und Integrationen im e-Health-Umfeld, insbesondere des Projekts e-Impfpass, aber auch mit ELGA e-Befunden oder e-Medikation betraut sind. Weiters richtet sich
der Leitfaden an alle an der Erstellung von Gesundheitsdaten und Gesundheitsdokumenten beteiligten Personen, einschließlich der Endbenutzer der medizinischen Softwaresysteme und der Angehörigen von Gesundheitsberufen.

=Informationen über dieses Dokument=
==Verbindlichkeit==
Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten für den Elektronischen Impfpass gem. Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 (GTelG 2012) sowie den darauf fußenden Novellen und Verordnungen. Die im Implementierungsleitfaden getroffenen Festlegungen für Inhalt, Struktur, Format und Codierung sind somit verbindlich.

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

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

== Verwendete Grundlagen und Bezug zu anderen Standards ==

{|
|style="vertical-align:top" |
Grundlage dieses Implementierungsleitfadens ist der internationale Standard "HL7 Clinical Document Architecture, Release 2.0" (CDA ©), für die das Copyright © von Health Level Seven International gilt. 
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. Das Datenmodell von CDA und seine Abbildung in XML folgen dem Basisstandard HL7 Version 3 mit seinem Referenzinformationsmodell (RIM). 
 
Für die Modellierung der Inhalte des Impfpasses wurde das "Immunization Content (IC)" Inhaltsprofil aus dem IHE Technical Framework "Patient Care Coordination (PCC)" ausgewählt, das auch im Elektronischen Impf- und Immunschutzdossier der Schweiz [[http://e-health-wiki.ch/index.php/Ehscda:CDA-CH-VACD_(specification)]] verwendet wird und das als wesentliche Grundlage für diesen Leitfaden dient.
| [[Datei:Grafik VerwendeteStandards.png| 300px|Verwendete Standards]]
<ref group="Abbildung">Verwendete Standards</ref>

|}

*[https://www.ihe.net/resources/technical_frameworks/#pcc IHE Integrationsprofile Patient Care Coordination] <ref name=IHEPCC>IHE Patient Care Coordination (PCC) [Online Juli 2019]: https://www.ihe.net/resources/technical_frameworks/#pcc</ref>
*[http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 Clinical Document Architecture (CDA)] <ref name=HL7CDA>HL7 Clinical Document Architecture (CDA) [Online Juli 2019]: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>
*[http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186 Version 3 Product Suite (inkl. RIM)] <ref name=CDAV3RIM>Version 3 Product Suite (inkl. RIM) [Online Juli 2019]: RIM http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186</ref>
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria), die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden (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.

== Wichtige unterstützende Materialien ==
{{BeginYellowBox}}
Auf der Website [[ILF:E-Impfpass_Guide |e-Impfpass Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
* Beispieldokumente für den "Kompletten Immunisierungsstatus" und für "Update Immunisierungsstatus"
* Schematron-Prüfregeln
* Design-Beispiel
Die im Weiteren angeführten Templatespezifikationen wurden im '''Art-Decor Projektrepository''' [https://art-decor.org/art-decor/decor-templates--elgaimpf-?section=templates e-Impfpass] erstellt und können dort eingesehen werden. Eine Anleitung zum Verständnis der Art-Decor-Notation finden Sie im Artikel [[Hilfe:Art-Decor-Tabellen verstehen|Art-Decor-Tabellen verstehen]].
{{EndYellowBox}}
Weitere Informationen zu CDA-Leitfäden werden auf der Website der ELGA GmbH zur Unterstützung bereitgestellt:
* Beispieldokumente
* Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
* CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
* Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
* Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
* Hinweise für die zu verwendenden Terminologien
* Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}
Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA].
{{EndYellowBox}}

=Harmonisierung=
Dieser Implementierungsleitfaden entstand durch die Harmonisierungsarbeit der Arbeitsgruppe e-Impfpass, die im Zeitraum von September 2018 bis Februar 2019 tagte. Die Teilnehmer der Arbeitsgruppe wurden durch ihre Organisation delegiert.

Die Arbeitsgruppe harmonisierte primär die inhaltlichen Vorgaben und soweit möglich die zu verwendenden Terminologien (Value Sets).
Die Formulierung der technischen Spezifikation des CDA Implementierungsleitfadens e-Impfpass erfolgte durch die ELGA GmbH parallel bzw. nach der inhaltlichen Festlegung.

Der Leitfaden wird in einem technischen Abstimmungsverfahren durch die HL7 Austria ("Ballot") zu einem österreichischen Standard. Die Verbindlichkeit zur Anwendung soll durch eine Novellierung des Gesundheitstelematikgesetzes 2012, BGBl.I Nr.111/2012 begründet werden.

== Autoren und Mitwirkende ==
Der vorliegende Leitfaden wurde unter der Leitung der ELGA GmbH von den Autoren und unter Mitwirkung der genannten Personen (Mitglieder der Arbeitsgruppe) erstellt. Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht.
Die HL7 Austria und die ELGA GmbH genehmigen ausdrücklich die Anwendung des Leitfadens ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente und weisen darauf hin, dass dies mit dem Einverständnis aller Mitwirkenden erfolgt.

===Autoren===
'''Das Redaktionsteam''' bestand aus folgenden Personen:
{| class="wikitable"
! Name
! Organisation
! Rolle
|-
| Mag. Dr. Stefan Sabutsch
| ELGA GmbH, HL7 Austria
| Autor, Herausgeber
|-
| DI Andrea Klostermann
| ELGA GmbH
| Autor
|-
| DI Oliver Kuttin
| ELGA GmbH
| Autor

|}

Mit Beiträgen von:
Tony Schaller (medshare GmbH),
Stephan Rainer-Sablatnig (ELGA GmbH),
Nina Svec, M.A. (ELGA GmbH),
Gabriel Kleinoscheg, MSc. (ELGA GmbH),
DI Nikola Tanjga (ELGA GmbH),
Helene Prenner (ELGA GmbH)

===Mitwirkende===
'''Teilnehmer der Arbeitsgruppe e-Impfpass''' (in alphabetischer Reihenfolge):
Anton Angerer (at.Software / WAVM),
Patrick Awart (Atos),
Elisabeth Bischof (Landessanitätsdirektion OÖ),
DI (FH) Reindert Buter (Buter GmbH),
Sabine Eder (Landessanitätsdirektion NÖ),
Mag. Alexander Ertl (BASG / AGES),
Dr. Katja Fischer (BMASGK),
Günter Franz (Landessanitätsdirektion Salzburg),
W HR Dr. Ernst Gschiel (Landessanitätsdirektion Burgenland),
Dr. Eva Heinzl (Landessanitätsdirektion OÖ),
Ingrid Huber (Landessanitätsdirektion NÖ),
OPhysR Dr.in Ursula Karnthaler (Landessanitätsdirektion Wien),
Herbert Karpf, BA (Landessanitätsdirektion Kärnten),
HR Dr. med. univ. Franz Katzgraber (Landessanitätsdirektion Tirol),
DI Andrea Klostermann (ELGA GmbH),
DI Oliver Kuttin (ELGA GmbH),
Dr. Irmgard Lechner (Landessanitätsdirektion NÖ),
Ruprecht Leitner (Apothekerverlag),
Dr. Anita Luckner-Hornischer (Landessanitätsdirektion Tirol),
Dr. Lukas Murajda, PhD, MSc (Landessanitätsdirektion Salzburg),
DI Michael Nöhammer (ÖÄK),
Christopher Ozvald (BMASGK),
Dr. Georg Palmisano (Landessanitätsdirektion OÖ),
Dr. Maria Paulke-Korinek (BMASGK),
Mag. Daniela Philadelphy (BASG / AGES),
Daniela Piererfellner (Landessanitätsdirektion OÖ),
Maria Pramhas (Land Salzburg - Impfadatenbank),
Dr. Daniel Prenninger (Landessanitätsdirektion Burgenland),
Mag. Margit Pufitsch-Weber (Wissenschaftliche Akademie für Vorsorgemedizin),
Stephan Rainer-Sablatnig (ELGA GmbH),
Dr. Stefan Sabutsch (ELGA GmbH),
Robert Scharinger (BMASGK),
Dr.Rudolf Schmitzberger (Impfreferat Österr Ärztekammer),
DI Mag. Birgit Scholz (ELGA GmbH),
Dr. Christoph Schweighofer (ÖÄK),
Carina Seerainer, MSc (ELGA GmbH),
Nina Sjencic (ELGA GmbH),
Landessanitätsdirektorin OSRin Dr.in Karin SPACEK (Landessanitätsdirektion Wien (Magistratsabteilung 15 - Gesundheitsdienst der Stadt Wien)),
Mag. Stefan Spitzbart (Hauptverband),
Stephanie Stürzenbecher, BA MA (Hauptverband),
Dr. Barbara Tucek, MD, MSc (BASG / AGES),
Mag. Ilana Ventura, MSc (BMASGK),
Dr.med. Heimo Wallenko, MAS (Landessanitätsdirektion Kärnten),
Gabriele Wasner (Landessanitätsdirektion OÖ)

{{ILF:Begriffsdefinitionen e-Impfpass}}

=Technischer Hintergrund=

{{ILF:eImpfpass_Allgemeine_Richtlinien | Allgemeine Richtlinien für die Implementierung des e-Impfpasses}}

{{ILF:eImpfpass_Datentypen | e-Impfpass Datentypen}}

==Weitere Informationen zu CDA==
Weitere Informationen zum technischen Hintergrund finden sich unter folgenden Links:

* [[elga-cdaalf-2.06.2:Konzept_und_Modellbeschreibung| Allgemeine Informationen zu CDA]] <ref name=CDAAllgemein>Allgemeine Informationen zu CDA [Online Juli 2019]: https://wiki.hl7.at/index.php?title=elga-cdaalf-2.06.2:Konzept_und_Modellbeschreibung</ref>
* [[CDA_Templates|CDA Templates]] <ref name=CDATemplates>CDA Templates [Online Juli 2019]: https://wiki.hl7.at/index.php?title=CDA_Templates</ref>
* [[ILF:Art-Decor-Tabellen_verstehen|Art-Decor-Tabellen verstehen]] <ref name=ArtDecorVerstehen>Art-Decor-Tabellen verstehen [Online Juli 2019]: https://wiki.hl7.at/index.php?title=Hilfe:Art-Decor-Tabellen_verstehen</ref>
* [[elga-cdaalf-2.06.2:Technische Konformitätsprüfung|Technische Konformitätsprüfung]] <ref name=TechnKonform>Technische Konformitätsprüfung [Online Juli 2019]: https://wiki.hl7.at/index.php?title=elga-cdaalf-2.06.2:Technische_Konformit%C3%A4tspr%C3%Bcfung</ref>
* [[Terminologien|Terminologien]] <ref name=Terminologien>Terminologien [Online Juli 2019]: https://wiki.hl7.at/index.php?title=Terminologien</ref>
= Funktionale Anforderungen=

== Darstellung==
Für die Darstellung des e-Impfpasses wird ein spezielles Stylesheet bereitgestellt, das im XML-Prolog referenziert wird ("ELGA_eimpf-stylesheet_v1.0.xsl").
Grundsätzlich werden die Daten aus den Entries dargestellt. Section.Text MUSS dennoch angegeben werden, da der CDA Rel. 2 Standard "Lesbarkeit für Menschen" ("human readability") vorschreibt.

<div class="landscape">

==Verwendung in der ELGA Infrastruktur==
===Vorgaben zu Dokument-Metadaten (XDS-Metadaten)===
{| class="wikitable"
! XDS-Mapping
! Optio-
nalität
! CDA-Element
clinicalDocument.
! Beispiel
! Erklärung
|-
| formatCode
| R
| .templateId/@extension
|
*<nowiki>@extension="XDSdocumentEntry.formatCode
^urn:hl7-at:eImpf:2019"</nowiki>
*@isplayName= "HL7 Austria e-Impfpass 2019"
| Version des Implementierungsleitfaden e-Impfpass - "Update Immunisierungsstatus" bzw. "Kompletter Immunisierungsstatus" mit XDSdocumentEntry.formatCode als Extension.
Das templateId-Element mit einer Extension beginnend mit "XDSdocumentEntry.formatCode^" wird ins XDS-Attribut formatCode gemappt (ohne Präfix XDSdocumentEntry.formatCode^).
|-
| classCode
| R
| .code
|
*@code="11369-6"
*@displayName="HISTORY OF IMMUNIZATIONS"
*@codeSystem="2.16.840.1.113883.6.1"
| Bezeichnet die "Dokumentklasse". Zulässige Werte gemäß Value-Set "ELGA_Dokumentklassen".
Aus Gründen der Kompatibilität zu IHE PCC und auch den Ableitungen im Schweizer CH-VACD haben alle Impfungsdokumente den Code '''11369-6 History of Immunization Narrative'''.
|-
| rowspan="2"| typeCode
| rowspan="2"| R
| rowspan="2"| .code.translation
|
*@code="82593-5"
*@displayName="Immunization summary report"
*@codeSystem="2.16.840.1.113883.6.1"
| Zur Unterscheidung des Dokumenttyps erhält das Element clinicalDocument.code des '''"Kompletter Immunisierungsstatus"''' ein zusätzliches translation-Element.
|-
|
*@code="87273-9"
*@displayName="Immunization note"
*@codeSystem="2.16.840.1.113883.6.1"
| Zur Unterscheidung des Dokumenttyps erhält das Element clinicalDocument.code des '''"Update Immunisierungsstatus"''' ein zusätzliches translation-Element.
|-
| rowspan="2"| title
| rowspan="2"| R
| rowspan="2"| .title
| "Kompletter Immunisierungsstatus"
| Für den lesenden Dokumentempfänger gedachter Titel des '''Kompletten Immunisierungsstatus'''.
|-
| "Update Immunisierungsstatus"
| Für den lesenden Dokumentempfänger gedachter Titel des '''Update Immunisierungsstatus'''.
|-
| eventCodeList
| R
| .documentationOf
.serviceEvent.code
|
*@code="41000179103"
*@displayName="Immunization record (record artifact)"
*@codeSystem="2.16.840.1.113883.6.96"
*@codeSystemName="SNOMED CT"
| Code der Gesundheitsdienstleistung.
|-
| rowspan="2"| serviceStartTime
| rowspan="2"| R
| rowspan="2"|.documentationOf.serviceEvent
.effectiveTime.low
|
Zeitpunkt des '''ältesten''' effectiveTime aus:
*"Immunization Entry":
**templateId 1.2.40.0.34.6.0.11.3.1
**substanceAdministration.effectiveTime und
*"Impfrelevante Erkrankungen Problem Entry":
**templateId 1.2.40.0.34.6.0.11.3.9
**act.effectiveTime.low
| Beginn der Gesundheitsdienstleistung beim '''Kompletter Immunisierungsstatus'''.
|-
| Zeitpunkt des Behandlungsbeginns (aktueller Besuch).
| Beginn der Gesundheitsdienstleistung bei '''Update Immunisierungsstatus'''.
|-
| rowspan="2"| serviceStopTime
| rowspan="2"| R
| rowspan="2"| .documentationOf.serviceEvent
.effectiveTime.high
|
Zeitpunkt des '''jüngsten''' effectiveTime aus:
*"Immunization Entry":
**templateId 1.2.40.0.34.6.0.11.3.1
**substanceAdministration.effectiveTime und
*"Impfrelevante Erkrankungen Problem Entry":
**templateId 1.2.40.0.34.6.0.11.3.9
**act.effectiveTime.high
| Ende der Gesundheitsdienstleistung bei '''Kompletter Immunisierungsstatus'''.
|-
| Zeitpunkt des Behandlungsendes (aktuelle Behandlung,
muss sich von Behandlungsbeginn unterscheiden)
| Ende der Gesundheitsdienstleistung bei '''Update Immunisierungsstatus'''.
|
|-
| practiceSettingCode
| R
| ''Hinweis: dzt. noch nicht als CDA-Element umgesetzt (folgt in nächster Hauptversion)''
|
| Fachliche Zuordnung des Dokuments. Mögliche Werte: F023 "Interdisziplinärer Bereich" oder F001 "Allgemeinmedizin"
|}
</div>

==Versionierung & Stornierung==
Versionierung und Stornierung betrifft ausschließlich Dokumente vom Typ "Update Immunisierungsstatus".

Das von der e-Impfpass Anwendung erzeugte On-Demand Dokument "Kompletter Immunisierungsstatus" ist immer eine neue Version desselben Dokuments, d.h. es ändert sich nur die Versionsnummer (die SetID bleibt für alle Versionen des kompletten Immunisierungsstatus eines Patienten gleich).

===Versionierung von Dokumenten===
Dokumente vom Typ "Update Immunisierungsstatus" können über die IHE Transaktion ITI-41 versioniert werden.
Die Inhalte werden von der zentralen e-Impfpass-Anwendung verarbeitet und alle Inhalte in den Datenbestand integriert. Das bedeutet, dass alle Daten, die bereits durch ein Dokument in den zentralen Datenbestand übernommen wurden, durch das Update ersetzt werden. Daten, die in der neu registrierten Version nicht enthalten sind, gelten als gelöscht.
Die Fachlogik der zentralen e-Impfpass-Anwendung kann die Änderung oder Löschung verweigern, sollten dadurch inkonsistente Datenbestände entstehen (z.B. wenn Informationen gelöscht werden sollen, auf denen spätere Impfeinträge beruhen).

===Stornierung von Dokumenten===
Dokumente vom Typ "Update Immunisierungsstatus" können über IHE Transaktion ITI-57 storniert werden. Alle Inhalte, die ursprünglich durch das stornierte Dokument eingetragen wurden, werden gelöscht.
Die Fachlogik der zentralen e-Impfpass-Anwendung kann die Stornierung verweigern, sollten dadurch inkonsistente Datenbestände entstehen (z.B. wenn Informationen gelöscht werden sollen, auf denen spätere Impfeinträge beruhen).

==Impfempfehlungen==
Ein Ziel des e-Impfpasses ist, interessierten Ärztinnen und Ärzten sowie Bürgerinnen und Bürgern einen raschen Überblick über aktuelle zur Verfügung stehende Impfungen zu geben. Dazu werden vom e-Impfpass "Impfempfehlungen" ausgegeben. Eine Impfempfehlung enthält zu einer Impfung den jeweils nächsten fälligen Impftermin und dazu eine Handlungsanweisung (Handlungsempfehlung/Handlungsvorschlag). Impfempfehlungen werden für alle Impfungen erstellt, die bereits mindestens einmal erhalten wurden oder die für die Person laut Österreichischen Impfplan empfohlen sind.

Die Impfempfehlungen werden vom Expertensystem der zentralen Anwendung aktuell erstellt und gemeinsam mit dem On-Demand-Dokument "Kompletter Immunisierungsstatus" ausgegeben. Das Expertensystem ist ein Teil der Fachlogik der zentralen Anwendung und bildet den jeweils aktuellen Österreichischen Impfplan ab, der vom Nationalen Impfgremium herausgegeben wird. Der Impfplan wird in ein tabellarisches Regelwerk übersetzt und ins Expertensystem importiert. Zur Berechnung der Impfempfehlung werden folgende Parameter aus der persönlichen Impfdokumentation herangezogen:
* Alter der Person
* Geschlecht
* Bereits erhaltene Impfungen:
** Dosiskennung der letzten eingetragenen Impfung
** Impfstoff
** Impfschema (sofern abweichend vom Defaultschema)
* Durchgemachte impfrelevante Erkrankungen
* Indikation für Impfung ("Risikogruppe")

Automatisch erstellte Impfempfehlungen können mit individuellen Impfempfehlungen eines Arztes überschrieben werden, z.B. bei Vorliegen einer Antikörperbestimmung (Impftiter-Ergebnis). Die Begründung kann (z.B. mit dem Messwert als Kommentar) angegeben werden.

'''Dosiskennung''': Damit die nächste Impfung im Rahmen eines bestimmten Impfschemas korrekt berechnet werden kann, ist es nicht notwendig, dass alle bisher verabreichten Dosen einer Impfung dokumentiert werden. Es reicht, die jeweils letzte Dosis zu dokumentieren, dafür muss die Dosiskennung korrekt angegeben werden (z.B. "Dosis 3").

'''Impftiter''': Ergebnisse von Antikörperbestimmungen werden NICHT von der Berechnungslogik berücksichtigt. Wenn der Impftiter ein Abweichen vom automatisch berechneten Impftermin notwendig macht, muss vom Arzt eine individuelle Impfempfehlung erstellt werden, als Kommentar soll der Impftiter angegeben werden.

'''Handlungsempfehlung''': Für jede automatisch von der zentralen Anwendung ausgegebenen Impfempfehlung wird eine Handlungsempfehlung ausgegeben. Die Handlungsempfehlung wird durch einen Code repräsentiert (Element ''code'' im Immunization Recommendation Entry) und stammt aus einem Value Set (eImpf_SpecialCaseVaccination_VS). Die Bedeutung der Codes ist im Value Set beschrieben (Bedeutung, Anwendungsbeschreibung, Hinweise). Zur einfacheren Darstellung werden die Handlungsempfehlungen gruppiert und bestimmten farbigen Icons zugewiesen; die Zuordnung erfolgt über eine hierarchische Strukturierung im Value Set (Ebene 0 = Icon, Ebene 1 = Handlungsempfehlung)
===Empfehlung, keine Impfung durchzuführen (Kontraindikation)===
Eine Sonderform der Impfempfehlung ist die Empfehlung, KEINE Impfung durchzuführen, wenn eine medizinisch begründete Kontraindikation gegen eine bestimmte Impfung vorliegt.
Für die Angabe einer Kontraindikation sind neben vom berechtigten dokumentierenden Arzt (Author) für einen Patienten folgende Daten einzutragen:
* Impfziel
* Zeitraum, in dem die Kontraindikation gilt
* Kommentar
* Optional: Impfstoff
Vom Expertensystem der zentralen Anwendung wird im Kompletten Immunisierungsstatus eine entsprechende Handlungsanweisung ergänzt ("Impfung nicht indiziert").
{{BeginYellowBox}}
Die Angabe von Kontraindikationen ist derzeit '''nur für Impfungen gegen SARS-CoV-2 (COVID-19) möglich''', um die '''Ausnahmen von der Impfpflicht''' zu dokumentieren.
{{EndYellowBox}}

== Mehrsprachigkeit und grenzüberschreitender Austausch ==
Mehrsprachigkeit wird in dieser Version nicht unterstützt, ist aber für die Zukunft angedacht. Die entsprechenden Strukturen im Leitfaden sind bereits angelegt.

=User Storys ("Anwendungsfälle")=
Die Einsatzszenarien für dieses Datenaustauschformat werden in Form von User Storys ("Anwendungsfälle") knapp beschrieben, um dem Leser den Hintergrund zu vermitteln. Diese Beschreibung der Anwendungsfälle ist nicht normativ und keine Vorentscheidung für die tatsächliche Umsetzung. Eine detaillierte technische Beschreibung der Anwendungsfälle und der Geschäftsprozesse findet sich im Architekturdokument e-Impfpass <ref name=ELGAeImpfpass>ELGA GmbH [Online Oktober 2019]: https://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/index.html</ref>.

Die derzeit bei den unterschiedlichen Akteuren des österreichischen Gesundheitswesens auftretenden Anwendungsfälle betreffend Impfungen werden im Folgenden skizziert.

==Übersicht vorhandener Akteure und Komponenten==
Folgende Abbildung zeigt einen Überblick über die Architektur mit den Akteuren und Komponenten für den e-Impfpass.

[[Datei:Architektur_Ueberblick1.png|1000px|Uebersicht e-Impfpass: Akteure und Komponenten]]

<ref group="Abbildung>Übersicht e-Impfpass: Architektur mit Akteuren und Komponenten</ref>

* e-Impfpass-Teilnehmer / Bürger 
* Impfende GDA
** Niedergelassene Ärzte
*** Fachärztinnen und Fachärzte für Kinder und Jugendheilkunde
*** Ärztinnen und Ärzte für Allgemeinmedizin
** Landessanitätsdirektionen inkl. Amtsärzte (Amtsärzte, Schulärzte, Betriebsärzte)/öffentliche Gesundheitsdienste
* Interessensvertretung von Bürger- und Bürgerinnen-Rechten
** Bürgerinnen und Bürger, die im Z-PI erfasst sind, und dessen Vertreter, insbesondere Eltern-für-Kinder
** ELGA-Ombudsstelle
* ELGA-Serviceline 
* Datenkorrigierender GDA
** Bezirksverwaltungsbehörde
* "Abrechnungsunterstützung" (im Rahmen des kostenlosen Kinderimpfprogramms)
** Landeshauptmann / Landeshauptfrau
** Bezirksverwaltungsbehörde
* Auswertungen für Durchimpfungsraten
** Landeshauptmann / Landeshauptfrau
** Zuständiges Bundesministerium für Gesundheit

Bei der Betrachtung der technischen Architektur haben folgende Ausgangspunkte einen besonderen Stellenwert und werden deshalb kurz zusammengefasst:
# Die e-Impfpass Anwendung ist eine eHealth-Anwendung mit zentraler Datenhaltung.
# Die e-Impfpass Anwendung nutzt betreffend Autorisierung, Protokollierung und Zugangskontrolle die bestehende ELGA Infrastruktur.
# Berechtigte e-Impfpass Anwender (GDA) sind im GDA-I mit entsprechender Rolle gelistet.
# Es muss zwischen folgend aufgelisteten rollenbasierenden Zugangangsarten unterschieden werden.
## Regulärer Zugang mittels Kontaktbestätigungen
## Behördlicher Zugang für tagaktuelles Ausbruchs-Management (und Durchimpfungsrate) welcher gesetzlich geregelt wird (auch ohne Kontaktbestätigung). Hier zählen Zugriffe auf die Impfdaten von eindeutig identifizierten Personen.
# Verabreichte Impfungen müssen lückenlos in der e-Impfpass Anwendung gespeichert werden. Da der Immunisierungsstatus im Ausbruchsfall jederzeit abrufbar sein muss, kommen individuelle Berechtigungen von e-Impfpass-Teilnehmern nicht zur Anwendung (Gesetzesgrundlage ist hier maßgebend).
# Die Geschäftslogik der Anwendung übernimmt die CDA-Verarbeitung und hat folgende Funktionen
## Speichert eingehende CDA Dokumente "Update Immunisierungsstatus", zerlegt diese (entsprechend gültigem Schema) und persistiert die Informationseinheiten.
## Das Zusammenstellen vom OnDemand-Dokument "Kompletter Immunisierungsstatus" (der eigentliche e-Impfpass der Teilnehmer) muss unterstützt werden. Hierfür werden die Inhalte der zentralen Datenbank zusammengestellt und im angeforderten Format (CDA) ausgehändigt.
## Die analytisch-statistische Weiterverarbeitung (Abzüge für BI) bzw. Auswertungen müssen ermöglicht werden.
## Auf Grundlage des gültigen Österreichischen Impfplanes muss bei der Abfrage des persönlichen e-Impfpasses eines Teilnehmers das Datum der nächste(n) fälligen Impfungen und etwaige Nachhol-Impftermine beigefügt werden. Vom GDA manuell eingefügte Impftermine müssen unterstützt werden und diese dürfen von der Fachlogik nicht überschrieben werden.

==Allgemeine Vorbedingungen==
Für den Zugriff auf den elektronischen Impfpass (lesend und schreibend) sind spezielle Rollen und Berechtigungen erforderlich. Diese sowie der Vorgang zur Authentifizierung und Autorisierung sind im Architekturdokument e-Impfpass <ref name=ELGAeImpfpass/>erläutert.
Die notwendigen Stammdaten (z.B. Impfungen, Impfstoffe, impfrelevante Erkrankungen ...) werden über den [https://termpub.gesundheit.gv.at/ Terminologieserver] bereitgestellt.

Sowohl der berechtigte GDA (über das GDA System, sobald E-Card gesteckt wurde), als auch die Bürgerin/der Bürger (über das ELGA Portal) können auf den persönlichen e-Impfpass zugreifen.

==U1 Kompletten Immunisierungsstatus abrufen==
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Max Muster (ELGA Teilnehmer) besucht seinen Hausarzt Dr. DeCarro (Impfender GDA) und möchte Informationen zu seinem Immunisierungsstatus erhalten.
# Dr. DeCarro fragt den e-Impfpass von Max Muster über seine Softwaresystem ab und erhält das On-Demand-Dokument "Kompletter Immunisierungsstatus", das Auskunft über die bisherigen Impfungen und entsprechende Impfempfehlungen enthält.
#Max Muster erfährt von Dr. DeCarro, dass laut Österreichischem Impfplan die nächste FSME-Auffrischungsimpfung in einem Monat ansteht und vereinbart hierfür einen Termin bei Dr. DeCarro.

Auch wenn noch keine Immunisierungseinträge in der e-Impfpass Anwendung gespeichert sind, können Impfempfehlungen abgerufen werden.

==U2 Aktualisierung Immunisierungsstatus==

Wird eine Änderung am dokumentierten Immunisierungsstatus vorgenommen (z.B. neuer Impfeintrag, Nachtragen einer Impfdokumentation oder Korrektur einer bestehenden Impfung, Eintrag einer impfrelevanten Erkrankung), so werden die Änderungen mit dem Datenaustauschformat "Update Immunisierungsstatus" an die zentrale e-Impfpass Anwendung übermittelt. Die zentrale Anwendung übernimmt die Änderungen als Update und berechnet die nächsten empfohlenen Impftermine.

Es kann zwischen folgenden Anwendungsfällen unterschieden werden:

===U2.1 Eintragen des Immunisierungsstatus===
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Max Muster besucht seinen Hausarzt Dr. DeCarro, weil er einen Termin für eine FSME-Auffrischungsimpfung vereinbart hat.
# Dr. DeCarro fragt den e-Impfpass von Max Muster über seine Softwaresystem ab und erhält das Dokument "Kompletter Immunisierungsstatus" (U1), das Auskunft über die bisherigen Impfungen und entsprechende Impfempfehlungen enthält und kontrolliert, ob sich seit dem letzten Abruf Änderungen ergeben haben.
# Dr. DeCarro führt die Impfung durch und dokumentiert diese in seinem Softwaresystem. Nach der Freigabe der Dokumentation erzeugt das Softwaresystem ein Datenaustauschformat "Update Immunisierungsstatus" und sendet dieses an die zentrale Anwendung e-Impfpass, die das Dokument übernimmt und ein Update der Datenbank durchführt.
# Dr. DeCarro kann nun das Dokument "Kompletter Immunisierungsstatus" erneut abrufen und erhält eine neue Version des Dokuments mit aktualisiertem Immunisierungsstatus und neuen Impfempfehlungen für Max Muster.

===U2.2 Korrektur eines Immunisierungseintrags (eigene Einträge)===
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Dr. DeCarro stellt fest, dass der Eintrag, den er für Max Muster erstellt hat, korrigiert werden muss (z.B. wegen eines Dokumentationsfehlers oder weil die individuelle Impfempfehlung vergessen wurde)
# Dr. DeCarro korrigiert den Eintrag in seinem Softwaresystem, das eine neue Version des Dokuments "Update Immunisierungsstatus" an die zentrale Anwendung übergibt (dabei sind alle Einträge in der Korrekturversion enthalten, auch jene, die nicht geändert werden müssen).
# Die zentrale Anwendung ersetzt alle Daten, die durch das originale Dokument "Update Immunisierungsstatus" übernommen worden waren durch die Daten, die in der korrigierten Version enthalten sind. Die korrigierten Daten werden in das Dokument "Kompletter Immunisierungsstatus" eingetragen (Dr. DeCarro bleibt der Author aller betreffenden Einträge).

Die Berechtigung für eine Korrektur von bereits eingetragenen Immunisierungseinträgen hat nur jener GDA, der diese Impfdaten eingetragen hat. Zusätzlich hat eine gesetzlich festgelegte Rolle die Berechtigung (siehe [[#U4 Datenkorrektur durch Behörde|U4]]).

'''''Anmerkung:''''' Eigene Einträge erkennt man daran, dass das id-Element von "Berechtigter Bearbeiter" (Immunization Entry/participant @typeCode="AUT") die eigene GDA-OID enthält.

Die Vorversionen des CDA "Update Immunisierungsstatus" wurden als "DEPRECATED" gekennzeichnet. Die neue Version des CDA Dokuments wird mit dem Status "APPROVED" gespeichert.

===U2.3 Stornierung eines Immunisierungseintrags===
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Dr. DeCarro stellt fest, dass der Eintrag, den er erstellt hat, storniert werden muss (z.B., weil er für den falschen Patienten dokumentiert hat)
# Dr. DeCarro löscht den Eintrag in seinem Softwaresystem, das eine Stornierungsnachricht mit dem Verweis auf das zu stornierende "Update Immunisierungsstatus"-Dokument an die zentrale Anwendung übergibt.
# Die zentrale Anwendung löscht alle Daten, die durch die originale Nachricht "Update Immunisierungsstatus" übernommen worden waren.

Die Berechtigung für eine Stornierung von bereits eingetragenen Immunisierungseinträgen hat nur jener GDA, der diese Impfdaten eingetragen hat oder eine gesetzlich festgelegte Rolle (siehe [[#U4 Datenkorrektur durch Behörde|U4]]).

Stornierte CDA Dokumente wurden als "DEPRECATED" gekennzeichnet.

===U2.4 Nachtragen der Impfdokumentation===
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Max Muster besucht seinen Hausarzt Dr. DeCarro und möchte seinen Papier-Impfpass in den e-Impfpass überführen.
# Dr. DeCarro überträgt das Papierdokument in sein Softwaresystem, das ein Datenaustauschformat "Update Immunisierungsstatus" erzeugt und an die zentrale Anwendung übergibt.

===U2.5 Selbsteintragung von Impfungen durch den Bürger===
Akteure: e-Impfpass Teilnehmer ("Max Muster")

Szenario:
# Max Muster möchte seinen Papier-Impfpass selbst in den e-Impfpass überführen.
# Max Muster überträgt das Papierdokument mit einem über das Internet verfügbarem Softwaresystem, das ein Datenaustauschformat "Update Immunisierungsstatus" erzeugt und an die zentrale Anwendung übergibt.
# Seinen Papierimpfpass kann er digitalisiert als Beilage anhängen (alle weiteren Sektionen sind bei einem Selbsteintrag nicht verfügbar).

'''Anmerkung''': Dieses Szenario ergibt sich aus dem GTelG § 24e: "''(1) Bürger/innen sowie deren gesetzliche oder bevollmächtigte Vertreter/innen haben das Recht (...) 2. Impfungen in das zentrale Impfregister einzutragen, wobei diese '''selbsteingetragenen Impfungen als solche gekennzeichnet werden''' und für Gesundheitsdiensteanbieter gemäß § 24c Abs. 2 Z 1 '''nur zur Information dienen'''.''". Eine entsprechende Funktion steht zum Stand der Erstellung dieses Leitfadens noch nicht zur Verfügung.

==U3 Abrechnung==
''Anmerkung: Die Abrechnung selbst steht nicht im Fokus dieses Leitfadens. Er stellt lediglich sicher, das die für die Abrechnungsunterstützung notwendigen Informationen über das Datenaustauschformat übertragen werden können.''

Akteure: Impfender GDA ("Dr. DeCarro"), Abrechnungsunterstützung, Kind "Max Musterkind"

Szenario:
# Dr. DeCarro dokumentiert die Impfung des Kindes "Max Musterkind" (siehe U2.1)
# Das GDA-Softwaresystem erzeugt ein Datenaustauschformat "Update Immunisierungsstatus", das zusätzlich die Informationen zur Abrechenbarkeit enthält und sendet dieses an die zentrale Anwendung.
# Die Abrechnungsunterstützung erhält von der zentralen Anwendung einen Minimaldatensatz (d.h. nur die minimal notwendigen Daten für die Abrechnung), der ausschließlich die Impfungen enthält, die in der gewählten Zeit und Region entsprechen und die vom GDA als "abrechenbar" markiert wurden.
# Die Abrechnungsunterstützung kontrolliert den Anspruch an Abrechnung der einzelnen Einträge und leitet alle Schritte zur Überweisung des Abrechnungsbetrags in die Wege.

Im Rahmen des kostenfreien Kinderimpfprogramms rechnen sowohl Ärztinnen und Ärzte als auch Apotheken mit den Ländern Impfleistungen mit Hilfe der Informationen aus dem zentralen Impfregister ab. Die für die Abrechnung zuständigen Länderstellen können über die Informationen aus dem zentralen Impfregister nachvollziehen, welche Ärztin oder welcher Arzt, welche Impfung wann verabreicht hat und somit den Verrechnungs- und Ausbezahlungsprozess abwickeln. Nicht relevant für die Abrechnung sind z.B. nacherfasste oder stornierte Impfungen, Titereinträge oder Einträge zur Immunisierung durch Krankheit. Der aktuelle Stand der abrechnungsrelevanten Impfdaten aus dem zentralen Impfregister wird jeweils im Folgemonat für die Abrechnungsunterstützung zur Verfügung gestellt.

==U4 Datenkorrektur durch Behörde (fremde Einträge) ==
Akteure: e-Impfpass Teilnehmer ("Max Muster"), Amtsarzt mit der Rolle "Korrekturberechtigte Person" ("Amelia Amtsarzt")

Szenario:
# Max Muster stellt fest, dass Dr. DeCarro, der mittlerweile in Pension ist, beim Übertragen einer Reiseimpfung aus dem Papierimpfpass eine falsche Impfung eingetragen hat und möchte diese in seinem e-Impfpass korrigieren lassen. Er stellt bei der Bezirksverwaltungsbehörde (Rolle "Korrekturberechtigte Person") einen entsprechenden Antrag.
# Amelia Amtsarzt aus der Bezirksverwaltungsbehörde ruft den "Kompletten Immunisierungsstatus" von Max Muster ab und trägt entsprechende Änderungen in ihr Softwaresystem ein.
# Das Softwaresystem der Bezirksverwaltungsbehörde, übergibt eine korrigierte Version des Dokuments "Update Immunisierungsstatus" (jenes, mit dem Dr. DeCarro damals den falschen Eintrag eingemeldet hat) an die zentrale Anwendung. Dabei sind alle Einträge in der Korrekturversion enthalten, auch jene, die nicht geändert werden müssen (als document.author ist Amelia Amtsarzt eingetragen).
# Die zentrale Anwendung ersetzt alle Daten, die durch das originale Dokument "Update Immunisierungsstatus" übernommen worden waren durch die Daten, die in der korrigierten Version enthalten sind. Die korrigierten Daten werden in das Dokument "Kompletter Immunisierungsstatus" eingetragen und Amelia Amtsarzt wird bei den geänderten Einträgen als "Korrigierende Person" geführt.

Grundlegend kann ein GDA nur jene Einträge in der ELGA-Infrastruktur aktualisieren, die von ihm selbst eingetragen wurden. Unter bestimmten Rahmenbedingungen sollen behördliche Stellen Daten im Impfpass korrigieren dürfen (z.B. wenn der impfende GDA, der eine Dokumentation ursprünglich erstellt hat, nicht mehr in der Lage ist, die Daten selbst zu korrigieren). Bei der zentralen e-Impfpass Anwendung gibt es daher ausgewählte GDA, die Bezirksverwaltungsbehörden, die Immunisierungseinträge von anderen GDA aktualisieren oder stornieren dürfen. Dies ist notwendig, da Immunisierungseinträge lebenslang gespeichert werden, und es somit eine vom eintragenden GDA unabhängige Korrekturmöglichkeit falscher Daten geben muss.

==U5 Krisenmanagement==
''Anmerkung: Das Krisenmanagements selbst steht nicht im Fokus dieses Leitfadens, es wird nur der Vollständigkeit halber die Vorgehensweise beschrieben.''
===U5.1 Krankheitsausbrüche===
Im Rahmen des Krisenmanagements bei Krankheitsausbrüchen muss von Kontaktpersonen (z.B. in Schule, Kindergarten, Ordination, Wartebereichen in Ambulanzen) der Impfstatus erhoben werden. Derzeit erfolgt die Erhebung des Impfstatus aufwändig manuell bzw. in den lokal begrenzten Datenbanken. Durch die zentrale e-Impfpass Anwendung werden Umgebungsuntersuchungen digital unterstützt, indem die Impfdokumentation von Kontaktpersonen für die österreichische Bevölkerung elektronisch bezogen wird. Dies wird das Ausbruchsmanagement beschleunigen und vereinfachen und somit Ansteckungen vermeiden sowie Kosten des Ausbruchs(-managements) senken.

===U5.1 Chargenrückruf===
Ein weiterer Anwendungsfall im Krisenmanagement betrifft den Chargenrückruf von Impfstoffen. Momentan veröffentlicht das Bundesamt für Sicherheit im Gesundheitswesen (BASG) im Anlassfall die Chargennummern von Arzneimitteln die Qualitätsmängel aufweisen. Apotheken, die Chargenrückrufe erhalten, sortieren die Ware aus und geben diese ihrem Lieferanten wieder mit. Sollte die Impfung die Apotheke schon verlassen haben, wird eruiert welcher GDA oder Bürger betroffen ist und im Anlassfall kontaktiert.

<div class="landscape">

=Datenarten=
==Dataset==
{| class="wikitable"
! style="width: 25%" |Name
! style="width: 40%" |Beschreibung
! style="width: 20%" |Mapping
! style="width: 15%" |Datenelement-Nr.
|- style="vertical-align:top;"
|'''Unterzeichnende Person (Dokument)''' (Rechtlicher Unterzeichner)
|Der "Rechtliche Unterzeichner" oder "Hauptunterzeichner" ist jene Person, welche für ein Update des Immunisierungsstatus bzw. den Nachtrag aus rechtlicher Sicht die Verantwortung übernimmt (gesamtes Dokument!). Der "Rechtliche Unterzeichner" entfällt beim Kompletten Immunisierungsstatus, da dieser automatisch von einem Gerät erstellt wird (hier entfällt die Angabe aller Unterzeichner).
|clinicalDoc.LegalAuthenticator
|elgaimpf-dataelement-368
|- style="vertical-align:top;"
| style="padding-left: 15px" |Zeitpunkt der Unterzeichnung
|Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.
|
|elgaimpf-dataelement-369
|- style="vertical-align:top;"
| style="padding-left: 15px" |Signatur
|
|
|elgaimpf-dataelement-370
|- style="vertical-align:top;"
| style="padding-left: 15px" |ID des Unterzeichners
|
|
|elgaimpf-dataelement-371
|- style="vertical-align:top;"
| style="padding-left: 15px" |Kontaktdaten
|Weitere Kontaktdaten (Telefon, Handy, Email...)
|
|elgaimpf-dataelement-372
|- style="vertical-align:top;"
| style="padding-left: 15px" |Name
|Name der Person
|
|elgaimpf-dataelement-373
|- style="vertical-align:top;"
| style="padding-left: 15px" |Organisation
|
|
|elgaimpf-dataelement-374
|- style="vertical-align:top;"
|'''Eintragende Person (Schreibkraft)'''
|Datenverarbeitende Person. Die Person, die Daten für den Impfpass dokumentiert.
|clinicalDoc.dataEnterer
|elgaimpf-dataelement-32
|- style="vertical-align:top;"
|'''Verantwortliche Person (Impfung)''' (Medizinisch verantwortliche Person, auch: Impfstelle)
|Die Person, die für die Impfung und ihre Dokumentation letztlich medizinisch verantwortlich ist. "Dr. X (im Privat-KH Y) war für die Impfung verantwortlich/hat sie angeordnet". Bei neuem Immunisierungseintrag muss dieses Element angegeben sein. Bei einem Nachtrag kann dieses Element entfallen, wenn nicht mehr eruierbar. Empfohlenes Label für entsprechende Eingabefelder einer GUI: „Für die Impfung verantwortlich“…
|substanceAdministration "Immunization Entry"/author
|elgaimpf-dataelement-307
|- style="vertical-align:top;"
| style="padding-left: 15px" |Name
|
|
|elgaimpf-dataelement-339
|- style="vertical-align:top;"
| style="padding-left: 30px" |Titel (Präfix)
|Titel der Person (voran- und nachgestellte Titel)
|
|elgaimpf-dataelement-340
|- style="vertical-align:top;"
| style="padding-left: 30px" |Vorname
|Vornamen der Person
|
|elgaimpf-dataelement-343
|- style="vertical-align:top;"
| style="padding-left: 30px" |Nachname
|Nachname der Person
|
|elgaimpf-dataelement-344
|- style="vertical-align:top;"
| style="padding-left: 15px" |ID des Unterzeichners
|ID der verantwortlichen Person (lokaler Identifikator)
|
|elgaimpf-dataelement-346
|- style="vertical-align:top;"
| style="padding-left: 15px" |Kontaktdaten
|Weitere Kontaktdaten (Telefon, Handy, Email...)
|
|elgaimpf-dataelement-347
|- style="vertical-align:top;"
| style="padding-left: 15px" |Organisation
|
|
|elgaimpf-dataelement-353
|- style="vertical-align:top;"
| style="padding-left: 30px" |ID der Organisation
|
|
|elgaimpf-dataelement-381
|- style="vertical-align:top;"
| style="padding-left: 30px" |Name der Organisation
|
|
|elgaimpf-dataelement-382
|- style="vertical-align:top;"
| style="padding-left: 30px" |Telekom
|Weitere Kontaktdaten (Telefon, Handy, Email...)
|
|elgaimpf-dataelement-383
|- style="vertical-align:top;"
| style="padding-left: 30px" |Adresse
|Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...)
|
|elgaimpf-dataelement-384
|- style="vertical-align:top;"
| style="padding-left: 15px" |Freigabezeitpunkt (Zeitpunkt der Unterzeichnung)
|Der Zeitpunkt, an dem die Dokumentation freigegeben wurde
|substanceAdministation.author.time
|elgaimpf-dataelement-366
|- style="vertical-align:top;"
|'''Impfende Person (Impfarzt)'''
|Die Person, die ''im Auftrag der medizinisch verantwortlichen Person'' die Impfung durchführt, z.B. ein Turnusarzt, eine Hebamme oder eine diplomierte Pflegeperson. Die Impfende Person ''kann'' mit der medizinisch verantwortlichen Person ident sein und es können auch beide (redundant) angegeben werden.
|substanceAdministration "Immunization Entry"/performer
|elgaimpf-dataelement-140
|- style="vertical-align:top;"
| style="padding-left: 15px" |Name
|Name der Person
|
|elgaimpf-dataelement-236
|- style="vertical-align:top;"
| style="padding-left: 30px" |Titel (Präfix)
|Titel der Person (voran- und nachgestellte Titel)
|
|elgaimpf-dataelement-237
|- style="vertical-align:top;"
| style="padding-left: 30px" |Vorname
|Vornamen der Person
|
|elgaimpf-dataelement-240
|- style="vertical-align:top;"
| style="padding-left: 30px" |Nachname
|Nachname der Person
|
|elgaimpf-dataelement-241
|- style="vertical-align:top;"
| style="padding-left: 15px" |Organisation
|
|
|elgaimpf-dataelement-294
|- style="vertical-align:top;"
| style="padding-left: 30px" |ID der Organisation
|
|
|elgaimpf-dataelement-389
|- style="vertical-align:top;"
| style="padding-left: 30px" |Name der Organisation
|
|
|elgaimpf-dataelement-390
|- style="vertical-align:top;"
| style="padding-left: 30px" |Telekom
|Weitere Kontaktdaten (Telefon, Handy, Email...)
|
|elgaimpf-dataelement-391
|- style="vertical-align:top;"
| style="padding-left: 30px" |Adresse
|Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...)
|
|elgaimpf-dataelement-392
|- style="vertical-align:top;"
| style="padding-left: 15px" |Rolle
|Berufsrolle der impfenden Person (Auswahlliste)
|
|elgaimpf-dataelement-210
|- style="vertical-align:top;"
|'''Nachtragende Person'''
|Die Person, die für die fachliche Richtigkeit des Nachtrags verantwortlich ist. Nur für Nachtragung relevant, dort verpflichtend anzugeben. (Z.B: "Dr. Z hat diese Impfung nachgetragen.") Wenn Immunisierungsdaten per Stapelverarbeitung aus bestehenden Registern in den e-Impfpass übertragen werden, kann hier auch das Register eingetragen werden, aus dem die Daten stammen (z.B. "Impfregister des Landes…")
|substanceAdministration "Immunization Entry"/participant mit @typeCode = "ENT"
|elgaimpf-dataelement-285
|- style="vertical-align:top;"
| style="padding-left: 15px" |Name
|Name der Person
|
|elgaimpf-dataelement-286
|- style="vertical-align:top;"
| style="padding-left: 30px" |Titel (Präfix)
|Titel der Person
|
|elgaimpf-dataelement-287
|- style="vertical-align:top;"
| style="padding-left: 30px" |Vorname
|Vornamen der Person
|
|elgaimpf-dataelement-290
|- style="vertical-align:top;"
| style="padding-left: 30px" |Nachname
|Nachname der Person
|
|elgaimpf-dataelement-291
|- style="vertical-align:top;"
| style="padding-left: 15px" |Datum der Eintragung (Eintragungsdatum, Datum der Dokumentation)
|Datum und Zeit, an dem die Impfung in den e-Impfpass eingetragen d.h. dokumentiert oder geändert wurde. Gilt auch bei einer nachträglichen Eintragung aus einer anderen Quelle (z.B. Papier-Impfpass, andere elektronische Quellen), d.h. NICHT das Impf-Datum
|substanceAdministration "Immunization Entry"/participant mit @typeCode = "ENT" / time
|elgaimpf-dataelement-293
|- style="vertical-align:top;"
|'''Korrigierende Person'''
|Die Person, die für die fachliche Richtigkeit der Korrektur eines bestehenden Immunisierungseintrags verantwortlich ist.
|substanceAdministration "Immunization Entry"/participant mit @typeCode = "VRF"
|elgaimpf-dataelement-402
|- style="vertical-align:top;"
| style="padding-left: 15px" |Name
|Name der Person (mit Titel, Vorname, Name, Organisation)
|
|elgaimpf-dataelement-404
|- style="vertical-align:top;"
| style="padding-left: 15px" |Datum der Korrektur (Korrekturdatum)
|Datum und Zeit, an dem die Korrektur im e-Impfpass eingetragen wurde.
|substanceAdministration "Immunization Entry"/participant mit @typeCode = "VRF" / time
|elgaimpf-dataelement-403
|- style="vertical-align:top;"
|'''Berechtigter Bearbeiter'''
|Die eindeutige Kennung des GDA, der einen Immunisierungs-Eintrag (entry) bearbeiten darf. Das Berechtigungssystem erlaubt die Korrektur eines Eintrags nur einem GDA mit derselben OID ''oder'' GDA mit der Rolle "Korrekturberechtigte Person".
|substanceAdministration "Immunization Entry"/participant mit @typeCode = "AUT"
|elgaimpf-dataelement-405
|- style="vertical-align:top;"
|'''Impfling''' (Patient, Klient, Kunde)
|Der Impfling ist die Person, über die der e-Impfpass Impfungen verwaltet und über deren Gesundheitsdaten berichtet wird.. Entspricht dem "Patienten".
|clinicalDocument.recordTarget
|elgaimpf-dataelement-1
|- style="vertical-align:top;"
| style="padding-left: 15px" |Name
|Name der Person
|
|elgaimpf-dataelement-172
|- style="vertical-align:top;"
| style="padding-left: 30px" |Titel (Präfix)
|Titel der Person (voran- und nachgestellte Titel)
|
|elgaimpf-dataelement-173
|- style="vertical-align:top;"
| style="padding-left: 30px" |Vorname
|Vornamen der Person
|
|elgaimpf-dataelement-176
|- style="vertical-align:top;"
| style="padding-left: 30px" |Nachname
|Nachname der Person
|
|elgaimpf-dataelement-177
|- style="vertical-align:top;"
| style="padding-left: 15px" |Geburtstdatum
|Geburtstdatum der Person
|
|elgaimpf-dataelement-95
|- style="vertical-align:top;"
| style="padding-left: 15px" |Geschlecht (Administatives Geschlecht)
|Administatives Geschlecht der Person im Sinne der Anrede oder Adressierung zB Brief: "Herr" oder "Frau"
|Werte: M, F. UNK (Unbekannt)
|elgaimpf-dataelement-94
|- style="vertical-align:top;"
| style="padding-left: 15px" |LokaleID
|Identifikator des Impflings im lokalen IT-System (Patientenbezogen, nicht fallbezogen) Verpflichtend mit Eintragung einer Impfung anzugeben.
|
|elgaimpf-dataelement-86
|- style="vertical-align:top;"
| style="padding-left: 15px" |SVNr (Sozialversicherungsnummer)
|Sozialversicherungsnummer
|
|elgaimpf-dataelement-87
|- style="vertical-align:top;"
| style="padding-left: 15px" |bPK-GH
|Gemäß eGovernment-Gesetz ist das bPk-GH der eindeutige Identifikator für den Gesundheitsbereich. Verpflichtende Angabe im CDA-Header für spezifische ELGA-Anwendungen (z.B. e-Medikation)
|
|elgaimpf-dataelement-88
|- style="vertical-align:top;"
| style="padding-left: 15px" |Adresse
|Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...)
|
|elgaimpf-dataelement-219
|- style="vertical-align:top;"
| style="padding-left: 30px" |Straße
|
|
|elgaimpf-dataelement-252
|- style="vertical-align:top;"
| style="padding-left: 30px" |Hausnummer
|
|
|elgaimpf-dataelement-253
|- style="vertical-align:top;"
| style="padding-left: 30px" |Postleitzahl
|
|
|elgaimpf-dataelement-254
|- style="vertical-align:top;"
| style="padding-left: 30px" |Stadt
|
|
|elgaimpf-dataelement-255
|- style="vertical-align:top;"
| style="padding-left: 30px" |Bundesland
|
|
|elgaimpf-dataelement-256
|- style="vertical-align:top;"
| style="padding-left: 30px" |Land
|
|
|elgaimpf-dataelement-257
|- style="vertical-align:top;"
| style="padding-left: 15px" |Gemeindekennziffer (GKZ, ÖSTAT-Nr.)
|Allen Gemeinden Österreichs ist eine 5-stellige Gemeindekennziffer (GKZ) zugeordnet. Das Gemeindeverzeichnis bildet die Verwaltungsgliederung in Verwaltungssprengel ab. Die Vergabe der Gemeindekennziffer obliegt Statistik Austria (Adressregisterverordnung – AdrRegV, BGBl. 218/2005, §1).
|Kein Mapping, ist nicht im CDA Dokumenten enthalten. Liegt in der zentralen Anwendung zur Adresse vor.
|elgaimpf-dataelement-49
|- style="vertical-align:top;"
| style="padding-left: 15px" |Bezirkskennziffer (BKZ)
|Wie Gemeindekennziffer, erste 3 Stellen
|Kein Mapping, ist nicht im CDA Dokumenten enthalten. Liegt in der zentralen Anwendung zur Adresse vor.
|elgaimpf-dataelement-85
|- style="vertical-align:top;"
| style="padding-left: 15px" |Kontaktdaten
|Weitere Kontaktdaten (Telefon, Handy, Email...)
|
|elgaimpf-dataelement-216
|- style="vertical-align:top;"
| style="padding-left: 30px" |Telefon Mobil
|
|
|elgaimpf-dataelement-227
|- style="vertical-align:top;"
| style="padding-left: 30px" |Telefon Festnetz
|
|
|elgaimpf-dataelement-228
|- style="vertical-align:top;"
| style="padding-left: 30px" |Mail
|
|
|elgaimpf-dataelement-229
|- style="vertical-align:top;"
| style="padding-left: 30px" |FAX
|
|
|elgaimpf-dataelement-230
|- style="vertical-align:top;"
|'''Personengruppe''' (Expositionsrisikogruppe)
|Merkmal für Zugehörigkeit des Impflings zu bestimmten Personen- oder Risikogruppen (z.B. Gesundheitsberufe). Bei bestimmten Personengruppen kann das Impfschema und damit die berechnete Impffrist abweichen. Optional, mehrfache Angabe möglich.
|Sektion "Expositionsrisiko Personengruppen" mit Act "Expositionsrisiko Problem Concern Entry"
|elgaimpf-dataelement-125
|- style="vertical-align:top;"
| style="padding-left: 15px" |Zeitbereich
|Zeitbereich, in dem die Zugehörigkeit zur Personengruppe aktiv ist oder war
|
|elgaimpf-dataelement-394
|- style="vertical-align:top;"
|'''Impfung''' (Vakzination, Schutzimpfung, Immunisierung )
|Dokumentierte Impfung: ein einzelne Gabe eines Impfstoffes
|Sektion "Impfungen - kodiert", substanceAdministration "Immunization Entry"
|elgaimpf-dataelement-2
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfung (Klassifikation) (Impfschutz, Impfstoffgruppe, Immunisierung)
|Impfschutz gegen eine bestimmte Krankheit oder einen Erreger. Mehrfach-Attribut - Bei einer Impfung mit einem Produkt können mehrere Wirkstoffe (gegen mehrere Krankheiten) verabreicht werden. Alle einzelnen "Impfungen" müssen zu dem Produkt zentral verfügbar sein.
|substanceAdministration "Immunization Entry" und entryRelationship/Observation "Immunization Target Entry"
|elgaimpf-dataelement-6
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfschema (Impfkonzept, vaccinationProtocol)
|Name für den "Plan der notwendigen Impf-Dosen" (Regelwerk für die Gabe von Impfdosen bzw Teilimpfungen zur Immunisierung; Grundimmunissierung und Auffrischung) Wenn bei Impfung nicht angegeben, wird das "Default-Schema" angenommen.
|Mapping: substanceAdministration "Immunization Entry" und precondition/criterion "Immunization Schedule Entry"
|elgaimpf-dataelement-25
|- style="vertical-align:top;"
| style="padding-left: 15px" |Dosiskennung (Dosis-Nummer, Reihenfolgenummer in der Sequenz der Impfdosen)
|Angabe, um welche Impfung oder Teilimpfung es sich handelt (entsprechend einem Impfschema)
|Mapping: criterion "Immunization Schedule Entry"/value
|elgaimpf-dataelement-30
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfdatum (Vaccination administration date)
|Zeitpunkt der Durchführung der Impfung
|substanceAdministration "Immunization Entry"/effectiveTime
|elgaimpf-dataelement-8
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfort
|Ort, an dem die Impfung stattgefunden hat (wenn abweichend von Organisation Impfarzt). (z.B: Öffentliche Einrichtung, Schule (+ Klasse), Kaserne, Betrieb ...)
|Muss immer im "Performer" Element des Immunization Entry angegeben werden.
Wenn der verantwortliche Arzt selbst impft, muss er zusätzlich als Impfarzt eingetragen werden. substanceAdministration "Immunization Entry"/performer/assignedEntity/representedOrganization/addr (mit @use="PHYS")
|elgaimpf-dataelement-137
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfreaktion (Reaktion)
|Aufgetretene Reaktion, Auswahlkatalog
|Wurde nicht umgesetzt
|elgaimpf-dataelement-283
|- style="vertical-align:top;"
| style="padding-left: 15px" |Abrechenbarkeit
|Kennzeichen, ob Impfung mit Land abgerechnet werden kann (Eintragung durch impfenden Arzt)
|Notwendig für Filterung der Daten, die an Länder zur Abrechnung der Impfungen weitergeleitet werden. Die Abrechenbarkeit selbst wird vom Land geprüft und festgestellt.Mapping: substanceAdministration "Immunization Entry" und entryRelationship/act "Immunization Billability Entry"
|elgaimpf-dataelement-29
|- style="vertical-align:top;"
| style="padding-left: 30px" |Klassifikator (Honorar-Klassifikation)
|Abrechnungsrelevante Klassifikation der Impfenden Person (zB "Arzt mit Hausapotheke"). Wird im Zentralsystem nicht mehr benötigt, daher gestrichen. --> Die Verrechnung etc. erfolgt über die internen GDA Systeme (benötigt wird nur die Kennzeichnungsmöglichkeit ob abrechenbar oder nicht
|act "Immunization Billability Entry"/code/qualifier
|elgaimpf-dataelement-367
|- style="vertical-align:top;"
| style="padding-left: 30px" |Impfindikation
|Grund für die Impfung (optional). Wird für Abrechnung benötigt: * IG1 Indikationsimpfung für Risikogruppe * IG2 Wiederholungsimpfung aufgrund medizinischer Indikation
|act "Immunization Billability Entry"/code/qualifier
|elgaimpf-dataelement-379
|- style="vertical-align:top;"
| style="padding-left: 30px" |Impfgutschein
|Identifikationskennzeichen eines Impf-Gutscheins (bei Vorliegen von Impf-Gutscheinheften)
|Notwendig für Abrechnung. Alphanumerisches Kennzeichen (gültig 1x für eine Impfung). Keine weitere Prüfung im e-Impfpass.Mapping: act "Immunization Billability Entry" mit act/id
|elgaimpf-dataelement-139
|- style="vertical-align:top;"
| style="padding-left: 15px" |Zusatzklassifikation
|Zusätzliche strukturierte Information zu einer Impfung, zB eine Klassifizierung der Umgebung, in der die Impfung stattgefunden hat.
|"Immunization Entry" mit observation "Zusatzklassifikation" Das @code-Attribut definiert die Art der Klassifizierung, der Wert wird im @value-Attribut angegeben.
|elgaimpf-dataelement-401
|- style="vertical-align:top;"
|'''Impfstoff (Produkt)''' (Arzneimittel)
|Daten zur verabreichten Arzneimittelspezialität
|substanceAdministration "Immunization Entry" und consumable/manufacturedProduct "Vaccine Product" bzw. "Vaccine Product nicht angegeben"
|elgaimpf-dataelement-3
|- style="vertical-align:top;"
| style="padding-left: 15px" |Bezeichnung der Arnzei (Zulassungsname)
|Bezeichnung des Impfstoffes, z.B. "Encepur 0,25 ml für Kinder Injektionssuspension in einer Fertigspritze"
|manufacturedProduct/manufacturedMaterial/name
|elgaimpf-dataelement-31
|- style="vertical-align:top;"
| style="padding-left: 15px" |Pharmazentralnummer (PZN)
|Pharmazentralnummer der Arzneispezialität
|manufacturedProduct/manufacturedMaterial/code
|elgaimpf-dataelement-5
|- style="vertical-align:top;"
| style="padding-left: 15px" |Chargennummer (Charge)
|Chargennummer der Arzneispezialität, die verabreicht wurde
|manufacturedProduct/manufacturedMaterial/lotNumberText
|elgaimpf-dataelement-4
|- style="vertical-align:top;"
| style="padding-left: 15px" |Ablaufdatum
|Muss dokumentiert werden. Kann aus 2D Barcode abgleitet werden Nicht für "Nacherfassung" erforderlich
|substanceAdministration "Immunization Entry" mit entryRelationship/act "Immunization Billability Entry"/effectiveTime
|elgaimpf-dataelement-134
|- style="vertical-align:top;"
| style="padding-left: 15px" |UniqueIdentifier (Serialisierungsnummer)
|Serialisierungsnummer oder "Packungs-Identifikator. Durch die Serialisierungsnummer ist jede einzelne Packung im europäischen Markt individualisierbar, entsprechend Fälschungsschutzrichtlinie 2011/62/EU und zugehörigerr delegierte Verordnung (EU) 2016/161
|manufacturedProduct/id
|elgaimpf-dataelement-135
|- style="vertical-align:top;"
| style="padding-left: 15px" |Hersteller (Zulassungsinhaber)
|Hersteller (Zulassungsinhaber) des Impfstoffes (bzw. der Arzneispezialität)
|manufacturedProduct/manufacturerOrganization
|elgaimpf-dataelement-12
|- style="vertical-align:top;"
| style="padding-left: 15px" |ATC
|ATC-Code des Wirkstoffs aus Fachinformation
|manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:code
|elgaimpf-dataelement-235
|- style="vertical-align:top;"
| style="padding-left: 15px" |Wirkstoff
|Wirkstoff(e) des Arzneimittels, zB "Masernviren, Stamm Schwarz (lebend, attenuiert)
|manufacturedMaterial/pharm:ingredient
|elgaimpf-dataelement-185
|- style="vertical-align:top;"
| style="padding-left: 15px" |Menge (Dosis)
|Menge der verabreichten Arzneispezialität (Mengenangabe aus Fachinformation). '''Hinweis:''' Die tatsächlich verabreichte Menge kann dokumentiert werden, falls von Fachinformation abweichend. Falls zwei Impfdosen verabreicht werden ("zwei Packungen"), gibt es zwei Möglichkeiten der Dokumentation: Wenn die Packungen dieselbe Chargennummer besitzen: Verabreichte Menge verdoppeln, nur eine Impfung dokumentieren (zwei Impfungen mit derselben Chargennummer würden von der zentralen Applikation als Duplikat erkannt und ignoriert). Wenn zwei unterschiedliche Chargennummern verimpft werden, können beide jeweils als eine eigene Impfung mit derselben Dosiskennung und demselben Impfdatum gespeichert werden.
|substanceAdministration "Immunization Entry"/doseQuantity
|elgaimpf-dataelement-15
|- style="vertical-align:top;"
|'''Impfempfehlung''' (Impfkalender)
|Daten der empfohlenen (zukünftigen) Impfungen: * Impfung, Arzneimittel, frühestmöglicher Folgetermin (Tag) * Anzugebende Folgetermine: immer nur der nächste Folgetermin Die Impflogik gilt grundsätzlich für lt. Impfplan empfohlene Impfungen und für darüber hinaus bereits einmal verabreichte Impfungen Automatisch / von Arzt eingetragen (zusätzlich)
|Sektion "Impfempfehlungen - kodiert" mit entry/substanceAdministration "Immunization Recommendation Entry" und negationInd "false".
|elgaimpf-dataelement-169
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impf-Frist (Datum der nächsten Impfung)
|Datum (Frist oder Zeitraum), an dem der nächste Impftermin (für diese Impfung) notwendig ist. Wird definiert durch: Nationaler Impfplan Fachinformation (liegt derzeit nicht strukturiert vor) Individuelle Konstellation des Impflings --> manueller Eintrag bei Impfung (Abhängig vom Produkt bzw "Impfung", wenn Kombinationspräparat)
|choice von /effectiveTime als TS und /effectiveTime als IVL_TS
|elgaimpf-dataelement-28
|- style="vertical-align:top;"
| style="padding-left: 15px" |Dosiskennung (Dosis-Nummer, Reihenfolgenummer in der Sequenz der Impfdosen)
|Angabe, um welche Impfung oder Teilimpfung es sich handelt (entsprechend einem Impfschema)
|/precondition/criterion "Immunization Schedule Entry"
|elgaimpf-dataelement-231
|- style="vertical-align:top;"
| style="padding-left: 15px" |Autor (Quelle)
|Person oder System, das die Empfehlung generiert
|/author
|elgaimpf-dataelement-232
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfung (Klassifikation) (Referenz)
|Verweist auf die Impfung, für die diese Empfehlung gilt. Eine Impfempfehlung pro Impfung (nicht pro Kombination)
|entryRelationship mit observation "Immunization Target Entry"
|elgaimpf-dataelement-380
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfstoff (Referenz)
|Verweist auf das Produkt, für das die Empfehlung gilt; aber mit eingeschränkten Attributen (PZN)
|consumable
|elgaimpf-dataelement-233
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfschema (Referenz)
|Referenz auf den der Empfehlung zugrundeliegenden Impfplan, Fachinformation, Dokumentation, … 1. Nationaler Impfplan 2. Fachinformation (liegt derzeit nicht strukturiert vor) 3. Individuelle Konstellation des Impflings --> manueller Eintrag bei Impfung (Abhängig vom Produkt bzw "Impfung", wenn Kombinationspräparat)
|reference/externalDocument
|elgaimpf-dataelement-234
|- style="vertical-align:top;"
| style="padding-left: 15px" |Begründung
|Freitext zur Begründung einer vom Impfarzt angepassten Impfempfehlung
|entryRelationship/@typeCode = "RSON" mit act "Comment Entry"
|elgaimpf-dataelement-171
|- style="vertical-align:top;"
|- style="vertical-align:top;"
|'''Kontraindikation für Impfungen'''
|Daten der Impfungen, die nicht verabreicht werden sollen: * Impfung 

*Zeitraum, in dem die Kontraindikation gilt * Kommentar Muss von einem Arzt eingetragen werden
|Sektion "Impfempfehlungen - kodiert" mit entry/substanceAdministration "Immunization Recommendation Entry" und negationInd "true".
|elgaimpf-dataelement-169
|- style="vertical-align:top;"
| style="padding-left: 15px" |Zeitraum
|Zeitraum, in dem die Kontraindikation gilt
|choice von /effectiveTime als TS und /effectiveTime als IVL_TS
|elgaimpf-dataelement-28
|- style="vertical-align:top;"
| style="padding-left: 15px" |Autor (Quelle)
|Person oder System, das die Kontraindikation bestätigt
|/author
|elgaimpf-dataelement-232
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfung (Klassifikation) (Referenz)
|Verweist auf die Impfung, für die diese Kontraindikation gilt.
|entryRelationship mit observation "Immunization Target Entry"
|elgaimpf-dataelement-380
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfstoff (Referenz)
|Verweist auf das Produkt, für das die Kontraindikation gilt
|consumable
|elgaimpf-dataelement-233
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfschema (Referenz)
|Referenz auf den der Kontraindikation zugrundeliegenden Impfplan, Fachinformation, Dokumentation, … 1. Nationaler Impfplan 2. Fachinformation (liegt derzeit nicht strukturiert vor) 3. Individuelle Konstellation des Impflings --> manueller Eintrag bei Impfung (Abhängig vom Produkt bzw "Impfung", wenn Kombinationspräparat)
|reference/externalDocument
|elgaimpf-dataelement-234
|- style="vertical-align:top;"
| style="padding-left: 15px" |Begründung
|Freitext zur Begründung einer vom Arzt eingetragenen Kontraindikation
|entryRelationship/@typeCode = "RSON" mit act "Comment Entry"
|elgaimpf-dataelement-171
|- style="vertical-align:top;"
|'''Impfrelevante Erkrankung'''
|Dokumentation von Infektionskrankheiten, die eine langfristige Immunisierung nach sich ziehen und daher eine weitere Impfung nicht notwendig machen. Die Eintragung erfolgt optional bei der Erhebung der Impfanamnese.
|Sektion "Impfrelevante Erkrankungen - kodiert" mit act "Impfrelevante Erkrankungen Problem Concern Entry"
|elgaimpf-dataelement-27
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfrelevante Erkrankung
|Impfrelevante Erkrankung (aus Auswahlkatalog, z.B. FSME, Varizellen, ...)
|Sektion "Impfrelevante Erkrankungen - kodiert" mit act "Impfrelevante Erkrankungen Problem Concern Entry"
|elgaimpf-dataelement-126
|- style="vertical-align:top;"
| style="padding-left: 15px" |Erkrankungsdatum
|Zeitintervall, in der die Erkrankung beobachtet wurde
|
|elgaimpf-dataelement-393
|- style="vertical-align:top;"
| style="padding-left: 15px" |Bemerkungen (Anmerkungen)
|Freitext für Eintragung des Nachweises der durchgemachten Erkrankung, z.B. durch Vorbefund oder Laborbefund mit Titer.
|observation "Impfrelevante Erkrankungen Problem Entry" mit entryRelationship act "Comment Entry"
|elgaimpf-dataelement-16
|- style="vertical-align:top;"
| style="padding-left: 15px" |Autor
|Erfasser der Information
|
|elgaimpf-dataelement-282
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfung (Referenz)
|Verknüpfung zu Impfung
|
|elgaimpf-dataelement-284
|- style="vertical-align:top;"
|'''Antikörper-Bestimmung (Impftiter)'''
|Ergebnisse von Antikörper-Untersuchungen, Antikörper Bestimmungen für für Virushepatitis A und B, Röteln und Varizellen etc.
|Sektion "Antikörper-Bestimmung" mit act "Lab Report Data Processing Entry" und entryRelationship "Laboratory Observation Entry"
|elgaimpf-dataelement-129
|- style="vertical-align:top;"
| style="padding-left: 15px" |Analyse
|Gemessener Laborparameter
|"Laboratory Observation Entry"
|elgaimpf-dataelement-271
|- style="vertical-align:top;"
| style="padding-left: 15px" |Wert
|Wert der Analyse
|"Laboratory Observation Entry" / value
|elgaimpf-dataelement-272
|- style="vertical-align:top;"
| style="padding-left: 15px" |Einheit
|Einheit des Messwerts. Muss in UCUM Notation angegeben werden
|"Laboratory Observation Entry" /value/@unit
|elgaimpf-dataelement-273
|- style="vertical-align:top;"
| style="padding-left: 15px" |Bewertung (Interpretation)
|Interpretations des Messwerts (Interpretationskennzeichen)
|"Laboratory Observation Entry" /interpretationCode
|elgaimpf-dataelement-274
|- style="vertical-align:top;"
| style="padding-left: 15px" |Datum
|Datum der Abnahme (wenn nicht vorhanden, Datum der Bestimmung)
|"Laboratory Observation Entry" /effectiveTime
|elgaimpf-dataelement-275
|- style="vertical-align:top;"
| style="padding-left: 15px" |Durchführendes Labor
|Durchführendes Labor
|"Laboratory Observation Entry" / performer
|elgaimpf-dataelement-276
|- style="vertical-align:top;"
| style="padding-left: 30px" |ID der Organisation
|
|
|elgaimpf-dataelement-277
|- style="vertical-align:top;"
| style="padding-left: 30px" |Name der Organisation
|
|
|elgaimpf-dataelement-278
|- style="vertical-align:top;"
| style="padding-left: 30px" |Telekom
|Weitere Kontaktdaten (Telefon, Handy, Email...)
|
|elgaimpf-dataelement-279
|- style="vertical-align:top;"
| style="padding-left: 30px" |Adresse
|Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...)
|
|elgaimpf-dataelement-280
|- style="vertical-align:top;"
|'''Informationsquelle'''
|Herkunft der Information
|
|elgaimpf-dataelement-11
|}

[https://art-decor.org/decor/services/RetrieveDataSet?id=1.2.40.0.34.777.4.1.1&language=de-DE&effectiveDate=2018-08-12T16:37:15&format=html&hidecolumns=3456bcdefghijklmno Link zum Dataset in Art-Decor]

=Technische Spezifikation=
==Übersicht CDA Struktur "Kompletter Immunisierungsstatus"==
Die Struktur des CDA Austauschformats ist in den nachfolgenden Kapiteln im Detail beschrieben. Zum schnellen Einstieg findet sich hier eine stark vereinfachte Zusammenfassung der Elemente.
Dieses Dokument kann von der zentralen Anwendung "e-Impfpass" angefragt werden. Es enthält alle gespeicherten Informationen zum Immunisierungsstatus der Person und wird jeweils aktuell erzeugt ("On-Demand-Dokument").

ELGA Interoperabilitätsstufen (EIS): Dieses Dokument existiert ausschließlich in einer voll strukturierten Form, eine Unterscheidung der Interoperabilitätsstufen ist daher nicht notwendig.

[[Datei:DLT_Grafik_KompletterImmunisierungsstatus.PNG|400px|CDA-Dokument in Ausprägung "Kompletter Immunisierungsstatus"]]

<ref group="Abbildung">CDA-Dokument in Ausprägung "Kompletter Immunisierungsstatus"</ref>
<div class="landscape">
===CDA Header===
Der Header enthält die (administrativen) Dokument-Metadaten
* '''Allgemeine Dokumentinformationen:''' Dokumenten-Id, Code, Titel, Erstellungszeitpunkt, Sprache, Version
* '''"Impfling"''' Angaben zur Person (Patient), deren Immunisierungsstatus beschrieben wird: Name, Geburtsdatum, Geschlecht, Identifikatoren, Adresse und Kontaktdaten, ...
* '''Mitwirkende am Dokument''': Autoren, Schreibkraft, Verwalter, Unterzeichner
* '''Related Document:''' Verweis auf ein allfällig ersetztes Dokument (Vorversion)

Der Header entspricht im Wesentlichen den bisherigen ELGA-CDA-Leitfäden ("Allgemeiner Leitfaden"). Für den e-Impfpass wurden punktuell Neuerungen eingeführt:
* TemplateIds für die Versionskennung
* Zusätzliches Translation-Element für den clinicalDocument.code

'''Hinweis''': Einige Header-Elemente des Allgemeinen Leitfadens werden hier nicht benötigt [NP], sind aber der Vollständigkeit halber angegeben. [NP]-Elemente dürfen nicht angegeben werden, bzw. sind zu ignorieren.
Beispiele: Data Enterer, Authorization, LegalAuthenticator, ...

===CDA Body===
Der "Structured Body" enthält die tatsächlichen (medizinischen) Inhalte des Dokuments
* Kapitel '''Impfungen''': Sammlung der dokumentierten Impfungen
** Impfung, Impfdatum, Impfstoff, Impfschema und Dosiskennung, medizinisch verantwortliche Person, Krankheit gegen welche die Impfung schützt, PZN, Chargennummer (LOT-Nr), Dosierung und weitere Angaben zur Verabreichung (Teilnehmende Personen)
* Kapitel '''Personengruppe''': Dokumentiert die Zugehörigkeit zu speziellen Personengruppen.
** Personengruppe, Datumsbereich der Zugehörigkeit zur Gruppe
* Kapitel '''Impfrelevante Erkrankungen''': Sammlung der dokumentierten impfrelevanten Erkrankungen
** Erkrankung, Datumsbereich
* Kapitel '''Antikörper-Untersuchungen''': Sammlung der dokumentierten Antikörper-Bestimmungen
** Untersuchung, Wert, Bewertung, Datum
* Kapitel '''Impfempfehlungen''': Sammlung der dokumentierten Impfempfehlungen (automatisch erstellte sowie vom Impfarzt individuell empfohlene)
** Strukturell wie Impfungen, mit anderen Pflichtfeldern und anderem Status
* Kapitel '''Beilagen''': digitalisierter Papierimpfpass als Attachment

Anmerkung: Impfreaktionen werden nicht unterstützt.

==Übersicht CDA Struktur "Update Immunisierungsstatus"==
Die Struktur des CDA Austauschformats ist in den nachfolgenden Kapiteln im Detail beschrieben. Zum schnellen Einstieg findet sich hier eine stark vereinfachte Zusammenfassung der Elemente.

Dieses Dokument wird vom impfenden GDA erstellt und an die zentrale Applikation gesendet. Es enthält die Informationen, die der GDA bei einem Besuch dokumentiert. Es kann Impfungen, Impfempfehlungen, impfrelevante Erkrankungen, Antikörperbestimmungen, etc enthalten.

ELGA Interoperabilitätsstufen (EIS): Dieses Dokument existiert ausschließlich in einer voll strukturierten Form, eine Unterscheidung der Interoperabilitätsstufen ist daher nicht notwendig.

[[Datei:DLT_Grafik_UpdateImmunisierungsstatus.PNG|400px|CDA-Dokument in Ausprägung "Update Immunisierungsstatus"]]

<ref group="Abbildung">CDA-Dokument in Ausprägung "Update Immunisierungsstatus"</ref>

===CDA Header===
Der Header enthält die (administrativen) Dokument-Metadaten
* '''Allgemeine Dokumentinformationen:''' Dokumenten-Id, Code, Titel, Erstellungszeitpunkt, Sprache, Version
* '''"Impfling"''' Angaben zur Person (Patient), deren Immunisierungsstatus beschrieben wird: Name, Geburtsdatum, Geschlecht, Identifikatoren, Adresse und Kontaktdaten, ...
* '''Mitwirkende am Dokument''': Autoren, Erfasser, Verwalter, Unterzeichner
* '''Related Document:''' Verweis auf ein allfällig ersetztes Dokument (Vorversion)

Der Header entspricht im Wesentlichen den bisherigen ELGA-CDA-Leitfäden ("Allgemeiner Leitfaden"). Für den e-Impfpass wurden punktuell Neuerungen eingeführt:
* TemplateIds für die Versionskennung
* Zusätzliches Translation-Element für den clinicalDocument.code

===CDA Body===
Der "Structured Body" enthält die tatsächlichen (medizinischen) Inhalte des Dokuments
* Kapitel '''Impfungen''': Sammlung der dokumentierten Impfungen
** Impfung, Impfdatum, Impfstoff, Impfschema und Dosiskennung, medizinisch verantwortliche Person, Krankheit gegen welche die Impfung schützt, PZN, Chargennummer (LOT-Nr), Dosierung und weitere Angaben zur Verabreichung (Teilnehmende Personen)
* Kapitel '''Personengruppe''': Dokumentiert die Zugehörigkeit zu speziellen Personengruppen.
** Personengruppe, Datumsbereich der Zugehörigkeit zur Gruppe
* Kapitel '''Impfrelevante Erkrankungen''': Sammlung der dokumentierten impfrelevanten Erkrankungen
** Erkrankung, Datumsbereich
* Kapitel '''Antikörper-Bestimmungen''': Sammlung der dokumentierten Laboruntersuchungen der impfrelevanten Antikörper ("Impftiter")
** Untersuchung, Wert, Bewertung, Datum
* Kapitel '''Impfempfehlungen''': Vom Impfarzt individuell empfohlene Impfungstermine, wenn abweichend von den automatisch erstellten Impfempfehlungen
** Strukturell wie Impfungen, mit anderen Pflichtfeldern und anderem Status

Anmerkung: Impfreaktionen werden nicht unterstützt.

==Übersicht der Strukturen mit Konformität und Kardinalität==
Folgende Tabellen sollen einen groben Überblick über die Inhalte der einzelnen Sektionen geben. Details sind den entsprechenden Templates zu entnehmen.

===Sektion Impfungen - kodiert===
'''1. Dokumentation einer Impfung''':

*Kompletter Immunisierungsstatus: Impfung wird angezeigt.
*Update Immunisierungsstatus: Neue Impfung wird durchgeführt.
*Update Nachtrag Immunisierungsstatus: Nachtrag einer bereits durchgeführten Impfung.

''Anmerkung'': Entweder-Oder-Auswahlmöglichkeiten sind mit "#)" gekennzeichnet.

{| class="wikitable"
! colspan="3" style="width: 70%" |Sektion Impfungen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="3" |SECTION Impfungen - kodiert (1.2.40.0.34.6.0.11.2.1)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="2" |Immunization Entry (1.2.40.0.34.6.0.11.3.1)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
|#) Vaccine Product (1.2.40.0.34.6.0.11.9.32)
|C [0..1]
|M [1..1]
|C [0..1]
|-
|
|
|#) Vaccine Product nicht angegeben (1.2.40.0.34.6.0.11.9.31)
|C [0..1]
|NP [0..0]
|C [0..1]
|-
|
|
|Performer Body - Impfende Person (1.2.40.0.34.6.0.11.9.21) ''Impfende Person''
|C [0..1]
|C [0..1]
|O [0..1]
|-
|
|
|Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8) ''Medizinisch verantwortliche Person''
|C [0..1]
|M [1..1]
|O [0..1]
|-
|
|
|Informant Body (1.2.40.0.34.6.0.11.9.3) ''Bürger (bei Selbsteintragung)''
|C [0..1]
|C [0..1]
|NP [0..0]
|-
|
|
|Participant Body - Transcriber (1.2.40.0.34.6.0.11.9.14) ''Nachtragende Person''
|C [0..1]
|NP [0..0]
|M [1..1]
|-
|
|
|Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) ''Korrigierende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) ''Berechtigter Bearbeiter''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) ''Eintragende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|Immunization Target Entry (1.2.40.0.34.6.0.11.3.2)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
|Immunization Billability Entry (1.2.40.0.34.6.0.11.3.5)
|NP [0..0]
|O [0..1]
|NP [0..0]
|-
|
|
|Zusatzklassifikation (1.2.40.0.34.6.0.11.3.168) ''Impfsetting''
|R [0..*]
|R [0..*]
|R [0..*]
|-
|
|
|External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf zugrundeliegendes Update-Dokument''
|M [1..1]
|R [0..1]
|R [0..1]
|-
|
|
|External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf das Impfzertifikat''
|R [0..1]
|R [0..1]
|R [0..1]
|-
|
|
|Immunization Schedule Entry (1.2.40.0.34.6.0.11.3.10) ''Impfschema''
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="2" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|Author Body (1.2.40.0.34.6.0.11.9.36)
|R [0..*]
|R [0..*]
|R [0..*]
|-
|
|
|Informant Body (1.2.40.0.34.6.0.11.9.3)
|R [0..*]
|R [0..*]
|R [0..*]
|}

'''2.''' Es wird '''keine Impfung''' durchgeführt, sondern z.B. eine Krankheit eingetragen.

{| class="wikitable"
! colspan="3" style="width: 70%" |Sektion Impfungen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="3" |SECTION Impfungen - kodiert (1.2.40.0.34.6.0.11.2.1)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="2" |Immunization Entry Impfung nicht angegeben (1.2.40.0.34.6.0.11.3.28)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
|Vaccine Product nicht angegeben (1.2.40.0.34.6.0.11.9.31)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="2" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) ''(siehe Sektion Impfungen)''
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Expositionsrisiko Personengruppen - kodiert===
{| class="wikitable"
! colspan="4" style="width: 70%" |Sektion Expositionsrisiko Personengruppen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="4" |SECTION Expositionsrisiko Personengruppen - kodiert (1.2.40.0.34.6.0.11.2.4)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="3" |Expositionsrisiko Problem Concern Entry (1.2.40.0.34.6.0.11.3.20)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
| colspan="2" |Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
| colspan="2" |Expositionsrisiko Problem Entry (1.2.40.0.34.6.0.11.3.21)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
|
|Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) ''Korrigierende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
|Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) ''Berechtigter Bearbeiter''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
|Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) ''Eintragende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
| colspan="2" |External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf zugrundeliegendes Update-Dokument''
|M [1..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="3" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) ''(siehe Sektion Impfungen)''
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Impfrelevante Erkrankungen - kodiert===
{| class="wikitable"
! colspan="5" style="width: 70%" |Sektion Impfrelevante Erkrankungen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="5" |SECTION Impfrelevante Erkrankungen - kodiert (1.2.40.0.34.6.0.11.2.5)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="4" |Impfrelevante Erkrankungen Problem Concern Entry (1.2.40.0.34.6.0.11.3.8)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
| colspan="3" |Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
| colspan="3" |Impfrelevante Erkrankungen Problem Entry (1.2.40.0.34.6.0.11.3.9)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
|
| colspan="2" |Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) ''Korrigierende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
| colspan="2" |Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) ''Berechtigter Bearbeiter''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
| colspan="2" |Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) ''Eintragende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
| colspan="2" |Comment Entry (1.2.40.0.34.6.0.11.3.11)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
|
|
|Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|C [0..1]
|C [0..1]
|C [0..1]
|-
|
|
|
|
|Informant Body (1.2.40.0.34.6.0.11.9.3)
|C [0..1]
|C [0..1]
|C [0..1]
|-
|
|
| colspan="3" |External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf zugrundeliegendes Update-Dokument''
|M [1..1]
|R [0..1]
|R [0..1]
|-
|
|
| colspan="3" |External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf das Impfzertifikat''
|R [0..1]
|R [0..1]
|R [0..1]
|-
|
| colspan="4" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) ''(siehe Sektion Impfungen)''
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Antikörper-Bestimmung - kodiert===
{| class="wikitable"
! colspan="6" style="width: 70%" |Sektion Antikörper-Bestimmung
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="6" |SECTION Antikörper-Bestimmung - kodiert (1.2.40.0.34.6.0.11.2.7)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="5" |Antikörper-Bestimmung Data Processing Entry (1.2.40.0.34.6.0.11.3.15)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
| colspan="4" |Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
| colspan="4" |Antikörper-Bestimmung Battery Organizer (1.2.40.0.34.6.0.11.3.18)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
|
| colspan="3" |Antikörper-Bestimmung Laboratory Observation Entry (1.2.40.0.34.6.0.11.3.16)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|
|
| colspan="2" |Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) ''Korrigierende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
|
| colspan="2" |Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) ''Berechtigter Bearbeiter''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
|
| colspan="2" |Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) ''Eintragende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
|
| colspan="2" |Comment Entry (1.2.40.0.34.6.0.11.3.11) ''siehe Sektion Impfrelevante Erkrankungen''
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
|
|
| colspan="2" |Participant ''(Validierende Person)''
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
|
|
| colspan="2" |Performer Body - Laboratory (1.2.40.0.34.6.0.11.9.28) ''Externes Labor''
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
| colspan="4" |External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf zugrundeliegendes Update-Dokument''
|M [1..1]
|O [0..1]
|O [0..1]
|-
|
|
| colspan="4" |External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf das Impfzertifikat''
|R [0..1]
|R [0..1]
|R [0..1]
|-
|
| colspan="5" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) ''(siehe Sektion Impfungen)''
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Impfempfehlungen - kodiert===
{| class="wikitable"
! colspan="4" style="width: 70%" |Sektion Impfempfehlungen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="4" |SECTION Impfempfehlungen - kodiert (1.2.40.0.34.6.0.11.2.2)
|R [1..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="3" |Immunization Recommendation Entry (1.2.40.0.34.6.0.11.3.3)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
| colspan="2" |#) Vaccine Product (1.2.40.0.34.6.0.11.9.32)
|C [0..1]
|C [0..1]
|C [0..1]
|-
|
|
| colspan="2" |#) Vaccine Product nicht angegeben (1.2.40.0.34.6.0.11.9.31)
|C [0..1]
|C [0..1]
|C [0..1]
|-
|
|
| colspan="2" |Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8) ''Medizinisch verantwortliche Person''
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
| colspan="2" |Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) ''Korrigierende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
| colspan="2" |Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) ''Berechtigter Bearbeiter''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
| colspan="2" |Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) ''Eintragende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
| colspan="2" |Immunization Target Entry (1.2.40.0.34.6.0.11.3.2)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
| colspan="2" |Comment Entry (1.2.40.0.34.6.0.11.3.11) ''siehe Sektion Impfrelevante Erkrankungen''
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
| colspan="2" |Impfplan Entry (1.2.40.0.34.6.0.11.3.22)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
| colspan="2" |External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf zugrundeliegendes Update-Dokument''
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
| colspan="2" |Immunization Schedule Entry (1.2.40.0.34.6.0.11.3.10) ''Impfschema''
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="3" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) ''(siehe Sektion Impfungen)''
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Beilagen===
{| class="wikitable"
! colspan="3" style="width: 70%" |Sektion Beilagen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="3" |SECTION Beilagen (1.2.40.0.34.6.0.11.2.71)
|O [0..1]
|R [0..1]
|O [0..1]
|-
|
| colspan="2" |Eingebettetes Objekt Entry (1.2.40.0.34.6.0.11.3.19)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
|Author Body (1.2.40.0.34.6.0.11.9.36)
|C [0..1]
|C [0..1]
|C [0..1]
|-
|
|
|Informant Body (1.2.40.0.34.6.0.11.9.3)
|C [0..1]
|C [0..1]
|C [0..1]
|}

==CDA Templates==

===Document Level Templates===
====Kompletter Immunisierungsstatus====
{{:1.2.40.0.34.6.0.11.0.4/dynamic}}
====Update Immunisierungsstatus====
{{:1.2.40.0.34.6.0.11.0.2/dynamic}}

===Header Level Templates===
==== Document Realm ====
{{:1.2.40.0.34.6.0.11.1.10/dynamic}}
====Document TypeId====
{{:1.2.40.0.34.6.0.11.1.30/dynamic}}
==== Document Id ====
{{:1.2.40.0.34.6.0.11.1.1/dynamic}}
==== Document Effective Time ====
{{:1.2.40.0.34.6.0.11.1.11/dynamic}}
==== Document Confidentiality Code ====
{{:1.2.40.0.34.6.0.11.1.12/dynamic}}
==== Document Language ====
{{:1.2.40.0.34.6.0.11.1.13/dynamic}}
==== Document Set Id and Version Number ====
{{:1.2.40.0.34.6.0.11.1.15/dynamic}}
====Record Target - e-Impfpass====
{{:1.2.40.0.34.6.0.11.1.31/dynamic}}
====Author====
{{:1.2.40.0.34.6.0.11.1.2/dynamic}}
==== Data Enterer====
{{:1.2.40.0.34.6.0.11.1.22/dynamic}}
====Custodian====
{{:1.2.40.0.34.6.0.11.1.4/dynamic}}
====Legal Authenticator====
{{:1.2.40.0.34.6.0.11.1.5/dynamic}}
==== Information Recipient ====
Wird nicht verwendet.
====Participant ====
Folgende Participants werden nicht verwendet:
*Ein-, Ueber-, Zuweisender Arzt
*Hausarzt
*Auskunftsberechtigte Person (Notfallkontakt)
*Angehörige
*Versicherung
*Wird nicht verwendet.
*Betreuungsorganisation
*Weitere Behandler
====In Fulfillment Of ====
Wird nicht verwendet.
====Documentation Of Service Event - e-Impfpass ====
{{:1.2.40.0.34.6.0.11.1.32/dynamic}}

====Document Replacement - Related Document ====
{{:1.2.40.0.34.6.0.11.1.14/dynamic}}
====Authorization ====
Wird nicht verwendet.
====Component Of - Encompassing Encounter ====

{{:1.2.40.0.34.6.0.11.1.7/static-2019-03-07T104449}}

====Encounter Location====
{{:1.2.40.0.34.6.0.11.1.8/static-2019-03-07T111321}}

===Section Level Templates===
====Impfungen - kodiert====
{{:1.2.40.0.34.6.0.11.2.1/dynamic}}
====Expositionsrisiko Personengruppen - kodiert ====
{{:1.2.40.0.34.6.0.11.2.4/dynamic}}

====Impfrelevante Erkrankungen - kodiert====
{{:1.2.40.0.34.6.0.11.2.5/dynamic}}
====Antikörper-Bestimmung====
{{:1.2.40.0.34.6.0.11.2.7/dynamic}}
====Impfempfehlungen - kodiert====
{{:1.2.40.0.34.6.0.11.2.2/dynamic}}
====Beilagen====
{{:1.2.40.0.34.6.0.11.2.71/dynamic}}

====Übersetzung (informativ)====
{{:1.2.40.0.34.6.0.11.2.8/dynamic}}

===Entry Level Template===
====Antikörper-Bestimmung Battery Organizer====
{{:1.2.40.0.34.6.0.11.3.18/dynamic}}
====Antikörper-Bestimmung Data Processing Entry ====
{{:1.2.40.0.34.6.0.11.3.15/dynamic}}
====Antikörper-Bestimmung Laboratory Observation Entry ====
{{:1.2.40.0.34.6.0.11.3.16/dynamic}}
====Comment Entry====
{{:1.2.40.0.34.6.0.11.3.11/dynamic}}
====Eingebettetes Objekt Entry====
{{:1.2.40.0.34.6.0.11.3.19/dynamic}}
==== Expositionsrisiko Problem Concern Entry====
{{:1.2.40.0.34.6.0.11.3.20/dynamic}}
==== Expositionsrisiko Problem Entry====
{{:1.2.40.0.34.6.0.11.3.21/dynamic}}
====External Document Entry ====
{{:1.2.40.0.34.6.0.11.3.14/dynamic}}
====Immunization Billability Entry ====
{{:1.2.40.0.34.6.0.11.3.5/dynamic}}
====Immunization Entry====
{{:1.2.40.0.34.6.0.11.3.1/dynamic}}
====Immunization Entry Impfung nicht angegeben====
{{:1.2.40.0.34.6.0.11.3.28/dynamic}}
====Immunization Recommendation Entry ====
{{:1.2.40.0.34.6.0.11.3.3/dynamic}}
====Immunization Schedule Entry ====
{{:1.2.40.0.34.6.0.11.3.10/dynamic}}
====Immunization Target Entry====
{{:1.2.40.0.34.6.0.11.3.2/dynamic}}
====Impfplan Entry====
{{:1.2.40.0.34.6.0.11.3.22/dynamic}}
====Impfrelevante Erkrankungen Problem Concern Entry ====
{{:1.2.40.0.34.6.0.11.3.8/dynamic}}
====Impfrelevante Erkrankungen Problem Entry====
{{:1.2.40.0.34.6.0.11.3.9/dynamic}}
====Vaccine Product ====
{{:1.2.40.0.34.6.0.11.9.32/dynamic}}
====Vaccine Product nicht angegeben ====
{{:1.2.40.0.34.6.0.11.9.31/dynamic}}
====Zusatzklassifikation (für Impfungen)====
{{:1.2.40.0.34.6.0.11.3.168/dynamic}}

===Weitere CDA Fragmente ===
====Address Compilation====
{{:1.2.40.0.34.6.0.11.9.25/dynamic}}
====Address Compilation Minimal====
{{:1.2.40.0.34.6.0.11.9.10/dynamic}}
====Assigned Entity====
{{:1.2.40.0.34.6.0.11.9.22/dynamic}}
====Assigned Entity Body====
{{:1.2.40.0.34.6.0.11.9.16/dynamic}}
====Assigned Entity Body with name, addr and telecom====
{{:1.2.40.0.34.6.0.11.9.29/dynamic}}
====Author Body ====
{{:1.2.40.0.34.6.0.11.9.36/dynamic}}
====Author Body - eImpfpass====
{{:1.2.40.0.34.6.0.11.9.8/dynamic}}
====Date Interval Information minimal====
{{:1.2.40.0.34.6.0.11.9.35/dynamic}}
====Device Compilation====
{{:1.2.40.0.34.6.0.11.9.18/dynamic}}
====Informant Body====
{{:1.2.40.0.34.6.0.11.9.3/dynamic}}
====Narrative Text Reference====
{{:1.2.40.0.34.6.0.11.9.1/dynamic}}
====Organization Compilation with id, name====
{{:1.2.40.0.34.6.0.11.9.5/dynamic}}
====Organization Compilation with id, name, tel, addr====
{{:1.2.40.0.34.6.0.11.9.7/dynamic}}
====Organization Compilation with name====
{{:1.2.40.0.34.6.0.11.9.9/dynamic}}
====Organization Compilation with name, addr minimal ====
{{:1.2.40.0.34.6.0.11.9.20/dynamic}}
====Organization Name Compilation ====
{{:1.2.40.0.34.6.0.11.9.27/dynamic}}
====Original Text Reference====
{{:1.2.40.0.34.6.0.11.9.2/dynamic}}
====Participant Body====
{{:1.2.40.0.34.6.0.11.9.13/dynamic}}
====Participant Body - Transcriber ====
{{:1.2.40.0.34.6.0.11.9.14/dynamic}}
====Participant Body - Verifier ====
{{:1.2.40.0.34.6.0.11.9.44/dynamic}}
====Participant Body - Authorized Editor====
{{:1.2.40.0.34.6.0.11.9.46/dynamic}}

====Participant Body - Data Enterer====
{{:1.2.40.0.34.6.0.11.9.47/dynamic}}

====Performer Body====
{{:1.2.40.0.34.6.0.11.9.17/dynamic}}
====Performer Body - Impfende Person====
{{:1.2.40.0.34.6.0.11.9.21/dynamic}}
====Performer Body - Laboratory====
{{:1.2.40.0.34.6.0.11.9.28/dynamic}}
====Person Name Compilation G1====
{{:1.2.40.0.34.6.0.11.9.26/dynamic}}
====Person Name Compilation G1 M====
{{:1.2.40.0.34.6.0.11.9.12/dynamic}}
====Person Name Compilation G2====
{{:1.2.40.0.34.6.0.11.9.6/dynamic}}
====Person Name Compilation G2 M====
{{:1.2.40.0.34.6.0.11.9.11/dynamic}}
====Time Interval Information minimal====
{{:1.2.40.0.34.6.0.11.9.15/dynamic}}

</div class="landscape">

==Terminologien==
Die für den kompletten Immunisierungsstatus und für das Update erforderlichen Terminologien sind im Folgenden aufgelistet. Achtung: Codelisten und Value Sets können weitere Attribute benötigen, die hier nicht darstellbar sind. Diese können jedoch vom Terminologieserver abgerufen werden: https://termpub.gesundheit.gv.at

* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=2.16.840.1.113883.1.11.20025 ActStatusCompleted]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.10 atcdabbr_LanguageCode]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.11 atcdabbr_LanguageCode]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.13 eImpf_Antikoerperbestimmung_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.10 eImpf_HistorischeImpfstoffe_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.4 eImpf_ImmunizationTarget_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.6 eImpf_Impfdosis_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.7 eImpf_Impfgrund_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.2 eImpf_ImpfrelevanteErkankungen_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.11 eImpf_Impfrollen_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.5 eImpf_Impfschema_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.14 eImpf_Impfstoffe_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.3 eImpf_SpecialCaseVaccination_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.15 eImpf_SpecialSituationIndication_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.62 eImpf_Zusatzklassifikation_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.5 ELGA_ActEncounterCode]
* [https://art-decor.org/art-decor/decor-valuesets--elga-?id=1.2.40.0.34.10.16 ELGA_AddressUse]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.4 ELGA_AdministrativeGender ]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.6 ELGA_AuthorSpeciality]
* [https://art-decor.org/art-decor/decor-valuesets--elgabbr-?id=1.2.40.0.34.10.39 ELGA_Dokumentenklassen]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elga-?id=1.2.40.0.34.10.27 ELGA_EntityNameUse]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.173 ELGA_HumanLanguage]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.42 ELGA_Medientyp]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.32 ELGA_MedikationMengenart_VS]
**Gültige UCUM-Einheit, siehe Terminologieserver. Beispiele:
*** <nowiki>{Stueck}</nowiki> oder <nowiki>{Packung}</nowiki> - vollständige Verabreichung einer Fertigspritze
*** <nowiki>ml</nowiki> - für eine abweichende Dosis angegeben in Volumseinheiten
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ ]
* [https://art-decor.org/art-decor/decor-valuesets--elga-?id=1.2.40.0.34.10.2 ELGA_NullFlavor]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.13 ELGA_ObservationInterpretation]
**Für die Antikörperbestimmung (Impftiter) im e-Impfpass kommen die Werte aus dem Knoten ''_ObservationInterpretationDetection'' zum Einsatz.
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.17 ELGA_PersonalRelationship]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.43 ELGA_ServiceEventPerformer]
* [https://art-decor.org/art-decor/decor-valuesets--elga-?id=1.2.40.0.34.10.36 ELGA_TelecomAddressUse]
* [https://art-decor.org/art-decor/decor-valuesets--elga-?id=1.2.40.0.34.10.25 ELGA_URLScheme]
* [https://art-decor.org/art-decor/decor-valuesets--elga-?id=1.2.40.0.34.10.73 ELGA_whoATC]
* ELGA_Wirkstoffe_AGES_VS
**Siehe Terminologieserver
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=2.16.840.1.113883.1.11.16040 EntityCode]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=2.16.840.1.113883.1.11.10901 ParticipationType]

<div class="portrait">

=Anhang=
==Abbildungen==
<references group="Abbildung"/>
==Tabellen==
<references group="Tabelle" />
==Abkürzungsverzeichnis==
{{ILF:Abkuerzungsverzeichnis}}

==Literaturverzeichnis==
<references />
</div>

==Revisionsliste==
===Nebenversionen===

==== Nebenversion x.y.z+2022mmdd ====

===== 5 Begriffsdefinitionen =====
Zeile "Persönlicher e-Impfpass", "Zulassungsname" in der Definition ergänzt.

===== 10.1 Dataset =====
elgaimpf-dataelement-31, Name und Beschreibung korrigiert von "Handelsname" zu "Zulassungsname". Beispiele ebenfalls korrigiert.

===== Vaccine Product 1.2.40.0.34.6.0.11.9.32 =====
Klarstellung der möglichen Verwendung des "Handelsnamens" einer Arznei in manufacturedProduct/manufacturedMaterial/code/@displayName

Klarstellung der möglichen Verwendung des "Zulassungsnamens" einer Arznei in manufacturedProduct/manufacturedMaterial/name

Beispiel-Snippets entsprechend angepasst.

====Nebenversion 1.3.0+20220127====
=====Participant Body - Data Enterer 1.2.40.0.34.6.0.11.9.47=====
Das Template "Participant Body - Data Enterer" wurde erstellt, damit der Data Enterer aus dem Update Immunisierungsstatus im Kompletten Immunisierungsstatus in die Entries (Immunization Entry, Immunization Recommendation Entry, Impfrelevante Erkrankungen Problem Entry) übernommen werden kann.
=====Expositionsrisiko Problem Entry 1.2.40.0.34.6.0.11.3.21=====
Dem Entry wurden die Participants "Participant Body - Verifier" (1.2.40.0.34.6.0.11.9.44), "Participant Body - Authorized Editor" (1.2.40.0.34.6.0.11.9.46) und "Participant Body - Data Enterer" (1.2.40.0.34.6.0.11.9.47) hinzugefügt.
=====Antikörper-Bestimmung Laboratory Observation Entry 1.2.40.0.34.6.0.11.3.16=====
Dem Entry wurde der Participants "Participant Body - Data Enterer" (1.2.40.0.34.6.0.11.9.47) hinzugefügt.

====Nebenversion 1.2.0+20220103====
======DLT Kompletter Immunisierungsstatus 1.2.40.0.34.6.0.11.0.4======
Anpassungen betreffend neuem Anwendungsfall U2.5 "Selbsteintragung von Impfungen durch den Bürger":

*neue Sektion Beilagen 0..1 ergänzt

=====DLT Update Immunisierungsstatus 1.2.40.0.34.6.0.11.0.2=====
Ergänzung von Constraints betreffend neuem Anwendungsfall U2.5 "Selbsteintragung von Impfungen durch den Bürger":

*Author: Bei Selbsteintragung wird die Software als Author angegeben
*DataEnterer: Änderung von 0..1 auf 0..1 C + Constraint: Bei Selbsteintragung muss der Bürger als DataEnterer angegeben werden
*neue Sektion Beilagen 0..1 + Constraint: Bei Selbsteintragung muss der Bürger als Informant angegeben werden
*folgende Sektionen wurden von 0..1 auf 0..1 C gesetzt + Constraint (Bei Selbsteintragung sind die Sektionen verboten):
**Expositionsrisiko Personengruppen
**Impfrelevante Erkrankungen
**Antikörper-Bestimmung
**Impfempfehlungen

=====Immunization Recommendation Entry 1.2.40.0.34.6.0.11.3.3=====
Angabe von Kontraindikationen ermöglicht (Empfehlung, keine Impfung durchzuführen). Wird im Update Immunisierungsstatus mit @negationInd="true" angezeigt. Im Kompletten Immunisierungsstatus wird eine entsprechender Code für eine Handlungsempfehlung automatisch hinzugefügt.

=====Performer Body - Impfende Person 1.2.40.0.34.6.0.11.9.21=====
Template-Beschreibung angepasst

====='''Author 1.2.40.0.34.6.0.11.1.2'''=====
Erweiterung des Constraints, sodass wenn Author ein/e Software/Gerät ist und keine OID aus dem GDA-I angegeben werden kann, die Angaben der Organisation des Geräte-/Software-Betreibers oder Herstellers entsprechen müssen.

=====Participant Body - Verifier 1.2.40.0.34.6.0.11.9.44=====
"Korrigierende Person" neu hinzugefügt

=====Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46)=====
''Berechtigter Bearbeiter'' neu hinzugefügt

=====Participant Body - Transcriber 1.2.40.0.34.6.0.11.9.14=====
Angabe der Organisation als scopingEntity.desc für Transcriber ermöglicht

=====Informant Body 1.2.40.0.34.6.0.11.9.3=====

*informant/relatedEntity/ @classCode ergänzt: 1..1 F "PRS"
*Beispiel korrigiert

=====Vaccine Product 1.2.40.0.34.6.0.11.9.32=====

*code/@nullFlavor-Assert zusätzlich als narrativer Constraint formuliert
*translation/@displayname 0..1 (Zulassungsname) ergänzt
*Beispielkorrektur

=====Impfrelevante Erkrankungen Problem Concern Entry 1.2.40.0.34.6.0.11.3.8=====
author von 0..1 C auf 1..1 R gesetzt, Constraint angepasst

=====Impfrelevante Erkrankungen Problem Entry1.2.40.0.34.6.0.11.3.9=====

*Anpassung: Es wird nur ein 0..1 Comment Entry mit 0..1 Author den Kompletten Immunisierungsstatus übernommen.
*Korrigierende Person 0..1 C ergänzt

=====Immunization Entry 1.2.40.0.34.6.0.11.3.1=====

*Informant wurde 0..1 C eingefügt, Constraint ergänzt (bei Selbsteintragung Informant verpflichtend, sonst NP)
*Anpassung Constraint Author: Bei Selbsteintragung und Update (ohne Nachtrag): Author 1..1 M
*Anpassung Constraint participant Transcriber: Bei Selbsteintragung Transcriber verboten (NP)
*Korrigierende Person 0..1 C ergänzt
*Zusatzklassifikation: Constraint entfernt
*/doseQuantity: Korrektur der Beschreibung zur Mengenangabe der verabreichten Arzneispezialität

=====Immunization Recommendation Entry 1.2.40.0.34.6.0.11.3.3=====

*Anpassung: Es wird nur ein 0..1 Comment Entry mit 0..1 Author in den Kompletten Immunisierungsstatus übernommen.
*Korrigierende Person 0..1 C ergänzt

=====Immunization Schedule Entry 1.2.40.0.34.6.0.11.3.10=====

*Bezeichnung "Impfkonzept" ersetzt durch "Impfschema", Beispielkorrektur Dosis,
*value-Constraint bezüglich Selbsteintragung angepasst.

=====Immunization Target Entry 1.2.40.0.34.6.0.11.3.2=====
Beispielkorrektur

=====Expositionsrisiko Problem Entry 1.2.40.0.34.6.0.11.3.21=====
Beispielkorrektur

=====Expositionsrisiko Problem Concern Entry 1.2.40.0.34.6.0.11.3.20=====
Anpassung author von 0..1 C auf 1..1 M

=====Antikörper-Bestimmung Laboratory Observation Entry 1.2.40.0.34.6.0.11.3.16=====

*Anpassung: Es wird nur ein 0..1 Comment Entry mit 0..1 Author den Kompletten Immunisierungsstatus übernommen.
*Korrigierende Person 0..1 C ergänzt
*Beispiel hinzugefügt, wie ein Testname und Testhersteller für einen Antikörpertest angegeben werden können
*code/@codeSystemName ist nicht mehr verpflichtend anzugeben

=====Beilagen 1.2.40.0.34.6.0.11.2.71=====
Selbsteintragung durch Bürger: Sektion für Multimedia-Attachments hinzugefügt.

=====Leitfaden diverse Kapitel=====

*3.1 Verbindlichkeit: Ergänzung von Hinweisen auf EU-Recht u. GTelG
*3.1. und 9.1 Übersicht über vorhandene Akteure und Komponenten: Hinweise auf Pilotprojekt entfernt
*8.4. Impfempfehlungen: Ergänzung Hinweis für individuelle Impfempfehlungen und Definition "Handlungsempfehlung"
*8.4.1. Sonderform: Empfehlung, keine Impfung durchzuführen (Kontraindikation)
*9 User Storys ("Anwendungsfälle"): U2.2 "Korrektur eines Immunisierungseintrags" und U4 "Datenkorrektur durch Behörde" verbessert, Selbsteintragung durch

Bürger: U2.5 "Selbsteintragung von Impfungen durch den Bürger" hinzugefügt.

*5 Begriffsdefinitionen
**Korrektur "Kostenloses Kinderimpfkonzepte" in "Kostenfreies Kinderimpfprogramm"
**"Hersteller" - eine Definition des Herstellers (Zulassungsinhabers) von Impfstoffen wurde hinzugefügt.
**"Nachtragende Person" - die Definition der nachtragenden Person wurde verbessert.
*10 Datenarten:
**"Reaktion" auf den korrekten Platz bei Impfung verschoben und zur Verdeutlichung in "Impfreaktion" umbenannt.
**"Korrigierende Person" hinzugefügt
**"Berechtigter Bearbeiter" hinzugefügt
*11.3 Übersicht der Strukturen mit Konformität und Kardinalität: Korrekturen Kardinalität/Konformität
*11.5 Terminologien: Value Sets werden nur noch verlinkt
*12.4 Literaturverzeichnis: Defekte Links korrigiert

====Nebenversion 1.1.1+20210601====
{| class="wikitable"
|Schlüssel
|Zusammenfassung
|<nowiki>Typ</nowiki>
|-
|
|"Begriffsdefinition Nachtragende Person" - die Definition der nachtragenden Person wurde verbessert.
|Verbesserung
|-
|
|"Begriffsdefinition Hersteller" - eine Definition des Herstellers (Zulassungsinhabers) von Impfstoffen wurde hinzugefügt.
|Verbesserung
|-
|
|"11.4.4.17 Antikörper-Bestimmung Laboratory Observation Entry" - Beispiel hinzugefügt, wie ein Testname und Testhersteller für einen Antikörpertest angegeben werden können.
|Verbesserung
|}

====Nebenversion 1.1.0+20210512====
{| class="wikitable"
|Schlüssel
|Zusammenfassung
|<nowiki>Typ</nowiki>
|-
|ELGA-1100
|"Zusatzklassifikation" (1.2.40.0.34.6.0.11.3.168) / : Optionale Zusatzklassifikation einer Impfung für Aufnahme von "Impfsetting" etc hinzugefügt
|Verbesserung
|-
|ELGA-1024
|"Immunization Entry" (1.2.40.0.34.6.0.11.3.1) / : Präzision der Datumsangabe bei Impfungen - nur Nachtragungen können mit unscharfen Datumsangaben eingetragen werden
|Verbesserung
|-
|ELGA-1082
|Dataset Impfgrund / : Impfindikation=Impfgrund für Abrechnung - Beschreibung verbessert
|Verbesserung
|-
|ELGA-827
|"Immunization Recommendation Entry" (1.2.40.0.34.6.0.11.3.3) / : Impfempfehlung: Die zu verabreichende Dosis (Menge) kann nun bei der Empfehlung angegeben werden.
|Verbesserung
|-
|ELGA-734
|Referenz für Impfzertifikat, Genesungs- und Testzertifikat (1.2.40.0.34.6.0.11.3.14) / : Optional kann nun auch ein Internet-Link auf ein extern gespeichertes Zertifikat (PDF-Dokument) mit gespeichert werden
|Verbesserung
|-
|
|Verbesserungen von Beschreibungen: Definition "Nachtragen", "Impfort", Laboratory Observation observation/referenceRange
|Verbesserung
|-
|ELGA-734
|"External Document Entry" (1.2.40.0.34.6.0.11.3.14) / Dokumentenklassifikation: Einschränkung auf LOINC entfernt
|Verbesserung
|-
|ELGA-728
|"Informant Body" (1.2.40.0.34.6.0.11.9.3): addr: Ergänzung Compilation, telecom: Attribute, Ergänzung Value Sets und Constraint
|Verbesserung
|-
|ELGA-724
|"Immunization Recommendation Entry" ([[#Immunization_Recommendation_Entry|1.2.40.0.34.6.0.11.3.3]]): Kardinalität von Comment Entry (1.2.40.0.34.6.0.11.3.11) von 0..1 auf 0..* korrigiert, da mehrfach benötigt
|Fehler
|-
|ELGA-719
|In der Impfempfehlungslogik werden nicht einzelne Handelsprodukte mit PZN vorgeschlagen, sondern die Zulassungsnummer.

Es ist daher notwendig, dass es eine Möglichkeit gibt, die Zulassungsnummer alleine im Template "Vaccine Product" (1.2.40.0.34.6.0.11.9.32) anzugeben:

/code mit der PZN von [M] zu [R] geändert, dabei MUSS NullFlavor="OTH" angeführt sein.

/code/translation darf mehrfach vorkommen und trägt die Zulassungsnummer.

|Fehler
|-
|ELGA-717
|"Immunization Recommendation Entry" (1.2.40.0.34.6.0.11.3.3): Optionalität von code/@displayName und code/@codeSystemName
entspricht den Datentyp-Vorgaben für CD und wird daher nicht redundant modelliert. Daher entfernt.
|Verbesserung
|-
|ELGA-716
|Beschreibung, dass passive Immunisierung und "Allergieimpfungen" nicht unterstützt werden, wurde hinzugefügt
|Verbesserung
|-
|ELGA-715
|"Antikörper-Bestimmung Laboratory Observation Entry" (1.2.40.0.34.6.0.11.3.16): ReferenceRange Datentyp geändert
|Fehler
|-
|
|Kapitel "Wichtige unterstützende Materialien" wurde umbenannt in "Wichtige unterstützende Materialien" und ergänzt mit Link zu Beispielbefunden, Schematron-Prüfregeln, PDF-Version des Leitfadens
|Verbesserung
|-
|
|Dataset-Elemente des Headers wurden in den Templates referenziert/gemappt (rein informativ).
|Verbesserung
|-
|
|"Expositionsrisiko Personengruppen - kodiert" (1.2.40.0.34.6.0.11.2.4):
- ID der Sektion: Kardinalität von 0..* auf 0..1 geändert

- Titel der Sektion wurde von "Expositionsrisiko - Personengruppen" auf "Spezielle Impfindikation" geändert
|Fehler
|-
|
|"Impfrelevante Erkrankungen - kodiert" (1.2.40.0.34.6.0.11.2.5) / id: Kardinalität von 0..* auf 0..1 geändert
|Fehler
|-
|
|"Übersetzung (informativ)" (1.2.40.0.34.6.0.11.2.8): Containment "Author Body - eImpfpass" (1.2.40.0.34.6.0.11.9.8) geändert auf "Author Body" (1.2.40.0.34.6.0.11.9.36), "Author Body" im Leitfaden ergänzt
|Fehler
|-
|
|"Address Compilation" (1.2.40.0.34.6.0.11.9.25) und Address Compilation Minimal (1.2.40.0.34.6.0.11.9.10): Änderung streetAddressLine, streetName, houseNumber von 0..1 R auf 0..1 C, Constraint ergänzt
|Verbesserung
|-
|
|Schamatron Prüfregeln wurden in einigen Templates ergänzt. Diese waren aber bereits in entsprechenden Constraints beschrieben
|Verbesserung
|-
|
|Kapitel "Revisionsliste" ergänzt
|Verbesserung
|-
|
|"Immunization Schedule Entry" (1.2.40.0.34.6.0.11.3.10): Constraint angepasst
|Verbesserung
|-
|
|"Immunization Target Entry" (1.2.40.0.34.6.0.11.3.2): @codeSystem von 1..1 F 2.16.840.1.113883.6.96 auf 1..1 R geändert, @codeSystemName fixer Wert entfernt
|Verbesserung
|-
|
|"6.1.2 Legende der Konformitätskriterien (Optionalität)" Verbesserte Beschreibung.
|Verbesserung
|-
|
|"9.6 U4 Datenkorrektur durch Behörde" - Wording angepasst um keinen physischen Amtsweg zu implizieren, "Bezirksverwaltungsbehörde" statt "Bezirkshauptmannschaft".
|Verbesserung
|}

ILF:E-Impfpass

2022-07-12T07:05:23Z

Kuttin: /* Dataset */

{{#seo:
|title=e-Impfpass
|titlemode=append
|keywords= e-Impfpass
|description=Der e-Impfpass definiert einen technischen und semantischen Standard für den elektronischen und strukturierten Austausch von Impfungen und Daten zur Immunisierungsstatus einer Person.
}}
{{#customtitle:e-Impfpass}}



{{#css:
@media Screen{
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.toc{
width: 20%;
float: right !important;
margin: 10px 0px 10px 30px !important;
border: 1px solid #AAA;
background-color: #F9F9F9;
display: table;
padding: 7px !important;
}
}
}}



{{Infobox Dokument
|Group = CDA Implementierungsleitfaden
|Title = HL7 Implementation Guide for CDA® R2: e-Impfpass (Version 1)
|Subtitle = Zur Anwendung im österreichischen Gesundheitswesen [1.2.40.0.34.7.19.1]
|Short = e-Impfpass
|Namespace = ILF
|Type = Implementierungsleitfaden
|Version = 1.3.0+20220127
|Submitted = ELGA GmbH
|Date = 2022-01-27
|Copyright = © HL7 Austria 2018-2022
|Status = Finale Version (normative Nebenversion)
|Verfahren = Normativ
|Period = Produktiveinsatz
|OID = 1.2.40.0.34.7.19.1
|Realm = Österreich
}}
{{TOC limit|5}}


=Zusammenfassung=
{{BeginYellowBox}}
Dieser Leitfaden beschreibt die Datenaustauschformate für den [https://www.elga.gv.at/e-impfpass/e-impfpass/index.html e-Impfpass] in Österreich.

Die Grundlage der Datenaustauschformate ist der internationale [[CDA-Grundlagen|CDA-Standard]], der sich in ELGA bereits bewährt hat. Er erlaubt es Sender und Empfänger, sich ohne vorherige Absprache zu verstehen. Als Basisspezifikation wurde das "Immunization Content (IC)" Inhaltsprofil aus dem IHE Technical Framework "Patient Care Coordination (PCC)" ausgewählt, das auch im Schweizerischen [http://e-health-wiki.ch/index.php/CDA-CH-VACD_(project) eImpfdossier] <ref name=ImpfdossierCH>Elektronisches Impf- und Immunschutzdossier der Schweiz [Online 2019]. http://e-health-wiki.ch/index.php/Ehscda:CDA-CH-VACD_(specification)</ref> verwendet wird.

Als Datenaustauschformate dienen zwei unterschiedliche CDA-Dokument-Templates:

* '''[[ILF:E-Impfpass#.C3.9Cbersicht_CDA_Struktur_.22Kompletter_Immunisierungsstatus.22|Kompletter Immunisierungsstatus]]''': Das von der zentralen Anwendung abrufbare Datenaustauschformat. Es enthält alle verfügbaren Informationen zum Immunisierungsstatus einer Person (Impfungen, impfrelevante Erkrankungen, Antikörper-Bestimmungen) und Impfempfehlungen.
* '''[[ILF:E-Impfpass#.C3.9Cbersicht_CDA_Struktur_.22Update_Immunisierungsstatus.22|Update Immunisierungsstatus]]''': Das Datenaustauschformat, das an die zentrale Anwendung gesendet wird, um Änderungen am Immunisierungsstatus einer Person zu dokumentieren (Impfungen, impfrelevante Erkrankungen, Antikörper-Bestimmungen) sowie individuell angepasste Impfempfehlungen, die durch den impfenden Arzt festgelegt werden.

Die Notation der Spezifikation der Datenaustauschformate folgt der "Art-Decor"-Schreibweise, die auf einer eigenen Seite ([[Hilfe:Art-Decor-Tabellen_verstehen|Art-Decor-Tabellen verstehen]]) erläutert wird.

Der vorgesehene Ablauf des Datenaustausches wird im Kapitel [[ILF:E-Impfpass#Anwendungsf.C3.A4lle|Anwendungsfälle]] beschrieben.
{{EndYellowBox}}

{{BeginYellowBox}}
Die gesetzliche Grundlage für den e-Impfpass ist das Gesundheitstelematikgesetz (GTelG 5. Abschnitt: eHealth-Anwendungen, 2. Unterabschnitt: § 24b bis § 24g) und die zugehörige eHealth-Verordnung (eHealthV 2020). 
Dieser Leitfaden ist ein nationaler HL7©-Standard, der technisch und inhaltlich im Rahmen des Abstimmungsverfahrens 2019-1 ("Ballot") normiert wurde.
Kommentare zu diesem Leitfaden können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden.
{{EndYellowBox}}
<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">


==Impressum==
<div class="mw-collapsible-content">
''Medieneigentümer, Herausgeber, Hersteller, Verleger:'' 
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: 01. 2127050. 
Internet: [http://www.elga.gv.at www.elga.gv.at]
Email: [mailto:cda@elga.gv.at cda@elga.gv.at]. 
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch

''Redaktion, Projektleitung, Koordination: '' 
Mag. Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]

''Abbildungen:'' © ELGA GmbH

''Nutzung'': Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria, Franckstrasse 41/5/14, 8010 Graz; [http://www.hl7.at www.hl7.at]. 
Die Nutzung ist zum Zweck der Erstellung medizinischer Dokumente ohne Lizenz- und Nutzungsgebühren ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter [https://www.gesundheit.gv.at www.gesundheit.gv.at] und [https://www.elga.gv.at/cda www.elga.gv.at/cda]
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">
== Haftungsausschluss ==
<div class="mw-collapsible-content">
Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht. Die ELGA GmbH weist ausdrücklich darauf hin, dass es sich bei dem vorliegenden Leitfaden um unverbindliche Arbeitsergebnisse handelt, die zur Anwendung empfohlen werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls unerwünscht und von den Erstellern des Dokumentes nicht beabsichtigt.

Die Nutzung des vorliegenden Leitfadens erfolgt in ausschließlicher Verantwortung der Anwender. Aus der Verwendung des vorliegenden Leitfadens können keinerlei Rechtsansprüche gegen die ELGA GmbH erhoben und/oder abgeleitet werden.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">
== Sprachliche Gleichbehandlung ==
<div class="mw-collapsible-content">
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer und Frauen in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
</div></div>

{{ILF:Lizenzinformationen}}

<div class="toccolours mw-collapsible mw-collapsed" style="width:50%; overflow:auto;">
==PDF-Bedienungshinweise==
<div class="mw-collapsible-content">
Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

* Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
* Seitenweise blättern: "Bild" Tasten
* Scrollen: Pfeil nach oben bzw. unten
* Zoomen: Strg + Mouserad drehen
* Suchen im Dokument: Strg + F
</div></div>



=Einleitung=
==Ausgangslage und Motivation==
Im österreichischen Impfwesen wird der papierbasierte Impfpass als zentrales Instrument für die Dokumentation und den Nachweis von Impfungen verwendet. Obwohl sich der papierbasierte Impfpass über viele Jahre bewährt hat, so erfüllt er nicht mehr die Anforderungen an ein modernes Gesundheitsvorsorgeinstrument. Der Papierimpfpass geht oft verloren, die teilweise handschriftlichen Aufzeichnungen sind schwierig zu entziffern und nicht vollständig bzw. über mehrere Impfpässe verteilt. Hier soll der e-Impfpass ansetzen und valide und übersichtliche Daten schaffen. Zudem sollen auf Basis des nationalen Impfplans persönliche Impfempfehlungen ausgegeben werden.
Auf Beschluss der Bundeszielsteuerungskommission wurde daher die Umsetzung der Pilotierung des elektronischen Impfpasses (e-Impfpass) durch die ELGA GmbH beschlossen.
Mit dem Ziel einer optimierten Impfversorgung der österreichischen Bevölkerung ist der Impfausweis der Zukunft ein elektronisches Dokument (e-Impfpass). Um den Austausch dieser Informationen zwischen allen beteiligten Institutionen und Personen zu unterstützen, muss ein einheitliches Austauschformat geschaffen und definiert werden, welches in diesem Dokument beschrieben wird.

==Zweck des Dokuments==
Das vorliegende Dokument beschreibt die einheitlichen Austauschformate und Inhalte für den Informationsaustausch für den "e-Impfpass" für das Österreichische Gesundheitswesen. Diese Spezifikation ist das Resultat einer Harmonisierungsarbeit mit dem Ziel, Impfeinträge innerhalb der österreichischen "Elektronischen Gesundheitsakte" (ELGA) als abgestimmte und einheitlich strukturierte Dokumente darzustellen. Der vorliegende Implementierungsleitfaden beinhaltet daher Spezifikationen für die semantische Interoperabilität von Systemen rund um den e-Impfpass inkl. der elektronische Anfragen von Impfempfehlungen.
Die Grundlage der Datenaustauschformate ist der internationale CDA-Standard, der sich in ELGA bereits bewährt hat. Als Basisspezifikation wurde das "Immunization Content (IC)" Inhaltsprofil aus dem IHE Technical Framework "Patient Care Coordination (PCC)" ausgewählt, das auch im Schweizerischen eImpfdossier verwendet wird. Das vorliegende Dokument wurde von einer Arbeitsgruppe von Vertretern des Gesundheitswesens, der Wissenschaft und der Wirtschaft sowie von der Health Level 7 (HL7) Anwendergruppe Österreich erstellt. Der Leitfaden basiert auf den vorangegangenen Erfahrungen in der Erstellung von Implementierungsleitfäden für ELGA CDA Dokumente. Die Header enthalten zum einen administrative Daten (allgemeine Angaben zum Dokument, Daten zum Patienten, usw.) und dienen zum anderen auch als Quelle für die Metadaten, die bei der Registrierung des Dokuments in ELGA verwendet werden. Der Header orientiert sich am bestehenden "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente", enthält aber Verallgemeinerungen, da es sich um ein e-Health-Dokument und nicht um ein ELGA-Dokument handelt. Die medizinisch relevanten Anteile zur Erfassung des Immunisierungsstatus sind im so genannten "Body" enthalten.

==Zielgruppe==
Anwender dieses Dokuments sind Softwareentwickler und Berater, die allgemein mit Implementierungen und Integrationen im e-Health-Umfeld, insbesondere des Projekts e-Impfpass, aber auch mit ELGA e-Befunden oder e-Medikation betraut sind. Weiters richtet sich
der Leitfaden an alle an der Erstellung von Gesundheitsdaten und Gesundheitsdokumenten beteiligten Personen, einschließlich der Endbenutzer der medizinischen Softwaresysteme und der Angehörigen von Gesundheitsberufen.

=Informationen über dieses Dokument=
==Verbindlichkeit==
Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten für den Elektronischen Impfpass gem. Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 (GTelG 2012) sowie den darauf fußenden Novellen und Verordnungen. Die im Implementierungsleitfaden getroffenen Festlegungen für Inhalt, Struktur, Format und Codierung sind somit verbindlich.

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

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

== Verwendete Grundlagen und Bezug zu anderen Standards ==

{|
|style="vertical-align:top" |
Grundlage dieses Implementierungsleitfadens ist der internationale Standard "HL7 Clinical Document Architecture, Release 2.0" (CDA ©), für die das Copyright © von Health Level Seven International gilt. 
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. Das Datenmodell von CDA und seine Abbildung in XML folgen dem Basisstandard HL7 Version 3 mit seinem Referenzinformationsmodell (RIM). 
 
Für die Modellierung der Inhalte des Impfpasses wurde das "Immunization Content (IC)" Inhaltsprofil aus dem IHE Technical Framework "Patient Care Coordination (PCC)" ausgewählt, das auch im Elektronischen Impf- und Immunschutzdossier der Schweiz [[http://e-health-wiki.ch/index.php/Ehscda:CDA-CH-VACD_(specification)]] verwendet wird und das als wesentliche Grundlage für diesen Leitfaden dient.
| [[Datei:Grafik VerwendeteStandards.png| 300px|Verwendete Standards]]
<ref group="Abbildung">Verwendete Standards</ref>

|}

*[https://www.ihe.net/resources/technical_frameworks/#pcc IHE Integrationsprofile Patient Care Coordination] <ref name=IHEPCC>IHE Patient Care Coordination (PCC) [Online Juli 2019]: https://www.ihe.net/resources/technical_frameworks/#pcc</ref>
*[http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 Clinical Document Architecture (CDA)] <ref name=HL7CDA>HL7 Clinical Document Architecture (CDA) [Online Juli 2019]: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>
*[http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186 Version 3 Product Suite (inkl. RIM)] <ref name=CDAV3RIM>Version 3 Product Suite (inkl. RIM) [Online Juli 2019]: RIM http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186</ref>
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria), die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden (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.

== Wichtige unterstützende Materialien ==
{{BeginYellowBox}}
Auf der Website [[ILF:E-Impfpass_Guide |e-Impfpass Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
* Beispieldokumente für den "Kompletten Immunisierungsstatus" und für "Update Immunisierungsstatus"
* Schematron-Prüfregeln
* Design-Beispiel
Die im Weiteren angeführten Templatespezifikationen wurden im '''Art-Decor Projektrepository''' [https://art-decor.org/art-decor/decor-templates--elgaimpf-?section=templates e-Impfpass] erstellt und können dort eingesehen werden. Eine Anleitung zum Verständnis der Art-Decor-Notation finden Sie im Artikel [[Hilfe:Art-Decor-Tabellen verstehen|Art-Decor-Tabellen verstehen]].
{{EndYellowBox}}
Weitere Informationen zu CDA-Leitfäden werden auf der Website der ELGA GmbH zur Unterstützung bereitgestellt:
* Beispieldokumente
* Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
* CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
* Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
* Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
* Hinweise für die zu verwendenden Terminologien
* Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}
Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA].
{{EndYellowBox}}

=Harmonisierung=
Dieser Implementierungsleitfaden entstand durch die Harmonisierungsarbeit der Arbeitsgruppe e-Impfpass, die im Zeitraum von September 2018 bis Februar 2019 tagte. Die Teilnehmer der Arbeitsgruppe wurden durch ihre Organisation delegiert.

Die Arbeitsgruppe harmonisierte primär die inhaltlichen Vorgaben und soweit möglich die zu verwendenden Terminologien (Value Sets).
Die Formulierung der technischen Spezifikation des CDA Implementierungsleitfadens e-Impfpass erfolgte durch die ELGA GmbH parallel bzw. nach der inhaltlichen Festlegung.

Der Leitfaden wird in einem technischen Abstimmungsverfahren durch die HL7 Austria ("Ballot") zu einem österreichischen Standard. Die Verbindlichkeit zur Anwendung soll durch eine Novellierung des Gesundheitstelematikgesetzes 2012, BGBl.I Nr.111/2012 begründet werden.

== Autoren und Mitwirkende ==
Der vorliegende Leitfaden wurde unter der Leitung der ELGA GmbH von den Autoren und unter Mitwirkung der genannten Personen (Mitglieder der Arbeitsgruppe) erstellt. Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht.
Die HL7 Austria und die ELGA GmbH genehmigen ausdrücklich die Anwendung des Leitfadens ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente und weisen darauf hin, dass dies mit dem Einverständnis aller Mitwirkenden erfolgt.

===Autoren===
'''Das Redaktionsteam''' bestand aus folgenden Personen:
{| class="wikitable"
! Name
! Organisation
! Rolle
|-
| Mag. Dr. Stefan Sabutsch
| ELGA GmbH, HL7 Austria
| Autor, Herausgeber
|-
| DI Andrea Klostermann
| ELGA GmbH
| Autor
|-
| DI Oliver Kuttin
| ELGA GmbH
| Autor

|}

Mit Beiträgen von:
Tony Schaller (medshare GmbH),
Stephan Rainer-Sablatnig (ELGA GmbH),
Nina Svec, M.A. (ELGA GmbH),
Gabriel Kleinoscheg, MSc. (ELGA GmbH),
DI Nikola Tanjga (ELGA GmbH),
Helene Prenner (ELGA GmbH)

===Mitwirkende===
'''Teilnehmer der Arbeitsgruppe e-Impfpass''' (in alphabetischer Reihenfolge):
Anton Angerer (at.Software / WAVM),
Patrick Awart (Atos),
Elisabeth Bischof (Landessanitätsdirektion OÖ),
DI (FH) Reindert Buter (Buter GmbH),
Sabine Eder (Landessanitätsdirektion NÖ),
Mag. Alexander Ertl (BASG / AGES),
Dr. Katja Fischer (BMASGK),
Günter Franz (Landessanitätsdirektion Salzburg),
W HR Dr. Ernst Gschiel (Landessanitätsdirektion Burgenland),
Dr. Eva Heinzl (Landessanitätsdirektion OÖ),
Ingrid Huber (Landessanitätsdirektion NÖ),
OPhysR Dr.in Ursula Karnthaler (Landessanitätsdirektion Wien),
Herbert Karpf, BA (Landessanitätsdirektion Kärnten),
HR Dr. med. univ. Franz Katzgraber (Landessanitätsdirektion Tirol),
DI Andrea Klostermann (ELGA GmbH),
DI Oliver Kuttin (ELGA GmbH),
Dr. Irmgard Lechner (Landessanitätsdirektion NÖ),
Ruprecht Leitner (Apothekerverlag),
Dr. Anita Luckner-Hornischer (Landessanitätsdirektion Tirol),
Dr. Lukas Murajda, PhD, MSc (Landessanitätsdirektion Salzburg),
DI Michael Nöhammer (ÖÄK),
Christopher Ozvald (BMASGK),
Dr. Georg Palmisano (Landessanitätsdirektion OÖ),
Dr. Maria Paulke-Korinek (BMASGK),
Mag. Daniela Philadelphy (BASG / AGES),
Daniela Piererfellner (Landessanitätsdirektion OÖ),
Maria Pramhas (Land Salzburg - Impfadatenbank),
Dr. Daniel Prenninger (Landessanitätsdirektion Burgenland),
Mag. Margit Pufitsch-Weber (Wissenschaftliche Akademie für Vorsorgemedizin),
Stephan Rainer-Sablatnig (ELGA GmbH),
Dr. Stefan Sabutsch (ELGA GmbH),
Robert Scharinger (BMASGK),
Dr.Rudolf Schmitzberger (Impfreferat Österr Ärztekammer),
DI Mag. Birgit Scholz (ELGA GmbH),
Dr. Christoph Schweighofer (ÖÄK),
Carina Seerainer, MSc (ELGA GmbH),
Nina Sjencic (ELGA GmbH),
Landessanitätsdirektorin OSRin Dr.in Karin SPACEK (Landessanitätsdirektion Wien (Magistratsabteilung 15 - Gesundheitsdienst der Stadt Wien)),
Mag. Stefan Spitzbart (Hauptverband),
Stephanie Stürzenbecher, BA MA (Hauptverband),
Dr. Barbara Tucek, MD, MSc (BASG / AGES),
Mag. Ilana Ventura, MSc (BMASGK),
Dr.med. Heimo Wallenko, MAS (Landessanitätsdirektion Kärnten),
Gabriele Wasner (Landessanitätsdirektion OÖ)

{{ILF:Begriffsdefinitionen e-Impfpass}}

=Technischer Hintergrund=

{{ILF:eImpfpass_Allgemeine_Richtlinien | Allgemeine Richtlinien für die Implementierung des e-Impfpasses}}

{{ILF:eImpfpass_Datentypen | e-Impfpass Datentypen}}

==Weitere Informationen zu CDA==
Weitere Informationen zum technischen Hintergrund finden sich unter folgenden Links:

* [[elga-cdaalf-2.06.2:Konzept_und_Modellbeschreibung| Allgemeine Informationen zu CDA]] <ref name=CDAAllgemein>Allgemeine Informationen zu CDA [Online Juli 2019]: https://wiki.hl7.at/index.php?title=elga-cdaalf-2.06.2:Konzept_und_Modellbeschreibung</ref>
* [[CDA_Templates|CDA Templates]] <ref name=CDATemplates>CDA Templates [Online Juli 2019]: https://wiki.hl7.at/index.php?title=CDA_Templates</ref>
* [[ILF:Art-Decor-Tabellen_verstehen|Art-Decor-Tabellen verstehen]] <ref name=ArtDecorVerstehen>Art-Decor-Tabellen verstehen [Online Juli 2019]: https://wiki.hl7.at/index.php?title=Hilfe:Art-Decor-Tabellen_verstehen</ref>
* [[elga-cdaalf-2.06.2:Technische Konformitätsprüfung|Technische Konformitätsprüfung]] <ref name=TechnKonform>Technische Konformitätsprüfung [Online Juli 2019]: https://wiki.hl7.at/index.php?title=elga-cdaalf-2.06.2:Technische_Konformit%C3%A4tspr%C3%Bcfung</ref>
* [[Terminologien|Terminologien]] <ref name=Terminologien>Terminologien [Online Juli 2019]: https://wiki.hl7.at/index.php?title=Terminologien</ref>
= Funktionale Anforderungen=

== Darstellung==
Für die Darstellung des e-Impfpasses wird ein spezielles Stylesheet bereitgestellt, das im XML-Prolog referenziert wird ("ELGA_eimpf-stylesheet_v1.0.xsl").
Grundsätzlich werden die Daten aus den Entries dargestellt. Section.Text MUSS dennoch angegeben werden, da der CDA Rel. 2 Standard "Lesbarkeit für Menschen" ("human readability") vorschreibt.

<div class="landscape">

==Verwendung in der ELGA Infrastruktur==
===Vorgaben zu Dokument-Metadaten (XDS-Metadaten)===
{| class="wikitable"
! XDS-Mapping
! Optio-
nalität
! CDA-Element
clinicalDocument.
! Beispiel
! Erklärung
|-
| formatCode
| R
| .templateId/@extension
|
*<nowiki>@extension="XDSdocumentEntry.formatCode
^urn:hl7-at:eImpf:2019"</nowiki>
*@isplayName= "HL7 Austria e-Impfpass 2019"
| Version des Implementierungsleitfaden e-Impfpass - "Update Immunisierungsstatus" bzw. "Kompletter Immunisierungsstatus" mit XDSdocumentEntry.formatCode als Extension.
Das templateId-Element mit einer Extension beginnend mit "XDSdocumentEntry.formatCode^" wird ins XDS-Attribut formatCode gemappt (ohne Präfix XDSdocumentEntry.formatCode^).
|-
| classCode
| R
| .code
|
*@code="11369-6"
*@displayName="HISTORY OF IMMUNIZATIONS"
*@codeSystem="2.16.840.1.113883.6.1"
| Bezeichnet die "Dokumentklasse". Zulässige Werte gemäß Value-Set "ELGA_Dokumentklassen".
Aus Gründen der Kompatibilität zu IHE PCC und auch den Ableitungen im Schweizer CH-VACD haben alle Impfungsdokumente den Code '''11369-6 History of Immunization Narrative'''.
|-
| rowspan="2"| typeCode
| rowspan="2"| R
| rowspan="2"| .code.translation
|
*@code="82593-5"
*@displayName="Immunization summary report"
*@codeSystem="2.16.840.1.113883.6.1"
| Zur Unterscheidung des Dokumenttyps erhält das Element clinicalDocument.code des '''"Kompletter Immunisierungsstatus"''' ein zusätzliches translation-Element.
|-
|
*@code="87273-9"
*@displayName="Immunization note"
*@codeSystem="2.16.840.1.113883.6.1"
| Zur Unterscheidung des Dokumenttyps erhält das Element clinicalDocument.code des '''"Update Immunisierungsstatus"''' ein zusätzliches translation-Element.
|-
| rowspan="2"| title
| rowspan="2"| R
| rowspan="2"| .title
| "Kompletter Immunisierungsstatus"
| Für den lesenden Dokumentempfänger gedachter Titel des '''Kompletten Immunisierungsstatus'''.
|-
| "Update Immunisierungsstatus"
| Für den lesenden Dokumentempfänger gedachter Titel des '''Update Immunisierungsstatus'''.
|-
| eventCodeList
| R
| .documentationOf
.serviceEvent.code
|
*@code="41000179103"
*@displayName="Immunization record (record artifact)"
*@codeSystem="2.16.840.1.113883.6.96"
*@codeSystemName="SNOMED CT"
| Code der Gesundheitsdienstleistung.
|-
| rowspan="2"| serviceStartTime
| rowspan="2"| R
| rowspan="2"|.documentationOf.serviceEvent
.effectiveTime.low
|
Zeitpunkt des '''ältesten''' effectiveTime aus:
*"Immunization Entry":
**templateId 1.2.40.0.34.6.0.11.3.1
**substanceAdministration.effectiveTime und
*"Impfrelevante Erkrankungen Problem Entry":
**templateId 1.2.40.0.34.6.0.11.3.9
**act.effectiveTime.low
| Beginn der Gesundheitsdienstleistung beim '''Kompletter Immunisierungsstatus'''.
|-
| Zeitpunkt des Behandlungsbeginns (aktueller Besuch).
| Beginn der Gesundheitsdienstleistung bei '''Update Immunisierungsstatus'''.
|-
| rowspan="2"| serviceStopTime
| rowspan="2"| R
| rowspan="2"| .documentationOf.serviceEvent
.effectiveTime.high
|
Zeitpunkt des '''jüngsten''' effectiveTime aus:
*"Immunization Entry":
**templateId 1.2.40.0.34.6.0.11.3.1
**substanceAdministration.effectiveTime und
*"Impfrelevante Erkrankungen Problem Entry":
**templateId 1.2.40.0.34.6.0.11.3.9
**act.effectiveTime.high
| Ende der Gesundheitsdienstleistung bei '''Kompletter Immunisierungsstatus'''.
|-
| Zeitpunkt des Behandlungsendes (aktuelle Behandlung,
muss sich von Behandlungsbeginn unterscheiden)
| Ende der Gesundheitsdienstleistung bei '''Update Immunisierungsstatus'''.
|
|-
| practiceSettingCode
| R
| ''Hinweis: dzt. noch nicht als CDA-Element umgesetzt (folgt in nächster Hauptversion)''
|
| Fachliche Zuordnung des Dokuments. Mögliche Werte: F023 "Interdisziplinärer Bereich" oder F001 "Allgemeinmedizin"
|}
</div>

==Versionierung & Stornierung==
Versionierung und Stornierung betrifft ausschließlich Dokumente vom Typ "Update Immunisierungsstatus".

Das von der e-Impfpass Anwendung erzeugte On-Demand Dokument "Kompletter Immunisierungsstatus" ist immer eine neue Version desselben Dokuments, d.h. es ändert sich nur die Versionsnummer (die SetID bleibt für alle Versionen des kompletten Immunisierungsstatus eines Patienten gleich).

===Versionierung von Dokumenten===
Dokumente vom Typ "Update Immunisierungsstatus" können über die IHE Transaktion ITI-41 versioniert werden.
Die Inhalte werden von der zentralen e-Impfpass-Anwendung verarbeitet und alle Inhalte in den Datenbestand integriert. Das bedeutet, dass alle Daten, die bereits durch ein Dokument in den zentralen Datenbestand übernommen wurden, durch das Update ersetzt werden. Daten, die in der neu registrierten Version nicht enthalten sind, gelten als gelöscht.
Die Fachlogik der zentralen e-Impfpass-Anwendung kann die Änderung oder Löschung verweigern, sollten dadurch inkonsistente Datenbestände entstehen (z.B. wenn Informationen gelöscht werden sollen, auf denen spätere Impfeinträge beruhen).

===Stornierung von Dokumenten===
Dokumente vom Typ "Update Immunisierungsstatus" können über IHE Transaktion ITI-57 storniert werden. Alle Inhalte, die ursprünglich durch das stornierte Dokument eingetragen wurden, werden gelöscht.
Die Fachlogik der zentralen e-Impfpass-Anwendung kann die Stornierung verweigern, sollten dadurch inkonsistente Datenbestände entstehen (z.B. wenn Informationen gelöscht werden sollen, auf denen spätere Impfeinträge beruhen).

==Impfempfehlungen==
Ein Ziel des e-Impfpasses ist, interessierten Ärztinnen und Ärzten sowie Bürgerinnen und Bürgern einen raschen Überblick über aktuelle zur Verfügung stehende Impfungen zu geben. Dazu werden vom e-Impfpass "Impfempfehlungen" ausgegeben. Eine Impfempfehlung enthält zu einer Impfung den jeweils nächsten fälligen Impftermin und dazu eine Handlungsanweisung (Handlungsempfehlung/Handlungsvorschlag). Impfempfehlungen werden für alle Impfungen erstellt, die bereits mindestens einmal erhalten wurden oder die für die Person laut Österreichischen Impfplan empfohlen sind.

Die Impfempfehlungen werden vom Expertensystem der zentralen Anwendung aktuell erstellt und gemeinsam mit dem On-Demand-Dokument "Kompletter Immunisierungsstatus" ausgegeben. Das Expertensystem ist ein Teil der Fachlogik der zentralen Anwendung und bildet den jeweils aktuellen Österreichischen Impfplan ab, der vom Nationalen Impfgremium herausgegeben wird. Der Impfplan wird in ein tabellarisches Regelwerk übersetzt und ins Expertensystem importiert. Zur Berechnung der Impfempfehlung werden folgende Parameter aus der persönlichen Impfdokumentation herangezogen:
* Alter der Person
* Geschlecht
* Bereits erhaltene Impfungen:
** Dosiskennung der letzten eingetragenen Impfung
** Impfstoff
** Impfschema (sofern abweichend vom Defaultschema)
* Durchgemachte impfrelevante Erkrankungen
* Indikation für Impfung ("Risikogruppe")

Automatisch erstellte Impfempfehlungen können mit individuellen Impfempfehlungen eines Arztes überschrieben werden, z.B. bei Vorliegen einer Antikörperbestimmung (Impftiter-Ergebnis). Die Begründung kann (z.B. mit dem Messwert als Kommentar) angegeben werden.

'''Dosiskennung''': Damit die nächste Impfung im Rahmen eines bestimmten Impfschemas korrekt berechnet werden kann, ist es nicht notwendig, dass alle bisher verabreichten Dosen einer Impfung dokumentiert werden. Es reicht, die jeweils letzte Dosis zu dokumentieren, dafür muss die Dosiskennung korrekt angegeben werden (z.B. "Dosis 3").

'''Impftiter''': Ergebnisse von Antikörperbestimmungen werden NICHT von der Berechnungslogik berücksichtigt. Wenn der Impftiter ein Abweichen vom automatisch berechneten Impftermin notwendig macht, muss vom Arzt eine individuelle Impfempfehlung erstellt werden, als Kommentar soll der Impftiter angegeben werden.

'''Handlungsempfehlung''': Für jede automatisch von der zentralen Anwendung ausgegebenen Impfempfehlung wird eine Handlungsempfehlung ausgegeben. Die Handlungsempfehlung wird durch einen Code repräsentiert (Element ''code'' im Immunization Recommendation Entry) und stammt aus einem Value Set (eImpf_SpecialCaseVaccination_VS). Die Bedeutung der Codes ist im Value Set beschrieben (Bedeutung, Anwendungsbeschreibung, Hinweise). Zur einfacheren Darstellung werden die Handlungsempfehlungen gruppiert und bestimmten farbigen Icons zugewiesen; die Zuordnung erfolgt über eine hierarchische Strukturierung im Value Set (Ebene 0 = Icon, Ebene 1 = Handlungsempfehlung)
===Empfehlung, keine Impfung durchzuführen (Kontraindikation)===
Eine Sonderform der Impfempfehlung ist die Empfehlung, KEINE Impfung durchzuführen, wenn eine medizinisch begründete Kontraindikation gegen eine bestimmte Impfung vorliegt.
Für die Angabe einer Kontraindikation sind neben vom berechtigten dokumentierenden Arzt (Author) für einen Patienten folgende Daten einzutragen:
* Impfziel
* Zeitraum, in dem die Kontraindikation gilt
* Kommentar
* Optional: Impfstoff
Vom Expertensystem der zentralen Anwendung wird im Kompletten Immunisierungsstatus eine entsprechende Handlungsanweisung ergänzt ("Impfung nicht indiziert").
{{BeginYellowBox}}
Die Angabe von Kontraindikationen ist derzeit '''nur für Impfungen gegen SARS-CoV-2 (COVID-19) möglich''', um die '''Ausnahmen von der Impfpflicht''' zu dokumentieren.
{{EndYellowBox}}

== Mehrsprachigkeit und grenzüberschreitender Austausch ==
Mehrsprachigkeit wird in dieser Version nicht unterstützt, ist aber für die Zukunft angedacht. Die entsprechenden Strukturen im Leitfaden sind bereits angelegt.

=User Storys ("Anwendungsfälle")=
Die Einsatzszenarien für dieses Datenaustauschformat werden in Form von User Storys ("Anwendungsfälle") knapp beschrieben, um dem Leser den Hintergrund zu vermitteln. Diese Beschreibung der Anwendungsfälle ist nicht normativ und keine Vorentscheidung für die tatsächliche Umsetzung. Eine detaillierte technische Beschreibung der Anwendungsfälle und der Geschäftsprozesse findet sich im Architekturdokument e-Impfpass <ref name=ELGAeImpfpass>ELGA GmbH [Online Oktober 2019]: https://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/index.html</ref>.

Die derzeit bei den unterschiedlichen Akteuren des österreichischen Gesundheitswesens auftretenden Anwendungsfälle betreffend Impfungen werden im Folgenden skizziert.

==Übersicht vorhandener Akteure und Komponenten==
Folgende Abbildung zeigt einen Überblick über die Architektur mit den Akteuren und Komponenten für den e-Impfpass.

[[Datei:Architektur_Ueberblick1.png|1000px|Uebersicht e-Impfpass: Akteure und Komponenten]]

<ref group="Abbildung>Übersicht e-Impfpass: Architektur mit Akteuren und Komponenten</ref>

* e-Impfpass-Teilnehmer / Bürger 
* Impfende GDA
** Niedergelassene Ärzte
*** Fachärztinnen und Fachärzte für Kinder und Jugendheilkunde
*** Ärztinnen und Ärzte für Allgemeinmedizin
** Landessanitätsdirektionen inkl. Amtsärzte (Amtsärzte, Schulärzte, Betriebsärzte)/öffentliche Gesundheitsdienste
* Interessensvertretung von Bürger- und Bürgerinnen-Rechten
** Bürgerinnen und Bürger, die im Z-PI erfasst sind, und dessen Vertreter, insbesondere Eltern-für-Kinder
** ELGA-Ombudsstelle
* ELGA-Serviceline 
* Datenkorrigierender GDA
** Bezirksverwaltungsbehörde
* "Abrechnungsunterstützung" (im Rahmen des kostenlosen Kinderimpfprogramms)
** Landeshauptmann / Landeshauptfrau
** Bezirksverwaltungsbehörde
* Auswertungen für Durchimpfungsraten
** Landeshauptmann / Landeshauptfrau
** Zuständiges Bundesministerium für Gesundheit

Bei der Betrachtung der technischen Architektur haben folgende Ausgangspunkte einen besonderen Stellenwert und werden deshalb kurz zusammengefasst:
# Die e-Impfpass Anwendung ist eine eHealth-Anwendung mit zentraler Datenhaltung.
# Die e-Impfpass Anwendung nutzt betreffend Autorisierung, Protokollierung und Zugangskontrolle die bestehende ELGA Infrastruktur.
# Berechtigte e-Impfpass Anwender (GDA) sind im GDA-I mit entsprechender Rolle gelistet.
# Es muss zwischen folgend aufgelisteten rollenbasierenden Zugangangsarten unterschieden werden.
## Regulärer Zugang mittels Kontaktbestätigungen
## Behördlicher Zugang für tagaktuelles Ausbruchs-Management (und Durchimpfungsrate) welcher gesetzlich geregelt wird (auch ohne Kontaktbestätigung). Hier zählen Zugriffe auf die Impfdaten von eindeutig identifizierten Personen.
# Verabreichte Impfungen müssen lückenlos in der e-Impfpass Anwendung gespeichert werden. Da der Immunisierungsstatus im Ausbruchsfall jederzeit abrufbar sein muss, kommen individuelle Berechtigungen von e-Impfpass-Teilnehmern nicht zur Anwendung (Gesetzesgrundlage ist hier maßgebend).
# Die Geschäftslogik der Anwendung übernimmt die CDA-Verarbeitung und hat folgende Funktionen
## Speichert eingehende CDA Dokumente "Update Immunisierungsstatus", zerlegt diese (entsprechend gültigem Schema) und persistiert die Informationseinheiten.
## Das Zusammenstellen vom OnDemand-Dokument "Kompletter Immunisierungsstatus" (der eigentliche e-Impfpass der Teilnehmer) muss unterstützt werden. Hierfür werden die Inhalte der zentralen Datenbank zusammengestellt und im angeforderten Format (CDA) ausgehändigt.
## Die analytisch-statistische Weiterverarbeitung (Abzüge für BI) bzw. Auswertungen müssen ermöglicht werden.
## Auf Grundlage des gültigen Österreichischen Impfplanes muss bei der Abfrage des persönlichen e-Impfpasses eines Teilnehmers das Datum der nächste(n) fälligen Impfungen und etwaige Nachhol-Impftermine beigefügt werden. Vom GDA manuell eingefügte Impftermine müssen unterstützt werden und diese dürfen von der Fachlogik nicht überschrieben werden.

==Allgemeine Vorbedingungen==
Für den Zugriff auf den elektronischen Impfpass (lesend und schreibend) sind spezielle Rollen und Berechtigungen erforderlich. Diese sowie der Vorgang zur Authentifizierung und Autorisierung sind im Architekturdokument e-Impfpass <ref name=ELGAeImpfpass/>erläutert.
Die notwendigen Stammdaten (z.B. Impfungen, Impfstoffe, impfrelevante Erkrankungen ...) werden über den [https://termpub.gesundheit.gv.at/ Terminologieserver] bereitgestellt.

Sowohl der berechtigte GDA (über das GDA System, sobald E-Card gesteckt wurde), als auch die Bürgerin/der Bürger (über das ELGA Portal) können auf den persönlichen e-Impfpass zugreifen.

==U1 Kompletten Immunisierungsstatus abrufen==
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Max Muster (ELGA Teilnehmer) besucht seinen Hausarzt Dr. DeCarro (Impfender GDA) und möchte Informationen zu seinem Immunisierungsstatus erhalten.
# Dr. DeCarro fragt den e-Impfpass von Max Muster über seine Softwaresystem ab und erhält das On-Demand-Dokument "Kompletter Immunisierungsstatus", das Auskunft über die bisherigen Impfungen und entsprechende Impfempfehlungen enthält.
#Max Muster erfährt von Dr. DeCarro, dass laut Österreichischem Impfplan die nächste FSME-Auffrischungsimpfung in einem Monat ansteht und vereinbart hierfür einen Termin bei Dr. DeCarro.

Auch wenn noch keine Immunisierungseinträge in der e-Impfpass Anwendung gespeichert sind, können Impfempfehlungen abgerufen werden.

==U2 Aktualisierung Immunisierungsstatus==

Wird eine Änderung am dokumentierten Immunisierungsstatus vorgenommen (z.B. neuer Impfeintrag, Nachtragen einer Impfdokumentation oder Korrektur einer bestehenden Impfung, Eintrag einer impfrelevanten Erkrankung), so werden die Änderungen mit dem Datenaustauschformat "Update Immunisierungsstatus" an die zentrale e-Impfpass Anwendung übermittelt. Die zentrale Anwendung übernimmt die Änderungen als Update und berechnet die nächsten empfohlenen Impftermine.

Es kann zwischen folgenden Anwendungsfällen unterschieden werden:

===U2.1 Eintragen des Immunisierungsstatus===
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Max Muster besucht seinen Hausarzt Dr. DeCarro, weil er einen Termin für eine FSME-Auffrischungsimpfung vereinbart hat.
# Dr. DeCarro fragt den e-Impfpass von Max Muster über seine Softwaresystem ab und erhält das Dokument "Kompletter Immunisierungsstatus" (U1), das Auskunft über die bisherigen Impfungen und entsprechende Impfempfehlungen enthält und kontrolliert, ob sich seit dem letzten Abruf Änderungen ergeben haben.
# Dr. DeCarro führt die Impfung durch und dokumentiert diese in seinem Softwaresystem. Nach der Freigabe der Dokumentation erzeugt das Softwaresystem ein Datenaustauschformat "Update Immunisierungsstatus" und sendet dieses an die zentrale Anwendung e-Impfpass, die das Dokument übernimmt und ein Update der Datenbank durchführt.
# Dr. DeCarro kann nun das Dokument "Kompletter Immunisierungsstatus" erneut abrufen und erhält eine neue Version des Dokuments mit aktualisiertem Immunisierungsstatus und neuen Impfempfehlungen für Max Muster.

===U2.2 Korrektur eines Immunisierungseintrags (eigene Einträge)===
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Dr. DeCarro stellt fest, dass der Eintrag, den er für Max Muster erstellt hat, korrigiert werden muss (z.B. wegen eines Dokumentationsfehlers oder weil die individuelle Impfempfehlung vergessen wurde)
# Dr. DeCarro korrigiert den Eintrag in seinem Softwaresystem, das eine neue Version des Dokuments "Update Immunisierungsstatus" an die zentrale Anwendung übergibt (dabei sind alle Einträge in der Korrekturversion enthalten, auch jene, die nicht geändert werden müssen).
# Die zentrale Anwendung ersetzt alle Daten, die durch das originale Dokument "Update Immunisierungsstatus" übernommen worden waren durch die Daten, die in der korrigierten Version enthalten sind. Die korrigierten Daten werden in das Dokument "Kompletter Immunisierungsstatus" eingetragen (Dr. DeCarro bleibt der Author aller betreffenden Einträge).

Die Berechtigung für eine Korrektur von bereits eingetragenen Immunisierungseinträgen hat nur jener GDA, der diese Impfdaten eingetragen hat. Zusätzlich hat eine gesetzlich festgelegte Rolle die Berechtigung (siehe [[#U4 Datenkorrektur durch Behörde|U4]]).

'''''Anmerkung:''''' Eigene Einträge erkennt man daran, dass das id-Element von "Berechtigter Bearbeiter" (Immunization Entry/participant @typeCode="AUT") die eigene GDA-OID enthält.

Die Vorversionen des CDA "Update Immunisierungsstatus" wurden als "DEPRECATED" gekennzeichnet. Die neue Version des CDA Dokuments wird mit dem Status "APPROVED" gespeichert.

===U2.3 Stornierung eines Immunisierungseintrags===
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Dr. DeCarro stellt fest, dass der Eintrag, den er erstellt hat, storniert werden muss (z.B., weil er für den falschen Patienten dokumentiert hat)
# Dr. DeCarro löscht den Eintrag in seinem Softwaresystem, das eine Stornierungsnachricht mit dem Verweis auf das zu stornierende "Update Immunisierungsstatus"-Dokument an die zentrale Anwendung übergibt.
# Die zentrale Anwendung löscht alle Daten, die durch die originale Nachricht "Update Immunisierungsstatus" übernommen worden waren.

Die Berechtigung für eine Stornierung von bereits eingetragenen Immunisierungseinträgen hat nur jener GDA, der diese Impfdaten eingetragen hat oder eine gesetzlich festgelegte Rolle (siehe [[#U4 Datenkorrektur durch Behörde|U4]]).

Stornierte CDA Dokumente wurden als "DEPRECATED" gekennzeichnet.

===U2.4 Nachtragen der Impfdokumentation===
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Max Muster besucht seinen Hausarzt Dr. DeCarro und möchte seinen Papier-Impfpass in den e-Impfpass überführen.
# Dr. DeCarro überträgt das Papierdokument in sein Softwaresystem, das ein Datenaustauschformat "Update Immunisierungsstatus" erzeugt und an die zentrale Anwendung übergibt.

===U2.5 Selbsteintragung von Impfungen durch den Bürger===
Akteure: e-Impfpass Teilnehmer ("Max Muster")

Szenario:
# Max Muster möchte seinen Papier-Impfpass selbst in den e-Impfpass überführen.
# Max Muster überträgt das Papierdokument mit einem über das Internet verfügbarem Softwaresystem, das ein Datenaustauschformat "Update Immunisierungsstatus" erzeugt und an die zentrale Anwendung übergibt.
# Seinen Papierimpfpass kann er digitalisiert als Beilage anhängen (alle weiteren Sektionen sind bei einem Selbsteintrag nicht verfügbar).

'''Anmerkung''': Dieses Szenario ergibt sich aus dem GTelG § 24e: "''(1) Bürger/innen sowie deren gesetzliche oder bevollmächtigte Vertreter/innen haben das Recht (...) 2. Impfungen in das zentrale Impfregister einzutragen, wobei diese '''selbsteingetragenen Impfungen als solche gekennzeichnet werden''' und für Gesundheitsdiensteanbieter gemäß § 24c Abs. 2 Z 1 '''nur zur Information dienen'''.''". Eine entsprechende Funktion steht zum Stand der Erstellung dieses Leitfadens noch nicht zur Verfügung.

==U3 Abrechnung==
''Anmerkung: Die Abrechnung selbst steht nicht im Fokus dieses Leitfadens. Er stellt lediglich sicher, das die für die Abrechnungsunterstützung notwendigen Informationen über das Datenaustauschformat übertragen werden können.''

Akteure: Impfender GDA ("Dr. DeCarro"), Abrechnungsunterstützung, Kind "Max Musterkind"

Szenario:
# Dr. DeCarro dokumentiert die Impfung des Kindes "Max Musterkind" (siehe U2.1)
# Das GDA-Softwaresystem erzeugt ein Datenaustauschformat "Update Immunisierungsstatus", das zusätzlich die Informationen zur Abrechenbarkeit enthält und sendet dieses an die zentrale Anwendung.
# Die Abrechnungsunterstützung erhält von der zentralen Anwendung einen Minimaldatensatz (d.h. nur die minimal notwendigen Daten für die Abrechnung), der ausschließlich die Impfungen enthält, die in der gewählten Zeit und Region entsprechen und die vom GDA als "abrechenbar" markiert wurden.
# Die Abrechnungsunterstützung kontrolliert den Anspruch an Abrechnung der einzelnen Einträge und leitet alle Schritte zur Überweisung des Abrechnungsbetrags in die Wege.

Im Rahmen des kostenfreien Kinderimpfprogramms rechnen sowohl Ärztinnen und Ärzte als auch Apotheken mit den Ländern Impfleistungen mit Hilfe der Informationen aus dem zentralen Impfregister ab. Die für die Abrechnung zuständigen Länderstellen können über die Informationen aus dem zentralen Impfregister nachvollziehen, welche Ärztin oder welcher Arzt, welche Impfung wann verabreicht hat und somit den Verrechnungs- und Ausbezahlungsprozess abwickeln. Nicht relevant für die Abrechnung sind z.B. nacherfasste oder stornierte Impfungen, Titereinträge oder Einträge zur Immunisierung durch Krankheit. Der aktuelle Stand der abrechnungsrelevanten Impfdaten aus dem zentralen Impfregister wird jeweils im Folgemonat für die Abrechnungsunterstützung zur Verfügung gestellt.

==U4 Datenkorrektur durch Behörde (fremde Einträge) ==
Akteure: e-Impfpass Teilnehmer ("Max Muster"), Amtsarzt mit der Rolle "Korrekturberechtigte Person" ("Amelia Amtsarzt")

Szenario:
# Max Muster stellt fest, dass Dr. DeCarro, der mittlerweile in Pension ist, beim Übertragen einer Reiseimpfung aus dem Papierimpfpass eine falsche Impfung eingetragen hat und möchte diese in seinem e-Impfpass korrigieren lassen. Er stellt bei der Bezirksverwaltungsbehörde (Rolle "Korrekturberechtigte Person") einen entsprechenden Antrag.
# Amelia Amtsarzt aus der Bezirksverwaltungsbehörde ruft den "Kompletten Immunisierungsstatus" von Max Muster ab und trägt entsprechende Änderungen in ihr Softwaresystem ein.
# Das Softwaresystem der Bezirksverwaltungsbehörde, übergibt eine korrigierte Version des Dokuments "Update Immunisierungsstatus" (jenes, mit dem Dr. DeCarro damals den falschen Eintrag eingemeldet hat) an die zentrale Anwendung. Dabei sind alle Einträge in der Korrekturversion enthalten, auch jene, die nicht geändert werden müssen (als document.author ist Amelia Amtsarzt eingetragen).
# Die zentrale Anwendung ersetzt alle Daten, die durch das originale Dokument "Update Immunisierungsstatus" übernommen worden waren durch die Daten, die in der korrigierten Version enthalten sind. Die korrigierten Daten werden in das Dokument "Kompletter Immunisierungsstatus" eingetragen und Amelia Amtsarzt wird bei den geänderten Einträgen als "Korrigierende Person" geführt.

Grundlegend kann ein GDA nur jene Einträge in der ELGA-Infrastruktur aktualisieren, die von ihm selbst eingetragen wurden. Unter bestimmten Rahmenbedingungen sollen behördliche Stellen Daten im Impfpass korrigieren dürfen (z.B. wenn der impfende GDA, der eine Dokumentation ursprünglich erstellt hat, nicht mehr in der Lage ist, die Daten selbst zu korrigieren). Bei der zentralen e-Impfpass Anwendung gibt es daher ausgewählte GDA, die Bezirksverwaltungsbehörden, die Immunisierungseinträge von anderen GDA aktualisieren oder stornieren dürfen. Dies ist notwendig, da Immunisierungseinträge lebenslang gespeichert werden, und es somit eine vom eintragenden GDA unabhängige Korrekturmöglichkeit falscher Daten geben muss.

==U5 Krisenmanagement==
''Anmerkung: Das Krisenmanagements selbst steht nicht im Fokus dieses Leitfadens, es wird nur der Vollständigkeit halber die Vorgehensweise beschrieben.''
===U5.1 Krankheitsausbrüche===
Im Rahmen des Krisenmanagements bei Krankheitsausbrüchen muss von Kontaktpersonen (z.B. in Schule, Kindergarten, Ordination, Wartebereichen in Ambulanzen) der Impfstatus erhoben werden. Derzeit erfolgt die Erhebung des Impfstatus aufwändig manuell bzw. in den lokal begrenzten Datenbanken. Durch die zentrale e-Impfpass Anwendung werden Umgebungsuntersuchungen digital unterstützt, indem die Impfdokumentation von Kontaktpersonen für die österreichische Bevölkerung elektronisch bezogen wird. Dies wird das Ausbruchsmanagement beschleunigen und vereinfachen und somit Ansteckungen vermeiden sowie Kosten des Ausbruchs(-managements) senken.

===U5.1 Chargenrückruf===
Ein weiterer Anwendungsfall im Krisenmanagement betrifft den Chargenrückruf von Impfstoffen. Momentan veröffentlicht das Bundesamt für Sicherheit im Gesundheitswesen (BASG) im Anlassfall die Chargennummern von Arzneimitteln die Qualitätsmängel aufweisen. Apotheken, die Chargenrückrufe erhalten, sortieren die Ware aus und geben diese ihrem Lieferanten wieder mit. Sollte die Impfung die Apotheke schon verlassen haben, wird eruiert welcher GDA oder Bürger betroffen ist und im Anlassfall kontaktiert.

<div class="landscape">

=Datenarten=
==Dataset==
{| class="wikitable"
! style="width: 25%" |Name
! style="width: 40%" |Beschreibung
! style="width: 20%" |Mapping
! style="width: 15%" |Datenelement-Nr.
|- style="vertical-align:top;"
|'''Unterzeichnende Person (Dokument)''' (Rechtlicher Unterzeichner)
|Der "Rechtliche Unterzeichner" oder "Hauptunterzeichner" ist jene Person, welche für ein Update des Immunisierungsstatus bzw. den Nachtrag aus rechtlicher Sicht die Verantwortung übernimmt (gesamtes Dokument!). Der "Rechtliche Unterzeichner" entfällt beim Kompletten Immunisierungsstatus, da dieser automatisch von einem Gerät erstellt wird (hier entfällt die Angabe aller Unterzeichner).
|clinicalDoc.LegalAuthenticator
|elgaimpf-dataelement-368
|- style="vertical-align:top;"
| style="padding-left: 15px" |Zeitpunkt der Unterzeichnung
|Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.
|
|elgaimpf-dataelement-369
|- style="vertical-align:top;"
| style="padding-left: 15px" |Signatur
|
|
|elgaimpf-dataelement-370
|- style="vertical-align:top;"
| style="padding-left: 15px" |ID des Unterzeichners
|
|
|elgaimpf-dataelement-371
|- style="vertical-align:top;"
| style="padding-left: 15px" |Kontaktdaten
|Weitere Kontaktdaten (Telefon, Handy, Email...)
|
|elgaimpf-dataelement-372
|- style="vertical-align:top;"
| style="padding-left: 15px" |Name
|Name der Person
|
|elgaimpf-dataelement-373
|- style="vertical-align:top;"
| style="padding-left: 15px" |Organisation
|
|
|elgaimpf-dataelement-374
|- style="vertical-align:top;"
|'''Eintragende Person (Schreibkraft)'''
|Datenverarbeitende Person. Die Person, die Daten für den Impfpass dokumentiert.
|clinicalDoc.dataEnterer
|elgaimpf-dataelement-32
|- style="vertical-align:top;"
|'''Verantwortliche Person (Impfung)''' (Medizinisch verantwortliche Person, auch: Impfstelle)
|Die Person, die für die Impfung und ihre Dokumentation letztlich medizinisch verantwortlich ist. "Dr. X (im Privat-KH Y) war für die Impfung verantwortlich/hat sie angeordnet". Bei neuem Immunisierungseintrag muss dieses Element angegeben sein. Bei einem Nachtrag kann dieses Element entfallen, wenn nicht mehr eruierbar. Empfohlenes Label für entsprechende Eingabefelder einer GUI: „Für die Impfung verantwortlich“…
|substanceAdministration "Immunization Entry"/author
|elgaimpf-dataelement-307
|- style="vertical-align:top;"
| style="padding-left: 15px" |Name
|
|
|elgaimpf-dataelement-339
|- style="vertical-align:top;"
| style="padding-left: 30px" |Titel (Präfix)
|Titel der Person (voran- und nachgestellte Titel)
|
|elgaimpf-dataelement-340
|- style="vertical-align:top;"
| style="padding-left: 30px" |Vorname
|Vornamen der Person
|
|elgaimpf-dataelement-343
|- style="vertical-align:top;"
| style="padding-left: 30px" |Nachname
|Nachname der Person
|
|elgaimpf-dataelement-344
|- style="vertical-align:top;"
| style="padding-left: 15px" |ID des Unterzeichners
|ID der verantwortlichen Person (lokaler Identifikator)
|
|elgaimpf-dataelement-346
|- style="vertical-align:top;"
| style="padding-left: 15px" |Kontaktdaten
|Weitere Kontaktdaten (Telefon, Handy, Email...)
|
|elgaimpf-dataelement-347
|- style="vertical-align:top;"
| style="padding-left: 15px" |Organisation
|
|
|elgaimpf-dataelement-353
|- style="vertical-align:top;"
| style="padding-left: 30px" |ID der Organisation
|
|
|elgaimpf-dataelement-381
|- style="vertical-align:top;"
| style="padding-left: 30px" |Name der Organisation
|
|
|elgaimpf-dataelement-382
|- style="vertical-align:top;"
| style="padding-left: 30px" |Telekom
|Weitere Kontaktdaten (Telefon, Handy, Email...)
|
|elgaimpf-dataelement-383
|- style="vertical-align:top;"
| style="padding-left: 30px" |Adresse
|Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...)
|
|elgaimpf-dataelement-384
|- style="vertical-align:top;"
| style="padding-left: 15px" |Freigabezeitpunkt (Zeitpunkt der Unterzeichnung)
|Der Zeitpunkt, an dem die Dokumentation freigegeben wurde
|substanceAdministation.author.time
|elgaimpf-dataelement-366
|- style="vertical-align:top;"
|'''Impfende Person (Impfarzt)'''
|Die Person, die ''im Auftrag der medizinisch verantwortlichen Person'' die Impfung durchführt, z.B. ein Turnusarzt, eine Hebamme oder eine diplomierte Pflegeperson. Die Impfende Person ''kann'' mit der medizinisch verantwortlichen Person ident sein und es können auch beide (redundant) angegeben werden.
|substanceAdministration "Immunization Entry"/performer
|elgaimpf-dataelement-140
|- style="vertical-align:top;"
| style="padding-left: 15px" |Name
|Name der Person
|
|elgaimpf-dataelement-236
|- style="vertical-align:top;"
| style="padding-left: 30px" |Titel (Präfix)
|Titel der Person (voran- und nachgestellte Titel)
|
|elgaimpf-dataelement-237
|- style="vertical-align:top;"
| style="padding-left: 30px" |Vorname
|Vornamen der Person
|
|elgaimpf-dataelement-240
|- style="vertical-align:top;"
| style="padding-left: 30px" |Nachname
|Nachname der Person
|
|elgaimpf-dataelement-241
|- style="vertical-align:top;"
| style="padding-left: 15px" |Organisation
|
|
|elgaimpf-dataelement-294
|- style="vertical-align:top;"
| style="padding-left: 30px" |ID der Organisation
|
|
|elgaimpf-dataelement-389
|- style="vertical-align:top;"
| style="padding-left: 30px" |Name der Organisation
|
|
|elgaimpf-dataelement-390
|- style="vertical-align:top;"
| style="padding-left: 30px" |Telekom
|Weitere Kontaktdaten (Telefon, Handy, Email...)
|
|elgaimpf-dataelement-391
|- style="vertical-align:top;"
| style="padding-left: 30px" |Adresse
|Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...)
|
|elgaimpf-dataelement-392
|- style="vertical-align:top;"
| style="padding-left: 15px" |Rolle
|Berufsrolle der impfenden Person (Auswahlliste)
|
|elgaimpf-dataelement-210
|- style="vertical-align:top;"
|'''Nachtragende Person'''
|Die Person, die für die fachliche Richtigkeit des Nachtrags verantwortlich ist. Nur für Nachtragung relevant, dort verpflichtend anzugeben. (Z.B: "Dr. Z hat diese Impfung nachgetragen.") Wenn Immunisierungsdaten per Stapelverarbeitung aus bestehenden Registern in den e-Impfpass übertragen werden, kann hier auch das Register eingetragen werden, aus dem die Daten stammen (z.B. "Impfregister des Landes…")
|substanceAdministration "Immunization Entry"/participant mit @typeCode = "ENT"
|elgaimpf-dataelement-285
|- style="vertical-align:top;"
| style="padding-left: 15px" |Name
|Name der Person
|
|elgaimpf-dataelement-286
|- style="vertical-align:top;"
| style="padding-left: 30px" |Titel (Präfix)
|Titel der Person
|
|elgaimpf-dataelement-287
|- style="vertical-align:top;"
| style="padding-left: 30px" |Vorname
|Vornamen der Person
|
|elgaimpf-dataelement-290
|- style="vertical-align:top;"
| style="padding-left: 30px" |Nachname
|Nachname der Person
|
|elgaimpf-dataelement-291
|- style="vertical-align:top;"
| style="padding-left: 15px" |Datum der Eintragung (Eintragungsdatum, Datum der Dokumentation)
|Datum und Zeit, an dem die Impfung in den e-Impfpass eingetragen d.h. dokumentiert oder geändert wurde. Gilt auch bei einer nachträglichen Eintragung aus einer anderen Quelle (z.B. Papier-Impfpass, andere elektronische Quellen), d.h. NICHT das Impf-Datum
|substanceAdministration "Immunization Entry"/participant mit @typeCode = "ENT" / time
|elgaimpf-dataelement-293
|- style="vertical-align:top;"
|'''Korrigierende Person'''
|Die Person, die für die fachliche Richtigkeit der Korrektur eines bestehenden Immunisierungseintrags verantwortlich ist.
|substanceAdministration "Immunization Entry"/participant mit @typeCode = "VRF"
|elgaimpf-dataelement-402
|- style="vertical-align:top;"
| style="padding-left: 15px" |Name
|Name der Person (mit Titel, Vorname, Name, Organisation)
|
|elgaimpf-dataelement-404
|- style="vertical-align:top;"
| style="padding-left: 15px" |Datum der Korrektur (Korrekturdatum)
|Datum und Zeit, an dem die Korrektur im e-Impfpass eingetragen wurde.
|substanceAdministration "Immunization Entry"/participant mit @typeCode = "VRF" / time
|elgaimpf-dataelement-403
|- style="vertical-align:top;"
|'''Berechtigter Bearbeiter'''
|Die eindeutige Kennung des GDA, der einen Immunisierungs-Eintrag (entry) bearbeiten darf. Das Berechtigungssystem erlaubt die Korrektur eines Eintrags nur einem GDA mit derselben OID ''oder'' GDA mit der Rolle "Korrekturberechtigte Person".
|substanceAdministration "Immunization Entry"/participant mit @typeCode = "AUT"
|elgaimpf-dataelement-405
|- style="vertical-align:top;"
|'''Impfling''' (Patient, Klient, Kunde)
|Der Impfling ist die Person, über die der e-Impfpass Impfungen verwaltet und über deren Gesundheitsdaten berichtet wird.. Entspricht dem "Patienten".
|clinicalDocument.recordTarget
|elgaimpf-dataelement-1
|- style="vertical-align:top;"
| style="padding-left: 15px" |Name
|Name der Person
|
|elgaimpf-dataelement-172
|- style="vertical-align:top;"
| style="padding-left: 30px" |Titel (Präfix)
|Titel der Person (voran- und nachgestellte Titel)
|
|elgaimpf-dataelement-173
|- style="vertical-align:top;"
| style="padding-left: 30px" |Vorname
|Vornamen der Person
|
|elgaimpf-dataelement-176
|- style="vertical-align:top;"
| style="padding-left: 30px" |Nachname
|Nachname der Person
|
|elgaimpf-dataelement-177
|- style="vertical-align:top;"
| style="padding-left: 15px" |Geburtstdatum
|Geburtstdatum der Person
|
|elgaimpf-dataelement-95
|- style="vertical-align:top;"
| style="padding-left: 15px" |Geschlecht (Administatives Geschlecht)
|Administatives Geschlecht der Person im Sinne der Anrede oder Adressierung zB Brief: "Herr" oder "Frau"
|Werte: M, F. UNK (Unbekannt)
|elgaimpf-dataelement-94
|- style="vertical-align:top;"
| style="padding-left: 15px" |LokaleID
|Identifikator des Impflings im lokalen IT-System (Patientenbezogen, nicht fallbezogen) Verpflichtend mit Eintragung einer Impfung anzugeben.
|
|elgaimpf-dataelement-86
|- style="vertical-align:top;"
| style="padding-left: 15px" |SVNr (Sozialversicherungsnummer)
|Sozialversicherungsnummer
|
|elgaimpf-dataelement-87
|- style="vertical-align:top;"
| style="padding-left: 15px" |bPK-GH
|Gemäß eGovernment-Gesetz ist das bPk-GH der eindeutige Identifikator für den Gesundheitsbereich. Verpflichtende Angabe im CDA-Header für spezifische ELGA-Anwendungen (z.B. e-Medikation)
|
|elgaimpf-dataelement-88
|- style="vertical-align:top;"
| style="padding-left: 15px" |Adresse
|Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...)
|
|elgaimpf-dataelement-219
|- style="vertical-align:top;"
| style="padding-left: 30px" |Straße
|
|
|elgaimpf-dataelement-252
|- style="vertical-align:top;"
| style="padding-left: 30px" |Hausnummer
|
|
|elgaimpf-dataelement-253
|- style="vertical-align:top;"
| style="padding-left: 30px" |Postleitzahl
|
|
|elgaimpf-dataelement-254
|- style="vertical-align:top;"
| style="padding-left: 30px" |Stadt
|
|
|elgaimpf-dataelement-255
|- style="vertical-align:top;"
| style="padding-left: 30px" |Bundesland
|
|
|elgaimpf-dataelement-256
|- style="vertical-align:top;"
| style="padding-left: 30px" |Land
|
|
|elgaimpf-dataelement-257
|- style="vertical-align:top;"
| style="padding-left: 15px" |Gemeindekennziffer (GKZ, ÖSTAT-Nr.)
|Allen Gemeinden Österreichs ist eine 5-stellige Gemeindekennziffer (GKZ) zugeordnet. Das Gemeindeverzeichnis bildet die Verwaltungsgliederung in Verwaltungssprengel ab. Die Vergabe der Gemeindekennziffer obliegt Statistik Austria (Adressregisterverordnung – AdrRegV, BGBl. 218/2005, §1).
|Kein Mapping, ist nicht im CDA Dokumenten enthalten. Liegt in der zentralen Anwendung zur Adresse vor.
|elgaimpf-dataelement-49
|- style="vertical-align:top;"
| style="padding-left: 15px" |Bezirkskennziffer (BKZ)
|Wie Gemeindekennziffer, erste 3 Stellen
|Kein Mapping, ist nicht im CDA Dokumenten enthalten. Liegt in der zentralen Anwendung zur Adresse vor.
|elgaimpf-dataelement-85
|- style="vertical-align:top;"
| style="padding-left: 15px" |Kontaktdaten
|Weitere Kontaktdaten (Telefon, Handy, Email...)
|
|elgaimpf-dataelement-216
|- style="vertical-align:top;"
| style="padding-left: 30px" |Telefon Mobil
|
|
|elgaimpf-dataelement-227
|- style="vertical-align:top;"
| style="padding-left: 30px" |Telefon Festnetz
|
|
|elgaimpf-dataelement-228
|- style="vertical-align:top;"
| style="padding-left: 30px" |Mail
|
|
|elgaimpf-dataelement-229
|- style="vertical-align:top;"
| style="padding-left: 30px" |FAX
|
|
|elgaimpf-dataelement-230
|- style="vertical-align:top;"
|'''Personengruppe''' (Expositionsrisikogruppe)
|Merkmal für Zugehörigkeit des Impflings zu bestimmten Personen- oder Risikogruppen (z.B. Gesundheitsberufe). Bei bestimmten Personengruppen kann das Impfschema und damit die berechnete Impffrist abweichen. Optional, mehrfache Angabe möglich.
|Sektion "Expositionsrisiko Personengruppen" mit Act "Expositionsrisiko Problem Concern Entry"
|elgaimpf-dataelement-125
|- style="vertical-align:top;"
| style="padding-left: 15px" |Zeitbereich
|Zeitbereich, in dem die Zugehörigkeit zur Personengruppe aktiv ist oder war
|
|elgaimpf-dataelement-394
|- style="vertical-align:top;"
|'''Impfung''' (Vakzination, Schutzimpfung, Immunisierung )
|Dokumentierte Impfung: ein einzelne Gabe eines Impfstoffes
|Sektion "Impfungen - kodiert", substanceAdministration "Immunization Entry"
|elgaimpf-dataelement-2
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfung (Klassifikation) (Impfschutz, Impfstoffgruppe, Immunisierung)
|Impfschutz gegen eine bestimmte Krankheit oder einen Erreger. Mehrfach-Attribut - Bei einer Impfung mit einem Produkt können mehrere Wirkstoffe (gegen mehrere Krankheiten) verabreicht werden. Alle einzelnen "Impfungen" müssen zu dem Produkt zentral verfügbar sein.
|substanceAdministration "Immunization Entry" und entryRelationship/Observation "Immunization Target Entry"
|elgaimpf-dataelement-6
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfschema (Impfkonzept, vaccinationProtocol)
|Name für den "Plan der notwendigen Impf-Dosen" (Regelwerk für die Gabe von Impfdosen bzw Teilimpfungen zur Immunisierung; Grundimmunissierung und Auffrischung) Wenn bei Impfung nicht angegeben, wird das "Default-Schema" angenommen.
|Mapping: substanceAdministration "Immunization Entry" und precondition/criterion "Immunization Schedule Entry"
|elgaimpf-dataelement-25
|- style="vertical-align:top;"
| style="padding-left: 15px" |Dosiskennung (Dosis-Nummer, Reihenfolgenummer in der Sequenz der Impfdosen)
|Angabe, um welche Impfung oder Teilimpfung es sich handelt (entsprechend einem Impfschema)
|Mapping: criterion "Immunization Schedule Entry"/value
|elgaimpf-dataelement-30
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfdatum (Vaccination administration date)
|Zeitpunkt der Durchführung der Impfung
|substanceAdministration "Immunization Entry"/effectiveTime
|elgaimpf-dataelement-8
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfort
|Ort, an dem die Impfung stattgefunden hat (wenn abweichend von Organisation Impfarzt). (z.B: Öffentliche Einrichtung, Schule (+ Klasse), Kaserne, Betrieb ...)
|Muss immer im "Performer" Element des Immunization Entry angegeben werden.
Wenn der verantwortliche Arzt selbst impft, muss er zusätzlich als Impfarzt eingetragen werden. substanceAdministration "Immunization Entry"/performer/assignedEntity/representedOrganization/addr (mit @use="PHYS")
|elgaimpf-dataelement-137
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfreaktion (Reaktion)
|Aufgetretene Reaktion, Auswahlkatalog
|Wurde nicht umgesetzt
|elgaimpf-dataelement-283
|- style="vertical-align:top;"
| style="padding-left: 15px" |Abrechenbarkeit
|Kennzeichen, ob Impfung mit Land abgerechnet werden kann (Eintragung durch impfenden Arzt)
|Notwendig für Filterung der Daten, die an Länder zur Abrechnung der Impfungen weitergeleitet werden. Die Abrechenbarkeit selbst wird vom Land geprüft und festgestellt.Mapping: substanceAdministration "Immunization Entry" und entryRelationship/act "Immunization Billability Entry"
|elgaimpf-dataelement-29
|- style="vertical-align:top;"
| style="padding-left: 30px" |Klassifikator (Honorar-Klassifikation)
|Abrechnungsrelevante Klassifikation der Impfenden Person (zB "Arzt mit Hausapotheke"). Wird im Zentralsystem nicht mehr benötigt, daher gestrichen. --> Die Verrechnung etc. erfolgt über die internen GDA Systeme (benötigt wird nur die Kennzeichnungsmöglichkeit ob abrechenbar oder nicht
|act "Immunization Billability Entry"/code/qualifier
|elgaimpf-dataelement-367
|- style="vertical-align:top;"
| style="padding-left: 30px" |Impfindikation
|Grund für die Impfung (optional). Wird für Abrechnung benötigt: * IG1 Indikationsimpfung für Risikogruppe * IG2 Wiederholungsimpfung aufgrund medizinischer Indikation
|act "Immunization Billability Entry"/code/qualifier
|elgaimpf-dataelement-379
|- style="vertical-align:top;"
| style="padding-left: 30px" |Impfgutschein
|Identifikationskennzeichen eines Impf-Gutscheins (bei Vorliegen von Impf-Gutscheinheften)
|Notwendig für Abrechnung. Alphanumerisches Kennzeichen (gültig 1x für eine Impfung). Keine weitere Prüfung im e-Impfpass.Mapping: act "Immunization Billability Entry" mit act/id
|elgaimpf-dataelement-139
|- style="vertical-align:top;"
| style="padding-left: 15px" |Zusatzklassifikation
|Zusätzliche strukturierte Information zu einer Impfung, zB eine Klassifizierung der Umgebung, in der die Impfung stattgefunden hat.
|"Immunization Entry" mit observation "Zusatzklassifikation" Das @code-Attribut definiert die Art der Klassifizierung, der Wert wird im @value-Attribut angegeben.
|elgaimpf-dataelement-401
|- style="vertical-align:top;"
|'''Impfstoff (Produkt)''' (Arzneimittel)
|Daten zur verabreichten Arzneimittelspezialität
|substanceAdministration "Immunization Entry" und consumable/manufacturedProduct "Vaccine Product" bzw. "Vaccine Product nicht angegeben"
|elgaimpf-dataelement-3
|- style="vertical-align:top;"
| style="padding-left: 15px" |Bezeichnung der Arnzei (Zulassungsname)
|Bezeichnung des Impfstoffes, z.B. "Encepur 0,25 ml für Kinder Injektionssuspension in einer Fertigspritze"
|manufacturedProduct/manufacturedMaterial/name
|elgaimpf-dataelement-31
|- style="vertical-align:top;"
| style="padding-left: 15px" |Pharmazentralnummer (PZN)
|Pharmazentralnummer der Arzneispezialität
|manufacturedProduct/manufacturedMaterial/code
|elgaimpf-dataelement-5
|- style="vertical-align:top;"
| style="padding-left: 15px" |Chargennummer (Charge)
|Chargennummer der Arzneispezialität, die verabreicht wurde
|manufacturedProduct/manufacturedMaterial/lotNumberText
|elgaimpf-dataelement-4
|- style="vertical-align:top;"
| style="padding-left: 15px" |Ablaufdatum
|Muss dokumentiert werden. Kann aus 2D Barcode abgleitet werden Nicht für "Nacherfassung" erforderlich
|substanceAdministration "Immunization Entry" mit entryRelationship/act "Immunization Billability Entry"/effectiveTime
|elgaimpf-dataelement-134
|- style="vertical-align:top;"
| style="padding-left: 15px" |UniqueIdentifier (Serialisierungsnummer)
|Serialisierungsnummer oder "Packungs-Identifikator. Durch die Serialisierungsnummer ist jede einzelne Packung im europäischen Markt individualisierbar, entsprechend Fälschungsschutzrichtlinie 2011/62/EU und zugehörigerr delegierte Verordnung (EU) 2016/161
|manufacturedProduct/id
|elgaimpf-dataelement-135
|- style="vertical-align:top;"
| style="padding-left: 15px" |Hersteller (Zulassungsinhaber)
|Hersteller (Zulassungsinhaber) des Impfstoffes (bzw. der Arzneispezialität)
|manufacturedProduct/manufacturerOrganization
|elgaimpf-dataelement-12
|- style="vertical-align:top;"
| style="padding-left: 15px" |ATC
|ATC-Code des Wirkstoffs aus Fachinformation
|manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:code
|elgaimpf-dataelement-235
|- style="vertical-align:top;"
| style="padding-left: 15px" |Wirkstoff
|Wirkstoff(e) des Arzneimittels, zB "Masernviren, Stamm Schwarz (lebend, attenuiert)
|manufacturedMaterial/pharm:ingredient
|elgaimpf-dataelement-185
|- style="vertical-align:top;"
| style="padding-left: 15px" |Menge (Dosis)
|Menge der verabreichten Arzneispezialität (Mengenangabe aus Fachinformation). '''Hinweis:''' Die tatsächlich verabreichte Menge kann dokumentiert werden, falls von Fachinformation abweichend. Falls zwei Impfdosen verabreicht werden ("zwei Packungen"), gibt es zwei Möglichkeiten der Dokumentation: Wenn die Packungen dieselbe Chargennummer besitzen: Verabreichte Menge verdoppeln, nur eine Impfung dokumentieren (zwei Impfungen mit derselben Chargennummer würden von der zentralen Applikation als Duplikat erkannt und ignoriert). Wenn zwei unterschiedliche Chargennummern verimpft werden, können beide jeweils als eine eigene Impfung mit derselben Dosiskennung und demselben Impfdatum gespeichert werden.
|substanceAdministration "Immunization Entry"/doseQuantity
|elgaimpf-dataelement-15
|- style="vertical-align:top;"
|'''Impfempfehlung''' (Impfkalender)
|Daten der empfohlenen (zukünftigen) Impfungen: * Impfung, Arzneimittel, frühestmöglicher Folgetermin (Tag) * Anzugebende Folgetermine: immer nur der nächste Folgetermin Die Impflogik gilt grundsätzlich für lt. Impfplan empfohlene Impfungen und für darüber hinaus bereits einmal verabreichte Impfungen Automatisch / von Arzt eingetragen (zusätzlich)
|Sektion "Impfempfehlungen - kodiert" mit entry/substanceAdministration "Immunization Recommendation Entry" und negationInd "false".
|elgaimpf-dataelement-169
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impf-Frist (Datum der nächsten Impfung)
|Datum (Frist oder Zeitraum), an dem der nächste Impftermin (für diese Impfung) notwendig ist. Wird definiert durch: Nationaler Impfplan Fachinformation (liegt derzeit nicht strukturiert vor) Individuelle Konstellation des Impflings --> manueller Eintrag bei Impfung (Abhängig vom Produkt bzw "Impfung", wenn Kombinationspräparat)
|choice von /effectiveTime als TS und /effectiveTime als IVL_TS
|elgaimpf-dataelement-28
|- style="vertical-align:top;"
| style="padding-left: 15px" |Dosiskennung (Dosis-Nummer, Reihenfolgenummer in der Sequenz der Impfdosen)
|Angabe, um welche Impfung oder Teilimpfung es sich handelt (entsprechend einem Impfschema)
|/precondition/criterion "Immunization Schedule Entry"
|elgaimpf-dataelement-231
|- style="vertical-align:top;"
| style="padding-left: 15px" |Autor (Quelle)
|Person oder System, das die Empfehlung generiert
|/author
|elgaimpf-dataelement-232
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfung (Klassifikation) (Referenz)
|Verweist auf die Impfung, für die diese Empfehlung gilt. Eine Impfempfehlung pro Impfung (nicht pro Kombination)
|entryRelationship mit observation "Immunization Target Entry"
|elgaimpf-dataelement-380
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfstoff (Referenz)
|Verweist auf das Produkt, für das die Empfehlung gilt; aber mit eingeschränkten Attributen (PZN)
|consumable
|elgaimpf-dataelement-233
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfschema (Referenz)
|Referenz auf den der Empfehlung zugrundeliegenden Impfplan, Fachinformation, Dokumentation, … 1. Nationaler Impfplan 2. Fachinformation (liegt derzeit nicht strukturiert vor) 3. Individuelle Konstellation des Impflings --> manueller Eintrag bei Impfung (Abhängig vom Produkt bzw "Impfung", wenn Kombinationspräparat)
|reference/externalDocument
|elgaimpf-dataelement-234
|- style="vertical-align:top;"
| style="padding-left: 15px" |Begründung
|Freitext zur Begründung einer vom Impfarzt angepassten Impfempfehlung
|entryRelationship/@typeCode = "RSON" mit act "Comment Entry"
|elgaimpf-dataelement-171
|- style="vertical-align:top;"
|- style="vertical-align:top;"
|'''Kontraindikation für Impfungen'''
|Daten der Impfungen, die nicht verabreicht werden sollen: * Impfung 

*Zeitraum, in dem die Kontraindikation gilt * Kommentar Muss von einem Arzt eingetragen werden
|Sektion "Impfempfehlungen - kodiert" mit entry/substanceAdministration "Immunization Recommendation Entry" und negationInd "true".
|elgaimpf-dataelement-169
|- style="vertical-align:top;"
| style="padding-left: 15px" |Zeitraum
|Zeitraum, in dem die Kontraindikation gilt
|choice von /effectiveTime als TS und /effectiveTime als IVL_TS
|elgaimpf-dataelement-28
|- style="vertical-align:top;"
| style="padding-left: 15px" |Autor (Quelle)
|Person oder System, das die Kontraindikation bestätigt
|/author
|elgaimpf-dataelement-232
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfung (Klassifikation) (Referenz)
|Verweist auf die Impfung, für die diese Kontraindikation gilt.
|entryRelationship mit observation "Immunization Target Entry"
|elgaimpf-dataelement-380
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfstoff (Referenz)
|Verweist auf das Produkt, für das die Kontraindikation gilt
|consumable
|elgaimpf-dataelement-233
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfschema (Referenz)
|Referenz auf den der Kontraindikation zugrundeliegenden Impfplan, Fachinformation, Dokumentation, … 1. Nationaler Impfplan 2. Fachinformation (liegt derzeit nicht strukturiert vor) 3. Individuelle Konstellation des Impflings --> manueller Eintrag bei Impfung (Abhängig vom Produkt bzw "Impfung", wenn Kombinationspräparat)
|reference/externalDocument
|elgaimpf-dataelement-234
|- style="vertical-align:top;"
| style="padding-left: 15px" |Begründung
|Freitext zur Begründung einer vom Arzt eingetragenen Kontraindikation
|entryRelationship/@typeCode = "RSON" mit act "Comment Entry"
|elgaimpf-dataelement-171
|- style="vertical-align:top;"
|'''Impfrelevante Erkrankung'''
|Dokumentation von Infektionskrankheiten, die eine langfristige Immunisierung nach sich ziehen und daher eine weitere Impfung nicht notwendig machen. Die Eintragung erfolgt optional bei der Erhebung der Impfanamnese.
|Sektion "Impfrelevante Erkrankungen - kodiert" mit act "Impfrelevante Erkrankungen Problem Concern Entry"
|elgaimpf-dataelement-27
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfrelevante Erkrankung
|Impfrelevante Erkrankung (aus Auswahlkatalog, z.B. FSME, Varizellen, ...)
|Sektion "Impfrelevante Erkrankungen - kodiert" mit act "Impfrelevante Erkrankungen Problem Concern Entry"
|elgaimpf-dataelement-126
|- style="vertical-align:top;"
| style="padding-left: 15px" |Erkrankungsdatum
|Zeitintervall, in der die Erkrankung beobachtet wurde
|
|elgaimpf-dataelement-393
|- style="vertical-align:top;"
| style="padding-left: 15px" |Bemerkungen (Anmerkungen)
|Freitext für Eintragung des Nachweises der durchgemachten Erkrankung, z.B. durch Vorbefund oder Laborbefund mit Titer.
|observation "Impfrelevante Erkrankungen Problem Entry" mit entryRelationship act "Comment Entry"
|elgaimpf-dataelement-16
|- style="vertical-align:top;"
| style="padding-left: 15px" |Autor
|Erfasser der Information
|
|elgaimpf-dataelement-282
|- style="vertical-align:top;"
| style="padding-left: 15px" |Impfung (Referenz)
|Verknüpfung zu Impfung
|
|elgaimpf-dataelement-284
|- style="vertical-align:top;"
|'''Antikörper-Bestimmung (Impftiter)'''
|Ergebnisse von Antikörper-Untersuchungen, Antikörper Bestimmungen für für Virushepatitis A und B, Röteln und Varizellen etc.
|Sektion "Antikörper-Bestimmung" mit act "Lab Report Data Processing Entry" und entryRelationship "Laboratory Observation Entry"
|elgaimpf-dataelement-129
|- style="vertical-align:top;"
| style="padding-left: 15px" |Analyse
|Gemessener Laborparameter
|"Laboratory Observation Entry"
|elgaimpf-dataelement-271
|- style="vertical-align:top;"
| style="padding-left: 15px" |Wert
|Wert der Analyse
|"Laboratory Observation Entry" / value
|elgaimpf-dataelement-272
|- style="vertical-align:top;"
| style="padding-left: 15px" |Einheit
|Einheit des Messwerts. Muss in UCUM Notation angegeben werden
|"Laboratory Observation Entry" /value/@unit
|elgaimpf-dataelement-273
|- style="vertical-align:top;"
| style="padding-left: 15px" |Bewertung (Interpretation)
|Interpretations des Messwerts (Interpretationskennzeichen)
|"Laboratory Observation Entry" /interpretationCode
|elgaimpf-dataelement-274
|- style="vertical-align:top;"
| style="padding-left: 15px" |Datum
|Datum der Abnahme (wenn nicht vorhanden, Datum der Bestimmung)
|"Laboratory Observation Entry" /effectiveTime
|elgaimpf-dataelement-275
|- style="vertical-align:top;"
| style="padding-left: 15px" |Durchführendes Labor
|Durchführendes Labor
|"Laboratory Observation Entry" / performer
|elgaimpf-dataelement-276
|- style="vertical-align:top;"
| style="padding-left: 30px" |ID der Organisation
|
|
|elgaimpf-dataelement-277
|- style="vertical-align:top;"
| style="padding-left: 30px" |Name der Organisation
|
|
|elgaimpf-dataelement-278
|- style="vertical-align:top;"
| style="padding-left: 30px" |Telekom
|Weitere Kontaktdaten (Telefon, Handy, Email...)
|
|elgaimpf-dataelement-279
|- style="vertical-align:top;"
| style="padding-left: 30px" |Adresse
|Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...)
|
|elgaimpf-dataelement-280
|- style="vertical-align:top;"
|'''Informationsquelle'''
|Herkunft der Information
|
|elgaimpf-dataelement-11
|}

[https://art-decor.org/decor/services/RetrieveDataSet?id=1.2.40.0.34.777.4.1.1&language=de-DE&effectiveDate=2018-08-12T16:37:15&format=html&hidecolumns=3456bcdefghijklmno Link zum Dataset in Art-Decor]

=Technische Spezifikation=
==Übersicht CDA Struktur "Kompletter Immunisierungsstatus"==
Die Struktur des CDA Austauschformats ist in den nachfolgenden Kapiteln im Detail beschrieben. Zum schnellen Einstieg findet sich hier eine stark vereinfachte Zusammenfassung der Elemente.
Dieses Dokument kann von der zentralen Anwendung "e-Impfpass" angefragt werden. Es enthält alle gespeicherten Informationen zum Immunisierungsstatus der Person und wird jeweils aktuell erzeugt ("On-Demand-Dokument").

ELGA Interoperabilitätsstufen (EIS): Dieses Dokument existiert ausschließlich in einer voll strukturierten Form, eine Unterscheidung der Interoperabilitätsstufen ist daher nicht notwendig.

[[Datei:DLT_Grafik_KompletterImmunisierungsstatus.PNG|400px|CDA-Dokument in Ausprägung "Kompletter Immunisierungsstatus"]]

<ref group="Abbildung">CDA-Dokument in Ausprägung "Kompletter Immunisierungsstatus"</ref>
<div class="landscape">
===CDA Header===
Der Header enthält die (administrativen) Dokument-Metadaten
* '''Allgemeine Dokumentinformationen:''' Dokumenten-Id, Code, Titel, Erstellungszeitpunkt, Sprache, Version
* '''"Impfling"''' Angaben zur Person (Patient), deren Immunisierungsstatus beschrieben wird: Name, Geburtsdatum, Geschlecht, Identifikatoren, Adresse und Kontaktdaten, ...
* '''Mitwirkende am Dokument''': Autoren, Schreibkraft, Verwalter, Unterzeichner
* '''Related Document:''' Verweis auf ein allfällig ersetztes Dokument (Vorversion)

Der Header entspricht im Wesentlichen den bisherigen ELGA-CDA-Leitfäden ("Allgemeiner Leitfaden"). Für den e-Impfpass wurden punktuell Neuerungen eingeführt:
* TemplateIds für die Versionskennung
* Zusätzliches Translation-Element für den clinicalDocument.code

'''Hinweis''': Einige Header-Elemente des Allgemeinen Leitfadens werden hier nicht benötigt [NP], sind aber der Vollständigkeit halber angegeben. [NP]-Elemente dürfen nicht angegeben werden, bzw. sind zu ignorieren.
Beispiele: Data Enterer, Authorization, LegalAuthenticator, ...

===CDA Body===
Der "Structured Body" enthält die tatsächlichen (medizinischen) Inhalte des Dokuments
* Kapitel '''Impfungen''': Sammlung der dokumentierten Impfungen
** Impfung, Impfdatum, Impfstoff, Impfschema und Dosiskennung, medizinisch verantwortliche Person, Krankheit gegen welche die Impfung schützt, PZN, Chargennummer (LOT-Nr), Dosierung und weitere Angaben zur Verabreichung (Teilnehmende Personen)
* Kapitel '''Personengruppe''': Dokumentiert die Zugehörigkeit zu speziellen Personengruppen.
** Personengruppe, Datumsbereich der Zugehörigkeit zur Gruppe
* Kapitel '''Impfrelevante Erkrankungen''': Sammlung der dokumentierten impfrelevanten Erkrankungen
** Erkrankung, Datumsbereich
* Kapitel '''Antikörper-Untersuchungen''': Sammlung der dokumentierten Antikörper-Bestimmungen
** Untersuchung, Wert, Bewertung, Datum
* Kapitel '''Impfempfehlungen''': Sammlung der dokumentierten Impfempfehlungen (automatisch erstellte sowie vom Impfarzt individuell empfohlene)
** Strukturell wie Impfungen, mit anderen Pflichtfeldern und anderem Status
* Kapitel '''Beilagen''': digitalisierter Papierimpfpass als Attachment

Anmerkung: Impfreaktionen werden nicht unterstützt.

==Übersicht CDA Struktur "Update Immunisierungsstatus"==
Die Struktur des CDA Austauschformats ist in den nachfolgenden Kapiteln im Detail beschrieben. Zum schnellen Einstieg findet sich hier eine stark vereinfachte Zusammenfassung der Elemente.

Dieses Dokument wird vom impfenden GDA erstellt und an die zentrale Applikation gesendet. Es enthält die Informationen, die der GDA bei einem Besuch dokumentiert. Es kann Impfungen, Impfempfehlungen, impfrelevante Erkrankungen, Antikörperbestimmungen, etc enthalten.

ELGA Interoperabilitätsstufen (EIS): Dieses Dokument existiert ausschließlich in einer voll strukturierten Form, eine Unterscheidung der Interoperabilitätsstufen ist daher nicht notwendig.

[[Datei:DLT_Grafik_UpdateImmunisierungsstatus.PNG|400px|CDA-Dokument in Ausprägung "Update Immunisierungsstatus"]]

<ref group="Abbildung">CDA-Dokument in Ausprägung "Update Immunisierungsstatus"</ref>

===CDA Header===
Der Header enthält die (administrativen) Dokument-Metadaten
* '''Allgemeine Dokumentinformationen:''' Dokumenten-Id, Code, Titel, Erstellungszeitpunkt, Sprache, Version
* '''"Impfling"''' Angaben zur Person (Patient), deren Immunisierungsstatus beschrieben wird: Name, Geburtsdatum, Geschlecht, Identifikatoren, Adresse und Kontaktdaten, ...
* '''Mitwirkende am Dokument''': Autoren, Erfasser, Verwalter, Unterzeichner
* '''Related Document:''' Verweis auf ein allfällig ersetztes Dokument (Vorversion)

Der Header entspricht im Wesentlichen den bisherigen ELGA-CDA-Leitfäden ("Allgemeiner Leitfaden"). Für den e-Impfpass wurden punktuell Neuerungen eingeführt:
* TemplateIds für die Versionskennung
* Zusätzliches Translation-Element für den clinicalDocument.code

===CDA Body===
Der "Structured Body" enthält die tatsächlichen (medizinischen) Inhalte des Dokuments
* Kapitel '''Impfungen''': Sammlung der dokumentierten Impfungen
** Impfung, Impfdatum, Impfstoff, Impfschema und Dosiskennung, medizinisch verantwortliche Person, Krankheit gegen welche die Impfung schützt, PZN, Chargennummer (LOT-Nr), Dosierung und weitere Angaben zur Verabreichung (Teilnehmende Personen)
* Kapitel '''Personengruppe''': Dokumentiert die Zugehörigkeit zu speziellen Personengruppen.
** Personengruppe, Datumsbereich der Zugehörigkeit zur Gruppe
* Kapitel '''Impfrelevante Erkrankungen''': Sammlung der dokumentierten impfrelevanten Erkrankungen
** Erkrankung, Datumsbereich
* Kapitel '''Antikörper-Bestimmungen''': Sammlung der dokumentierten Laboruntersuchungen der impfrelevanten Antikörper ("Impftiter")
** Untersuchung, Wert, Bewertung, Datum
* Kapitel '''Impfempfehlungen''': Vom Impfarzt individuell empfohlene Impfungstermine, wenn abweichend von den automatisch erstellten Impfempfehlungen
** Strukturell wie Impfungen, mit anderen Pflichtfeldern und anderem Status

Anmerkung: Impfreaktionen werden nicht unterstützt.

==Übersicht der Strukturen mit Konformität und Kardinalität==
Folgende Tabellen sollen einen groben Überblick über die Inhalte der einzelnen Sektionen geben. Details sind den entsprechenden Templates zu entnehmen.

===Sektion Impfungen - kodiert===
'''1. Dokumentation einer Impfung''':

*Kompletter Immunisierungsstatus: Impfung wird angezeigt.
*Update Immunisierungsstatus: Neue Impfung wird durchgeführt.
*Update Nachtrag Immunisierungsstatus: Nachtrag einer bereits durchgeführten Impfung.

''Anmerkung'': Entweder-Oder-Auswahlmöglichkeiten sind mit "#)" gekennzeichnet.

{| class="wikitable"
! colspan="3" style="width: 70%" |Sektion Impfungen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="3" |SECTION Impfungen - kodiert (1.2.40.0.34.6.0.11.2.1)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="2" |Immunization Entry (1.2.40.0.34.6.0.11.3.1)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
|#) Vaccine Product (1.2.40.0.34.6.0.11.9.32)
|C [0..1]
|M [1..1]
|C [0..1]
|-
|
|
|#) Vaccine Product nicht angegeben (1.2.40.0.34.6.0.11.9.31)
|C [0..1]
|NP [0..0]
|C [0..1]
|-
|
|
|Performer Body - Impfende Person (1.2.40.0.34.6.0.11.9.21) ''Impfende Person''
|C [0..1]
|C [0..1]
|O [0..1]
|-
|
|
|Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8) ''Medizinisch verantwortliche Person''
|C [0..1]
|M [1..1]
|O [0..1]
|-
|
|
|Informant Body (1.2.40.0.34.6.0.11.9.3) ''Bürger (bei Selbsteintragung)''
|C [0..1]
|C [0..1]
|NP [0..0]
|-
|
|
|Participant Body - Transcriber (1.2.40.0.34.6.0.11.9.14) ''Nachtragende Person''
|C [0..1]
|NP [0..0]
|M [1..1]
|-
|
|
|Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) ''Korrigierende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) ''Berechtigter Bearbeiter''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) ''Eintragende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|Immunization Target Entry (1.2.40.0.34.6.0.11.3.2)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
|Immunization Billability Entry (1.2.40.0.34.6.0.11.3.5)
|NP [0..0]
|O [0..1]
|NP [0..0]
|-
|
|
|Zusatzklassifikation (1.2.40.0.34.6.0.11.3.168) ''Impfsetting''
|R [0..*]
|R [0..*]
|R [0..*]
|-
|
|
|External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf zugrundeliegendes Update-Dokument''
|M [1..1]
|R [0..1]
|R [0..1]
|-
|
|
|External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf das Impfzertifikat''
|R [0..1]
|R [0..1]
|R [0..1]
|-
|
|
|Immunization Schedule Entry (1.2.40.0.34.6.0.11.3.10) ''Impfschema''
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="2" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|Author Body (1.2.40.0.34.6.0.11.9.36)
|R [0..*]
|R [0..*]
|R [0..*]
|-
|
|
|Informant Body (1.2.40.0.34.6.0.11.9.3)
|R [0..*]
|R [0..*]
|R [0..*]
|}

'''2.''' Es wird '''keine Impfung''' durchgeführt, sondern z.B. eine Krankheit eingetragen.

{| class="wikitable"
! colspan="3" style="width: 70%" |Sektion Impfungen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="3" |SECTION Impfungen - kodiert (1.2.40.0.34.6.0.11.2.1)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="2" |Immunization Entry Impfung nicht angegeben (1.2.40.0.34.6.0.11.3.28)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
|Vaccine Product nicht angegeben (1.2.40.0.34.6.0.11.9.31)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="2" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) ''(siehe Sektion Impfungen)''
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Expositionsrisiko Personengruppen - kodiert===
{| class="wikitable"
! colspan="4" style="width: 70%" |Sektion Expositionsrisiko Personengruppen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="4" |SECTION Expositionsrisiko Personengruppen - kodiert (1.2.40.0.34.6.0.11.2.4)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="3" |Expositionsrisiko Problem Concern Entry (1.2.40.0.34.6.0.11.3.20)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
| colspan="2" |Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
| colspan="2" |Expositionsrisiko Problem Entry (1.2.40.0.34.6.0.11.3.21)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
|
|Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) ''Korrigierende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
|Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) ''Berechtigter Bearbeiter''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
|Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) ''Eintragende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
| colspan="2" |External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf zugrundeliegendes Update-Dokument''
|M [1..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="3" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) ''(siehe Sektion Impfungen)''
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Impfrelevante Erkrankungen - kodiert===
{| class="wikitable"
! colspan="5" style="width: 70%" |Sektion Impfrelevante Erkrankungen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="5" |SECTION Impfrelevante Erkrankungen - kodiert (1.2.40.0.34.6.0.11.2.5)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="4" |Impfrelevante Erkrankungen Problem Concern Entry (1.2.40.0.34.6.0.11.3.8)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
| colspan="3" |Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
| colspan="3" |Impfrelevante Erkrankungen Problem Entry (1.2.40.0.34.6.0.11.3.9)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
|
| colspan="2" |Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) ''Korrigierende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
| colspan="2" |Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) ''Berechtigter Bearbeiter''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
| colspan="2" |Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) ''Eintragende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
| colspan="2" |Comment Entry (1.2.40.0.34.6.0.11.3.11)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
|
|
|Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|C [0..1]
|C [0..1]
|C [0..1]
|-
|
|
|
|
|Informant Body (1.2.40.0.34.6.0.11.9.3)
|C [0..1]
|C [0..1]
|C [0..1]
|-
|
|
| colspan="3" |External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf zugrundeliegendes Update-Dokument''
|M [1..1]
|R [0..1]
|R [0..1]
|-
|
|
| colspan="3" |External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf das Impfzertifikat''
|R [0..1]
|R [0..1]
|R [0..1]
|-
|
| colspan="4" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) ''(siehe Sektion Impfungen)''
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Antikörper-Bestimmung - kodiert===
{| class="wikitable"
! colspan="6" style="width: 70%" |Sektion Antikörper-Bestimmung
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="6" |SECTION Antikörper-Bestimmung - kodiert (1.2.40.0.34.6.0.11.2.7)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="5" |Antikörper-Bestimmung Data Processing Entry (1.2.40.0.34.6.0.11.3.15)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
| colspan="4" |Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
| colspan="4" |Antikörper-Bestimmung Battery Organizer (1.2.40.0.34.6.0.11.3.18)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
|
| colspan="3" |Antikörper-Bestimmung Laboratory Observation Entry (1.2.40.0.34.6.0.11.3.16)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|
|
| colspan="2" |Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) ''Korrigierende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
|
| colspan="2" |Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) ''Berechtigter Bearbeiter''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
|
| colspan="2" |Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) ''Eintragende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
|
|
| colspan="2" |Comment Entry (1.2.40.0.34.6.0.11.3.11) ''siehe Sektion Impfrelevante Erkrankungen''
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
|
|
| colspan="2" |Participant ''(Validierende Person)''
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
|
|
| colspan="2" |Performer Body - Laboratory (1.2.40.0.34.6.0.11.9.28) ''Externes Labor''
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
| colspan="4" |External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf zugrundeliegendes Update-Dokument''
|M [1..1]
|O [0..1]
|O [0..1]
|-
|
|
| colspan="4" |External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf das Impfzertifikat''
|R [0..1]
|R [0..1]
|R [0..1]
|-
|
| colspan="5" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) ''(siehe Sektion Impfungen)''
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Impfempfehlungen - kodiert===
{| class="wikitable"
! colspan="4" style="width: 70%" |Sektion Impfempfehlungen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="4" |SECTION Impfempfehlungen - kodiert (1.2.40.0.34.6.0.11.2.2)
|R [1..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="3" |Immunization Recommendation Entry (1.2.40.0.34.6.0.11.3.3)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
| colspan="2" |#) Vaccine Product (1.2.40.0.34.6.0.11.9.32)
|C [0..1]
|C [0..1]
|C [0..1]
|-
|
|
| colspan="2" |#) Vaccine Product nicht angegeben (1.2.40.0.34.6.0.11.9.31)
|C [0..1]
|C [0..1]
|C [0..1]
|-
|
|
| colspan="2" |Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8) ''Medizinisch verantwortliche Person''
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
| colspan="2" |Participant Body - Verifier (1.2.40.0.34.6.0.11.9.44) ''Korrigierende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
| colspan="2" |Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) ''Berechtigter Bearbeiter''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
| colspan="2" |Participant Body - Data Enterer (1.2.40.0.34.6.0.11.9.47) ''Eintragende Person''
|C [0..1]
|NP [0..0]
|NP [0..0]
|-
|
|
| colspan="2" |Immunization Target Entry (1.2.40.0.34.6.0.11.3.2)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
| colspan="2" |Comment Entry (1.2.40.0.34.6.0.11.3.11) ''siehe Sektion Impfrelevante Erkrankungen''
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
| colspan="2" |Impfplan Entry (1.2.40.0.34.6.0.11.3.22)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
| colspan="2" |External Document Entry (1.2.40.0.34.6.0.11.3.14) ''Referenz auf zugrundeliegendes Update-Dokument''
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
| colspan="2" |Immunization Schedule Entry (1.2.40.0.34.6.0.11.3.10) ''Impfschema''
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="3" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8) ''(siehe Sektion Impfungen)''
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Beilagen===
{| class="wikitable"
! colspan="3" style="width: 70%" |Sektion Beilagen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="3" |SECTION Beilagen (1.2.40.0.34.6.0.11.2.71)
|O [0..1]
|R [0..1]
|O [0..1]
|-
|
| colspan="2" |Eingebettetes Objekt Entry (1.2.40.0.34.6.0.11.3.19)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
|Author Body (1.2.40.0.34.6.0.11.9.36)
|C [0..1]
|C [0..1]
|C [0..1]
|-
|
|
|Informant Body (1.2.40.0.34.6.0.11.9.3)
|C [0..1]
|C [0..1]
|C [0..1]
|}

==CDA Templates==

===Document Level Templates===
====Kompletter Immunisierungsstatus====
{{:1.2.40.0.34.6.0.11.0.4/dynamic}}
====Update Immunisierungsstatus====
{{:1.2.40.0.34.6.0.11.0.2/dynamic}}

===Header Level Templates===
==== Document Realm ====
{{:1.2.40.0.34.6.0.11.1.10/dynamic}}
====Document TypeId====
{{:1.2.40.0.34.6.0.11.1.30/dynamic}}
==== Document Id ====
{{:1.2.40.0.34.6.0.11.1.1/dynamic}}
==== Document Effective Time ====
{{:1.2.40.0.34.6.0.11.1.11/dynamic}}
==== Document Confidentiality Code ====
{{:1.2.40.0.34.6.0.11.1.12/dynamic}}
==== Document Language ====
{{:1.2.40.0.34.6.0.11.1.13/dynamic}}
==== Document Set Id and Version Number ====
{{:1.2.40.0.34.6.0.11.1.15/dynamic}}
====Record Target - e-Impfpass====
{{:1.2.40.0.34.6.0.11.1.31/dynamic}}
====Author====
{{:1.2.40.0.34.6.0.11.1.2/dynamic}}
==== Data Enterer====
{{:1.2.40.0.34.6.0.11.1.22/dynamic}}
====Custodian====
{{:1.2.40.0.34.6.0.11.1.4/dynamic}}
====Legal Authenticator====
{{:1.2.40.0.34.6.0.11.1.5/dynamic}}
==== Information Recipient ====
Wird nicht verwendet.
====Participant ====
Folgende Participants werden nicht verwendet:
*Ein-, Ueber-, Zuweisender Arzt
*Hausarzt
*Auskunftsberechtigte Person (Notfallkontakt)
*Angehörige
*Versicherung
*Wird nicht verwendet.
*Betreuungsorganisation
*Weitere Behandler
====In Fulfillment Of ====
Wird nicht verwendet.
====Documentation Of Service Event - e-Impfpass ====
{{:1.2.40.0.34.6.0.11.1.32/dynamic}}

====Document Replacement - Related Document ====
{{:1.2.40.0.34.6.0.11.1.14/dynamic}}
====Authorization ====
Wird nicht verwendet.
====Component Of - Encompassing Encounter ====

{{:1.2.40.0.34.6.0.11.1.7/static-2019-03-07T104449}}

====Encounter Location====
{{:1.2.40.0.34.6.0.11.1.8/static-2019-03-07T111321}}

===Section Level Templates===
====Impfungen - kodiert====
{{:1.2.40.0.34.6.0.11.2.1/dynamic}}
====Expositionsrisiko Personengruppen - kodiert ====
{{:1.2.40.0.34.6.0.11.2.4/dynamic}}

====Impfrelevante Erkrankungen - kodiert====
{{:1.2.40.0.34.6.0.11.2.5/dynamic}}
====Antikörper-Bestimmung====
{{:1.2.40.0.34.6.0.11.2.7/dynamic}}
====Impfempfehlungen - kodiert====
{{:1.2.40.0.34.6.0.11.2.2/dynamic}}
====Beilagen====
{{:1.2.40.0.34.6.0.11.2.71/dynamic}}

====Übersetzung (informativ)====
{{:1.2.40.0.34.6.0.11.2.8/dynamic}}

===Entry Level Template===
====Antikörper-Bestimmung Battery Organizer====
{{:1.2.40.0.34.6.0.11.3.18/dynamic}}
====Antikörper-Bestimmung Data Processing Entry ====
{{:1.2.40.0.34.6.0.11.3.15/dynamic}}
====Antikörper-Bestimmung Laboratory Observation Entry ====
{{:1.2.40.0.34.6.0.11.3.16/dynamic}}
====Comment Entry====
{{:1.2.40.0.34.6.0.11.3.11/dynamic}}
====Eingebettetes Objekt Entry====
{{:1.2.40.0.34.6.0.11.3.19/dynamic}}
==== Expositionsrisiko Problem Concern Entry====
{{:1.2.40.0.34.6.0.11.3.20/dynamic}}
==== Expositionsrisiko Problem Entry====
{{:1.2.40.0.34.6.0.11.3.21/dynamic}}
====External Document Entry ====
{{:1.2.40.0.34.6.0.11.3.14/dynamic}}
====Immunization Billability Entry ====
{{:1.2.40.0.34.6.0.11.3.5/dynamic}}
====Immunization Entry====
{{:1.2.40.0.34.6.0.11.3.1/dynamic}}
====Immunization Entry Impfung nicht angegeben====
{{:1.2.40.0.34.6.0.11.3.28/dynamic}}
====Immunization Recommendation Entry ====
{{:1.2.40.0.34.6.0.11.3.3/dynamic}}
====Immunization Schedule Entry ====
{{:1.2.40.0.34.6.0.11.3.10/dynamic}}
====Immunization Target Entry====
{{:1.2.40.0.34.6.0.11.3.2/dynamic}}
====Impfplan Entry====
{{:1.2.40.0.34.6.0.11.3.22/dynamic}}
====Impfrelevante Erkrankungen Problem Concern Entry ====
{{:1.2.40.0.34.6.0.11.3.8/dynamic}}
====Impfrelevante Erkrankungen Problem Entry====
{{:1.2.40.0.34.6.0.11.3.9/dynamic}}
====Vaccine Product ====
{{:1.2.40.0.34.6.0.11.9.32/dynamic}}
====Vaccine Product nicht angegeben ====
{{:1.2.40.0.34.6.0.11.9.31/dynamic}}
====Zusatzklassifikation (für Impfungen)====
{{:1.2.40.0.34.6.0.11.3.168/dynamic}}

===Weitere CDA Fragmente ===
====Address Compilation====
{{:1.2.40.0.34.6.0.11.9.25/dynamic}}
====Address Compilation Minimal====
{{:1.2.40.0.34.6.0.11.9.10/dynamic}}
====Assigned Entity====
{{:1.2.40.0.34.6.0.11.9.22/dynamic}}
====Assigned Entity Body====
{{:1.2.40.0.34.6.0.11.9.16/dynamic}}
====Assigned Entity Body with name, addr and telecom====
{{:1.2.40.0.34.6.0.11.9.29/dynamic}}
====Author Body ====
{{:1.2.40.0.34.6.0.11.9.36/dynamic}}
====Author Body - eImpfpass====
{{:1.2.40.0.34.6.0.11.9.8/dynamic}}
====Date Interval Information minimal====
{{:1.2.40.0.34.6.0.11.9.35/dynamic}}
====Device Compilation====
{{:1.2.40.0.34.6.0.11.9.18/dynamic}}
====Informant Body====
{{:1.2.40.0.34.6.0.11.9.3/dynamic}}
====Narrative Text Reference====
{{:1.2.40.0.34.6.0.11.9.1/dynamic}}
====Organization Compilation with id, name====
{{:1.2.40.0.34.6.0.11.9.5/dynamic}}
====Organization Compilation with id, name, tel, addr====
{{:1.2.40.0.34.6.0.11.9.7/dynamic}}
====Organization Compilation with name====
{{:1.2.40.0.34.6.0.11.9.9/dynamic}}
====Organization Compilation with name, addr minimal ====
{{:1.2.40.0.34.6.0.11.9.20/dynamic}}
====Organization Name Compilation ====
{{:1.2.40.0.34.6.0.11.9.27/dynamic}}
====Original Text Reference====
{{:1.2.40.0.34.6.0.11.9.2/dynamic}}
====Participant Body====
{{:1.2.40.0.34.6.0.11.9.13/dynamic}}
====Participant Body - Transcriber ====
{{:1.2.40.0.34.6.0.11.9.14/dynamic}}
====Participant Body - Verifier ====
{{:1.2.40.0.34.6.0.11.9.44/dynamic}}
====Participant Body - Authorized Editor====
{{:1.2.40.0.34.6.0.11.9.46/dynamic}}

====Participant Body - Data Enterer====
{{:1.2.40.0.34.6.0.11.9.47/dynamic}}

====Performer Body====
{{:1.2.40.0.34.6.0.11.9.17/dynamic}}
====Performer Body - Impfende Person====
{{:1.2.40.0.34.6.0.11.9.21/dynamic}}
====Performer Body - Laboratory====
{{:1.2.40.0.34.6.0.11.9.28/dynamic}}
====Person Name Compilation G1====
{{:1.2.40.0.34.6.0.11.9.26/dynamic}}
====Person Name Compilation G1 M====
{{:1.2.40.0.34.6.0.11.9.12/dynamic}}
====Person Name Compilation G2====
{{:1.2.40.0.34.6.0.11.9.6/dynamic}}
====Person Name Compilation G2 M====
{{:1.2.40.0.34.6.0.11.9.11/dynamic}}
====Time Interval Information minimal====
{{:1.2.40.0.34.6.0.11.9.15/dynamic}}

</div class="landscape">

==Terminologien==
Die für den kompletten Immunisierungsstatus und für das Update erforderlichen Terminologien sind im Folgenden aufgelistet. Achtung: Codelisten und Value Sets können weitere Attribute benötigen, die hier nicht darstellbar sind. Diese können jedoch vom Terminologieserver abgerufen werden: https://termpub.gesundheit.gv.at

* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=2.16.840.1.113883.1.11.20025 ActStatusCompleted]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.10 atcdabbr_LanguageCode]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.11 atcdabbr_LanguageCode]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.13 eImpf_Antikoerperbestimmung_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.10 eImpf_HistorischeImpfstoffe_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.4 eImpf_ImmunizationTarget_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.6 eImpf_Impfdosis_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.7 eImpf_Impfgrund_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.2 eImpf_ImpfrelevanteErkankungen_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.11 eImpf_Impfrollen_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.5 eImpf_Impfschema_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.14 eImpf_Impfstoffe_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.3 eImpf_SpecialCaseVaccination_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.15 eImpf_SpecialSituationIndication_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.62 eImpf_Zusatzklassifikation_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.5 ELGA_ActEncounterCode]
* [https://art-decor.org/art-decor/decor-valuesets--elga-?id=1.2.40.0.34.10.16 ELGA_AddressUse]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.4 ELGA_AdministrativeGender ]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.6 ELGA_AuthorSpeciality]
* [https://art-decor.org/art-decor/decor-valuesets--elgabbr-?id=1.2.40.0.34.10.39 ELGA_Dokumentenklassen]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier_VS]
* [https://art-decor.org/art-decor/decor-valuesets--elga-?id=1.2.40.0.34.10.27 ELGA_EntityNameUse]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.173 ELGA_HumanLanguage]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.42 ELGA_Medientyp]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.32 ELGA_MedikationMengenart_VS]
**Gültige UCUM-Einheit, siehe Terminologieserver. Beispiele:
*** <nowiki>{Stueck}</nowiki> oder <nowiki>{Packung}</nowiki> - vollständige Verabreichung einer Fertigspritze
*** <nowiki>ml</nowiki> - für eine abweichende Dosis angegeben in Volumseinheiten
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ ]
* [https://art-decor.org/art-decor/decor-valuesets--elga-?id=1.2.40.0.34.10.2 ELGA_NullFlavor]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.13 ELGA_ObservationInterpretation]
**Für die Antikörperbestimmung (Impftiter) im e-Impfpass kommen die Werte aus dem Knoten ''_ObservationInterpretationDetection'' zum Einsatz.
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.17 ELGA_PersonalRelationship]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=1.2.40.0.34.10.43 ELGA_ServiceEventPerformer]
* [https://art-decor.org/art-decor/decor-valuesets--elga-?id=1.2.40.0.34.10.36 ELGA_TelecomAddressUse]
* [https://art-decor.org/art-decor/decor-valuesets--elga-?id=1.2.40.0.34.10.25 ELGA_URLScheme]
* [https://art-decor.org/art-decor/decor-valuesets--elga-?id=1.2.40.0.34.10.73 ELGA_whoATC]
* ELGA_Wirkstoffe_AGES_VS
**Siehe Terminologieserver
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=2.16.840.1.113883.1.11.16040 EntityCode]
* [https://art-decor.org/art-decor/decor-valuesets--elgaimpf-?id=2.16.840.1.113883.1.11.10901 ParticipationType]

<div class="portrait">

=Anhang=
==Abbildungen==
<references group="Abbildung"/>
==Tabellen==
<references group="Tabelle" />
==Abkürzungsverzeichnis==
{{ILF:Abkuerzungsverzeichnis}}

==Literaturverzeichnis==
<references />
</div>

==Revisionsliste==
===Nebenversionen===
====Nebenversion 1.3.0+20220127====
=====Participant Body - Data Enterer 1.2.40.0.34.6.0.11.9.47=====
Das Template "Participant Body - Data Enterer" wurde erstellt, damit der Data Enterer aus dem Update Immunisierungsstatus im Kompletten Immunisierungsstatus in die Entries (Immunization Entry, Immunization Recommendation Entry, Impfrelevante Erkrankungen Problem Entry) übernommen werden kann.
=====Expositionsrisiko Problem Entry 1.2.40.0.34.6.0.11.3.21=====
Dem Entry wurden die Participants "Participant Body - Verifier" (1.2.40.0.34.6.0.11.9.44), "Participant Body - Authorized Editor" (1.2.40.0.34.6.0.11.9.46) und "Participant Body - Data Enterer" (1.2.40.0.34.6.0.11.9.47) hinzugefügt.
=====Antikörper-Bestimmung Laboratory Observation Entry 1.2.40.0.34.6.0.11.3.16=====
Dem Entry wurde der Participants "Participant Body - Data Enterer" (1.2.40.0.34.6.0.11.9.47) hinzugefügt.

====Nebenversion 1.2.0+20220103====
======DLT Kompletter Immunisierungsstatus 1.2.40.0.34.6.0.11.0.4======
Anpassungen betreffend neuem Anwendungsfall U2.5 "Selbsteintragung von Impfungen durch den Bürger":
* neue Sektion Beilagen 0..1 ergänzt

=====DLT Update Immunisierungsstatus 1.2.40.0.34.6.0.11.0.2=====
Ergänzung von Constraints betreffend neuem Anwendungsfall U2.5 "Selbsteintragung von Impfungen durch den Bürger":
* Author: Bei Selbsteintragung wird die Software als Author angegeben
* DataEnterer: Änderung von 0..1 auf 0..1 C + Constraint: Bei Selbsteintragung muss der Bürger als DataEnterer angegeben werden
* neue Sektion Beilagen 0..1 + Constraint: Bei Selbsteintragung muss der Bürger als Informant angegeben werden
* folgende Sektionen wurden von 0..1 auf 0..1 C gesetzt + Constraint (Bei Selbsteintragung sind die Sektionen verboten):
** Expositionsrisiko Personengruppen
** Impfrelevante Erkrankungen
** Antikörper-Bestimmung
** Impfempfehlungen

=====Immunization Recommendation Entry 1.2.40.0.34.6.0.11.3.3 =====
Angabe von Kontraindikationen ermöglicht (Empfehlung, keine Impfung durchzuführen). Wird im Update Immunisierungsstatus mit @negationInd="true" angezeigt. Im Kompletten Immunisierungsstatus wird eine entsprechender Code für eine Handlungsempfehlung automatisch hinzugefügt.

=====Performer Body - Impfende Person 1.2.40.0.34.6.0.11.9.21=====
Template-Beschreibung angepasst

===== '''Author 1.2.40.0.34.6.0.11.1.2''' =====
Erweiterung des Constraints, sodass wenn Author ein/e Software/Gerät ist und keine OID aus dem GDA-I angegeben werden kann, die Angaben der Organisation des Geräte-/Software-Betreibers oder Herstellers entsprechen müssen.

===== Participant Body - Verifier 1.2.40.0.34.6.0.11.9.44 =====
"Korrigierende Person" neu hinzugefügt

===== Participant Body - Authorized Editor (1.2.40.0.34.6.0.11.9.46) =====
''Berechtigter Bearbeiter'' neu hinzugefügt

=====Participant Body - Transcriber 1.2.40.0.34.6.0.11.9.14=====
Angabe der Organisation als scopingEntity.desc für Transcriber ermöglicht

===== Informant Body 1.2.40.0.34.6.0.11.9.3 =====
* informant/relatedEntity/ @classCode ergänzt: 1..1 F "PRS"
* Beispiel korrigiert

=====Vaccine Product 1.2.40.0.34.6.0.11.9.32=====
* code/@nullFlavor-Assert zusätzlich als narrativer Constraint formuliert
* translation/@displayname 0..1 (Zulassungsname) ergänzt
* Beispielkorrektur

=====Impfrelevante Erkrankungen Problem Concern Entry 1.2.40.0.34.6.0.11.3.8=====
author von 0..1 C auf 1..1 R gesetzt, Constraint angepasst

=====Impfrelevante Erkrankungen Problem Entry1.2.40.0.34.6.0.11.3.9=====
* Anpassung: Es wird nur ein 0..1 Comment Entry mit 0..1 Author den Kompletten Immunisierungsstatus übernommen.
* Korrigierende Person 0..1 C ergänzt

=====Immunization Entry 1.2.40.0.34.6.0.11.3.1=====
* Informant wurde 0..1 C eingefügt, Constraint ergänzt (bei Selbsteintragung Informant verpflichtend, sonst NP)
* Anpassung Constraint Author: Bei Selbsteintragung und Update (ohne Nachtrag): Author 1..1 M
* Anpassung Constraint participant Transcriber: Bei Selbsteintragung Transcriber verboten (NP)
* Korrigierende Person 0..1 C ergänzt
* Zusatzklassifikation: Constraint entfernt
* /doseQuantity: Korrektur der Beschreibung zur Mengenangabe der verabreichten Arzneispezialität

=====Immunization Recommendation Entry 1.2.40.0.34.6.0.11.3.3=====
* Anpassung: Es wird nur ein 0..1 Comment Entry mit 0..1 Author in den Kompletten Immunisierungsstatus übernommen.
* Korrigierende Person 0..1 C ergänzt

=====Immunization Schedule Entry 1.2.40.0.34.6.0.11.3.10=====
* Bezeichnung "Impfkonzept" ersetzt durch "Impfschema", Beispielkorrektur Dosis,
* value-Constraint bezüglich Selbsteintragung angepasst.

=====Immunization Target Entry 1.2.40.0.34.6.0.11.3.2=====
Beispielkorrektur

=====Expositionsrisiko Problem Entry 1.2.40.0.34.6.0.11.3.21=====
Beispielkorrektur

=====Expositionsrisiko Problem Concern Entry 1.2.40.0.34.6.0.11.3.20=====
Anpassung author von 0..1 C auf 1..1 M

=====Antikörper-Bestimmung Laboratory Observation Entry 1.2.40.0.34.6.0.11.3.16=====
* Anpassung: Es wird nur ein 0..1 Comment Entry mit 0..1 Author den Kompletten Immunisierungsstatus übernommen.
* Korrigierende Person 0..1 C ergänzt
* Beispiel hinzugefügt, wie ein Testname und Testhersteller für einen Antikörpertest angegeben werden können
* code/@codeSystemName ist nicht mehr verpflichtend anzugeben

=====Beilagen 1.2.40.0.34.6.0.11.2.71=====
Selbsteintragung durch Bürger: Sektion für Multimedia-Attachments hinzugefügt.

=====Leitfaden diverse Kapitel=====
* 3.1 Verbindlichkeit: Ergänzung von Hinweisen auf EU-Recht u. GTelG
* 3.1. und 9.1 Übersicht über vorhandene Akteure und Komponenten: Hinweise auf Pilotprojekt entfernt
* 8.4. Impfempfehlungen: Ergänzung Hinweis für individuelle Impfempfehlungen und Definition "Handlungsempfehlung"
* 8.4.1. Sonderform: Empfehlung, keine Impfung durchzuführen (Kontraindikation)
* 9 User Storys ("Anwendungsfälle"): U2.2 "Korrektur eines Immunisierungseintrags" und U4 "Datenkorrektur durch Behörde" verbessert, Selbsteintragung durch
Bürger: U2.5 "Selbsteintragung von Impfungen durch den Bürger" hinzugefügt.
* 5 Begriffsdefinitionen
** Korrektur "Kostenloses Kinderimpfkonzepte" in "Kostenfreies Kinderimpfprogramm"
** "Hersteller" - eine Definition des Herstellers (Zulassungsinhabers) von Impfstoffen wurde hinzugefügt.
** "Nachtragende Person" - die Definition der nachtragenden Person wurde verbessert.
* 10 Datenarten:
** "Reaktion" auf den korrekten Platz bei Impfung verschoben und zur Verdeutlichung in "Impfreaktion" umbenannt.
** "Korrigierende Person" hinzugefügt
** "Berechtigter Bearbeiter" hinzugefügt
* 11.3 Übersicht der Strukturen mit Konformität und Kardinalität: Korrekturen Kardinalität/Konformität
* 11.5 Terminologien: Value Sets werden nur noch verlinkt
* 12.4 Literaturverzeichnis: Defekte Links korrigiert

====Nebenversion 1.1.1+20210601====
{| class="wikitable"
|Schlüssel
|Zusammenfassung
|<nowiki>Typ</nowiki>
|-
|
|"Begriffsdefinition Nachtragende Person" - die Definition der nachtragenden Person wurde verbessert.
|Verbesserung
|-
|
|"Begriffsdefinition Hersteller" - eine Definition des Herstellers (Zulassungsinhabers) von Impfstoffen wurde hinzugefügt.
|Verbesserung
|-
|
|"11.4.4.17 Antikörper-Bestimmung Laboratory Observation Entry" - Beispiel hinzugefügt, wie ein Testname und Testhersteller für einen Antikörpertest angegeben werden können.
|Verbesserung
|}

====Nebenversion 1.1.0+20210512====
{| class="wikitable"
|Schlüssel
|Zusammenfassung
|<nowiki>Typ</nowiki>
|-
|ELGA-1100
|"Zusatzklassifikation" (1.2.40.0.34.6.0.11.3.168) / : Optionale Zusatzklassifikation einer Impfung für Aufnahme von "Impfsetting" etc hinzugefügt
|Verbesserung
|-
|ELGA-1024
|"Immunization Entry" (1.2.40.0.34.6.0.11.3.1) / : Präzision der Datumsangabe bei Impfungen - nur Nachtragungen können mit unscharfen Datumsangaben eingetragen werden
|Verbesserung
|-
|ELGA-1082
|Dataset Impfgrund / : Impfindikation=Impfgrund für Abrechnung - Beschreibung verbessert
|Verbesserung
|-
|ELGA-827
|"Immunization Recommendation Entry" (1.2.40.0.34.6.0.11.3.3) / : Impfempfehlung: Die zu verabreichende Dosis (Menge) kann nun bei der Empfehlung angegeben werden.
|Verbesserung
|-
|ELGA-734
|Referenz für Impfzertifikat, Genesungs- und Testzertifikat (1.2.40.0.34.6.0.11.3.14) / : Optional kann nun auch ein Internet-Link auf ein extern gespeichertes Zertifikat (PDF-Dokument) mit gespeichert werden
|Verbesserung
|-
|
|Verbesserungen von Beschreibungen: Definition "Nachtragen", "Impfort", Laboratory Observation observation/referenceRange
|Verbesserung
|-
|ELGA-734
|"External Document Entry" (1.2.40.0.34.6.0.11.3.14) / Dokumentenklassifikation: Einschränkung auf LOINC entfernt
|Verbesserung
|-
|ELGA-728
|"Informant Body" (1.2.40.0.34.6.0.11.9.3): addr: Ergänzung Compilation, telecom: Attribute, Ergänzung Value Sets und Constraint
|Verbesserung
|-
|ELGA-724
|"Immunization Recommendation Entry" ([[#Immunization_Recommendation_Entry|1.2.40.0.34.6.0.11.3.3]]): Kardinalität von Comment Entry (1.2.40.0.34.6.0.11.3.11) von 0..1 auf 0..* korrigiert, da mehrfach benötigt
|Fehler
|-
|ELGA-719
|In der Impfempfehlungslogik werden nicht einzelne Handelsprodukte mit PZN vorgeschlagen, sondern die Zulassungsnummer.

Es ist daher notwendig, dass es eine Möglichkeit gibt, die Zulassungsnummer alleine im Template "Vaccine Product" (1.2.40.0.34.6.0.11.9.32) anzugeben:

/code mit der PZN von [M] zu [R] geändert, dabei MUSS NullFlavor="OTH" angeführt sein.

/code/translation darf mehrfach vorkommen und trägt die Zulassungsnummer.

|Fehler
|-
|ELGA-717
|"Immunization Recommendation Entry" (1.2.40.0.34.6.0.11.3.3): Optionalität von code/@displayName und code/@codeSystemName
entspricht den Datentyp-Vorgaben für CD und wird daher nicht redundant modelliert. Daher entfernt.
|Verbesserung
|-
|ELGA-716
|Beschreibung, dass passive Immunisierung und "Allergieimpfungen" nicht unterstützt werden, wurde hinzugefügt
|Verbesserung
|-
|ELGA-715
|"Antikörper-Bestimmung Laboratory Observation Entry" (1.2.40.0.34.6.0.11.3.16): ReferenceRange Datentyp geändert
|Fehler
|-
|
|Kapitel "Wichtige unterstützende Materialien" wurde umbenannt in "Wichtige unterstützende Materialien" und ergänzt mit Link zu Beispielbefunden, Schematron-Prüfregeln, PDF-Version des Leitfadens
|Verbesserung
|-
|
|Dataset-Elemente des Headers wurden in den Templates referenziert/gemappt (rein informativ).
|Verbesserung
|-
|
|"Expositionsrisiko Personengruppen - kodiert" (1.2.40.0.34.6.0.11.2.4):
- ID der Sektion: Kardinalität von 0..* auf 0..1 geändert

- Titel der Sektion wurde von "Expositionsrisiko - Personengruppen" auf "Spezielle Impfindikation" geändert
|Fehler
|-
|
|"Impfrelevante Erkrankungen - kodiert" (1.2.40.0.34.6.0.11.2.5) / id: Kardinalität von 0..* auf 0..1 geändert
|Fehler
|-
|
|"Übersetzung (informativ)" (1.2.40.0.34.6.0.11.2.8): Containment "Author Body - eImpfpass" (1.2.40.0.34.6.0.11.9.8) geändert auf "Author Body" (1.2.40.0.34.6.0.11.9.36), "Author Body" im Leitfaden ergänzt
|Fehler
|-
|
|"Address Compilation" (1.2.40.0.34.6.0.11.9.25) und Address Compilation Minimal (1.2.40.0.34.6.0.11.9.10): Änderung streetAddressLine, streetName, houseNumber von 0..1 R auf 0..1 C, Constraint ergänzt
|Verbesserung
|-
|
|Schamatron Prüfregeln wurden in einigen Templates ergänzt. Diese waren aber bereits in entsprechenden Constraints beschrieben
|Verbesserung
|-
|
|Kapitel "Revisionsliste" ergänzt
|Verbesserung
|-
|
|"Immunization Schedule Entry" (1.2.40.0.34.6.0.11.3.10): Constraint angepasst
|Verbesserung
|-
|
|"Immunization Target Entry" (1.2.40.0.34.6.0.11.3.2): @codeSystem von 1..1 F 2.16.840.1.113883.6.96 auf 1..1 R geändert, @codeSystemName fixer Wert entfernt
|Verbesserung
|-
|
|"6.1.2 Legende der Konformitätskriterien (Optionalität)" Verbesserte Beschreibung.
|Verbesserung
|-
|
|"9.6 U4 Datenkorrektur durch Behörde" - Wording angepasst um keinen physischen Amtsweg zu implizieren, "Bezirksverwaltungsbehörde" statt "Bezirkshauptmannschaft".
|Verbesserung
|}

ILF:Begriffsdefinitionen e-Impfpass

2022-07-12T07:00:32Z

Kuttin: /* Begriffsdefinitionen */

=Begriffsdefinitionen=
{| class="wikitable" style="margin-left: 16px; margin-right: 16px;"
!Begriff!!Definition
|-
|'''Zentrale e-Impfpass Anwendung'''
|Die zentrale e-Impfpass Anwendung umfasst die Fachlogiken für den persönlichen e-Impfpass, die persönlichen Impfempfehlungen, statistische Auswertungen und die Abrechnungsunterstützung.
|-
|'''Zentrales Impfregister'''
|Das zentrale Impfregister ist eine zentrale Datenbank, in der alle Daten zum Immunisierungsstatus der Patientinnen und Patienten gespeichert werden. Eine Auflistung der gespeicherten Daten ist dem vorliegenden CDA Implementierungsleitfaden für den e-Impfpass zu entnehmen. Die Daten aus dem zentralen Impfregister können, eine entsprechende gesetzliche Grundlage vorausgesetzt, für Funktionen wie zum Beispiel dem "persönlichen e-Impfpass", "Ausbruchsmanagement/Krisenmanagement" oder "Durchimpfungsraten" verwendet werden.
|-
|'''Immunisierungseintrag'''
|Im zentralen Impfregister werden nicht nur Informationen zu einer Impfung dokumentiert ("Impfeintrag"), sondern auch weitere Informationen zu Immunisierungen, wie erlangte Immunität durch Krankheit oder Immunitätsnachweise durch Impftiter-Bestimmungen. Die Bezeichnung für die im Impfregister verwalteten Dateneinträge lautet daher "Immunisierungseintrag".
Abgrenzung: Der e-Impfpass umfasst keine passiven Immunisierungen (Verabreichungen von Immunglobulinen) und auch keine Hyposensibilisierungen ("Allergieimpfungen")
|-
|'''Persönlicher e-Impfpass'''
|Der persönliche e-Impfpass fasst die Daten aus dem Impfregister zu einer gewissen Person zusammen. Diese Zusammenfassung enthält zumindest die Daten, die auch der Papierimpfpass umfasst (PatientInnendaten, Datum der Impfung, Handels- bzw. Zulassungsname des Impfstoffes, Chargenbezeichnung, Name der impfenden Ärztin bzw. des impfenden Arztes).
|-
|'''Persönliche Impfempfehlungen (im GTelG als "Impfkalender" definiert)'''
|Die zentrale e-Impfpass Anwendung soll nicht nur der elektronischen Dokumentation von Impfungen dienen, sondern muss auch auf Basis der vorhandenen Impfungen und dem aktuellen, österreichischen Impfplan<ref name="Impfplan">Österreichischer Impfplan [Online Sept. 2021] https://www.sozialministerium.at/Themen/Gesundheit/Impfen/Impfplan-%C3%96sterreich.html</ref> die nächsten empfohlenen Impfungen und Impfzeitpunkte für die jeweilige Patientin, den jeweiligen Patienten berechnen können. Resultat sind übersichtlich dargestellte und ausdruckbare persönliche Impfempfehlungen über die nächsten anstehenden Impfungen. Im GTelG wird diese Funktionalität als "Impfkalender" bezeichnet, was automatisch mit einer Kalenderdarstellung assoziiert wird. Da sich Impfempfehlungsabstände über mehrere Jahre und Jahrzehnte erstrecken können, werden aufgrund der Benutzerfreundlichkeit und Bedienbarkeit die Impfempfehlungen nicht in Kalenderform, sondern als Listen umgesetzt.
|-
|'''Nationaler Impfplan – "Impfplan Österreich"'''
|Der [https://www.sozialministerium.at/Themen/Gesundheit/Impfen/Impfplan-%C3%96sterreich.html "Impfplan Österreich"] wird in enger Zusammenarbeit des Bundesministeriums für Arbeit, Soziales, Gesundheit und Konsumentenschutz und den [https://www.sozialministerium.at/Themen/Gesundheit/Impfen/Nationales-Impfgremium.html Mitgliedern des Nationalen Impfgremiums (NIG)] nach den neuesten Erkenntnissen der Wissenschaft präzisiert und aktualisiert und veröffentlicht <ref name="Impfplan" />. Er enthält alle aktuellen, nationalen Impfempfehlungen und den damit verbunden Impfintervallen und Impfschemata, als auch die Liste an Impfungen, die ins kostenfreie Kinderimpfprogramm <ref name="Kinderimpfkonzept">Bundesministerium Arbeit, Soziales, Gesundheit und Konsumentenschutz [Online Sept. 2021]: https://www.sozialministerium.at/Themen/Gesundheit/Impfen/Kostenfreies-Kinderimpfprogramm.html</ref>fallen.
|-
|'''Impfschema'''
|Empfohlene Impfzeitpunkte werden im sogenannten "Impfschema" festgelegt und stellen ein Regelwerk der Impfdosen zur Erlangung der Grundimmunisierung oder deren Auffrischung dar. Für jeden Impfstoff gibt es ein Impfschema, das angibt, wie viele Impfungen in welchem zeitlichen Abstand zur Grundimmunisierung durchgeführt werden sollen, um den optimalen Impfschutz aufzubauen. Die Abstände zwischen den Impfungen sind immer Mindestabstände, die nur in dringenden Ausnahmefällen unterschritten werden sollten, z.B. wenn eine kurzfristige Auslandsreise ansteht.
|-
|'''Dosiskennung (Dosis, Impfdosis)'''
|Das Wort Dosiskennung beschreibt die Reihenfolgenummer in der Sequenz der Impfdosen oder die Teilimpfungen innerhalb eines Impfschemas. Im Leitfaden wird synonym auch das Wort "Impfdosis" oder auch kurz "Dosis" verwendet
|-
|'''Kostenfreies Kinderimpfprogramm'''
|Das kostenfreie Kinderimpfprogramm <ref name="Kinderimpfkonzept" /> hat zum Ziel, allen in Österreich lebenden Kindern bis zum 15. Lebensjahr Zugang zu den für die öffentliche Gesundheit wichtigen Impfungen zu ermöglichen, ohne dass dafür den Erziehungsberechtigten Kosten erwachsen. Nur so kann erreicht werden, dass die Impfbeteiligung in der Bevölkerung so verbreitet ist, dass auch Personen, die aus bestimmten Gründen nicht geimpft werden können (z.B. Personen mit Immunsuppression), vor einer Ansteckung geschützt sind (Herdenschutz).
|-
|'''e-Health-Anwendung vs. ELGA Anwendung'''
|Die zentrale e-Impfpass Anwendung und deren Pilotierung werden entsprechend der Entschließung des Nationalrates als e-Health-Anwendung umgesetzt. Unter "e-Health Anwendung" versteht man den Einsatz von Informations- und Kommunikationstechnologien in gesundheitsbezogenen Produkten, Dienstleistungen und Prozessen. Das GTelG, welches Anpassungen hinsichtlich der Umsetzung des e-Impfpasses beinhaltet, unterscheidet daher zwischen "ELGA-Anwendungen" und "e-Health-Anwendungen":

*'''"ELGA-Anwendungen"''' sind jene, die gesetzlich aufgelistet sind und "einen bestimmten Zweck […] von ELGA durch ELGA-Gesundheitsdiensteanbieter/innen und ELGA-Teilnehmer/innen" verfolgen.
*'''"e-Health-Anwendungen"''' sind jene, die gesondert gesetzlich aufgelistet sind und "einen bestimmten Zweck […] von ELGA-Komponenten durch Bürger/innen und Gesundheitsdiensteanbieter/innen" verfolgen. Erste gesetzlich vorgesehene e-Health-Anwendungen sind für die Primärversorgung und den e-Impfpass definiert. 

Während ELGA-Anwendungen ausschließlich von berechtigten ELGA-Gesundheitsdiensteanbietern verwendet werden können, können e-Health-Anwendungen von berechtigten ELGA-Gesundheitsdiensteanbietern und weiteren definierten Gesundheitsdiensteanbietern genutzt werden. Die Berechtigungen für e-Health- und ELGA-Anwendungen sind pro Gesundheitsdiensteanbieter gesetzlich vorgegeben.
|-
|'''Elektronischer Impfpass als e-Health Anwendung'''
|Mit der Umsetzung des elektronischen Impfpasses als e-Health Anwendung werden öffentliche Interessen verfolgt, wie z.B. die Sicherstellung der öffentlichen Gesundheit durch Gesundheitswarnungen, Ausbruchsmanagement sowie Prävention und Kontrolle ansteckender Krankheiten. Insofern ist eine möglichst vollständige und flächendeckende Dokumentation des Immunisierungsstatus der Bevölkerung im öffentlichen Interesse. 

*'''Gesundheitsdiensteanbieter, die nicht ELGA-GDA sind''': e-Health Anwendungen können von ELGA-GDA und Nicht-ELGA-GDA genützt werden. Betreffend e-Impfpass seien beispielhaft die von ELGA gesetzlich ausgeschlossenen Akteure Amtsärztinnen und Amtsärzte, Schulärztinnen und Schulärzte, Bezirksverwaltungsbehörden, Länder oder Bundesministerium für Arbeit, Soziales, Gesundheit und Konsumentenschutz zu nennen. 
*'''Verwendung der ELGA Infrastruktur''': Die Verwendung der bestehenden ELGA Infrastruktur inkl. der Betriebs- und Supportprozesse bietet mehrere Vorteile für die Sicherstellung des bereits beschriebenen öffentlichen Interesses. Einerseits erlaubt die Wiederverwendung bestehender ELGA-Infrastruktur eine schnellere Projektabwicklung zu geringeren Kosten, andererseits können Bürgerinnen und Bürger durch das ELGA Portal ihre Gesundheitsdaten an einer Stelle einsehen und administrieren. 
*'''Opt-Out-Regelung''': Eine gesetzliche Regelung für die Teilnahme am e-Impfpass ist zum Zeitpunkt der Erstellung des Leitfadens noch nicht verfügbar.
|-
|'''Durchimpfungsrate'''
|Damit Personen, die sich nicht gegen gewissen Krankheiten impfen lassen können (z.B. Säuglinge aufgrund des Alters oder Menschen mit chronischen Erkrankungen) vor Übertragung von Infektionskrankheiten geschützt sind, müssen genügend Personen in ihrem Umfeld geimpft sein (Herdenimmunität). Als Indikator zur Bestimmung der Herdenimmunität wird die Durchimpfungsrate bestimmt, die ein wichtiges Instrument zur Unterstützung der nationalen und internationalen hoheitlichen Aufgaben darstellt. Als Ausgangsbasis dienen die im zentralen Impfregister gespeicherten Daten, die für statistische Auswertungen aufbereitet werden müssen. Wie gesetzlich vorgegeben, ist der Personenbezug bis auf Geburtsmonat, Geburtsjahr und Gemeindekennziffer zu entfernen. Übliche Auswertungen sind beispielsweise über gewisse Bevölkerungsjahrgänge, Geschlecht und/oder Regionen/Wohnorte.
|-
|'''Krisenmanagement'''
|Die Landessanitätsdirektionen stellen bei Krankheitsausbrüchen ein Krisenmanagement auf, das die Auswertungen der Durchimpfungsraten anfertigt, welche wiederum an das Bundesministerium weitergegeben werden. Im Rahmen des Krisenmanagements bei Krankheitsausbrüchen muss von Kontaktpersonen (z.B. in Schule, Kindergarten, Ordination, Wartebereichen in Ambulanzen) der Impfstatus erhoben werden.
|-
|'''Allergie'''
|Als Allergie wird eine überschießende Abwehrreaktion des Immunsystems auf bestimmte Stoffe (Allergene) bezeichnet, die sich in typischen, oft mit entzündlichen Prozessen einhergehenden Symptomen äußert.
|-
|'''Impfung'''
|Die empfohlenen Impfungen gemäß Österreichischem Impfplan bieten für die individuelle und öffentliche Gesundheit einen Basisschutz. Die Ärzteschaft soll die empfohlenen Impfungen gemäß dem Österreichischen Impfplan <nowiki><ref name=Impfplan>, der periodisch aktualisiert wird, ihren Patienten empfehlen.</nowiki>
|-
|'''Empfohlene Impfungen für Risikogruppen'''
|Gewisse Impfungen werden für bestimmte Risikogruppen als nutzbringend eingestuft. Die Ärzteschaft soll diese Impfungen den Risikopatienten empfehlen, wenn sie sie mit einem vertretbaren Aufwand erreichen. Die Informationen dazu sind im österreichischen, nationalen Impfplan enthalten <ref name="Impfplan" />.
|-
|'''Impferfolg / Immunschutz'''
|Impfungen sind nicht immer zu 100% wirksam. In bestimmten Fällen, wie z.B. der Rötelnimpfung wird der Impferfolg und damit der Immunschutz mittels Messung des "Impftiters" überprüft (z.B. im Rahmen der Schwangerschaftsvorsorge oder bei beruflich exponierten Personen der Impferfolg und Immunschutz gegen das Hepatitis B-Virus). Ein Immunschutz kann auch durch bereits durchgemachte Infektionen zustande kommen und damit den weiteren Impfplan und Impfempfehlungen beeinflussen.
|-
|'''Non-Responder ("Impfversager")'''
|Gesunde Personen, die keine Immunität durch eine Impfung erlangen.
|-
|'''Impfempfehlung'''
|Impfempfehlungen sind Empfehlungen, welche auf der Grundlage des aktuellen, jährlichen österreichischen Impfplans <ref name="Impfplan" /> und des individuellen Impfplanes für eine bestimmte Impfung, einen bestimmten Zeitpunkt oder einer bestimmten Situation abgegeben werden.
|-
|'''Impfreaktion'''
|Impfreaktionen sind in der Regel harmlose Beschwerden nach einer verabreichten Impfung im Rahmen der Immunantwort. Sie treten in einem zeitlichen Zusammenhang mit einer Impfung auf.
|-
|'''Unerwünschte Impfreaktionen (Nebenwirkungen)'''
|Sogenannte unerwünschte Impferscheinungen können nach der Impfung auftreten (am häufigsten innerhalb der ersten 8 Wochen nach der Impfung). Es besteht eine Pflicht zur Meldung schwerer Impfreaktionen an die BASG.
Als Impfschaden bezeichnet man stärkere Nebenwirkungen oder (dauerhafte) Gesundheitsschädigungen.
|-
|'''Impfstelle'''
|Die Impfstelle ist diejenige Person resp. Organisation, welche eine Impfung durchgeführt hat.
|-
|'''Der nationale Impfplan – "Impfplan Österreich"'''
|Die Informationen über die in Österreich empfohlenen Impfungen sind im aktuellen jährlichen Österreichischen Impfplan <ref name="Impfplan" /> des BMASKG enthalten. Eine Aktualisierung erfolgt jährlich durch das Nationale Impfgremium.

|-
|'''Nachtrag'''
|Eine nachträgliche Eintragung einer Impfung, ''die ein anderer Gesundheitsdiensteanbieter'' verantwortet und dokumentiert hat. Diese Impfung liegt bereits in einer Primärdokumentation vor (z.B. Papier-Impfpass, lokale Impfdatenbank) und wird aus der Primärdokumentation in den e-Impfpass nachgetragen. Für das Nachtragen gelten andere Anforderungen an die bereitzustellenden Daten als bei der Dokumentation einer aktuellen Impfung: jedenfalls muss die Person erfasst werden, die für die fachliche Richtigkeit des Nachtrags verantwortlich ist ("Nachtragende Person"), aber auch der für die damalige Impfung verantwortliche Arzt, sofern eruierbar. Auch können hier "historische Impfstoffe" erfasst werden, die nicht mehr in Verwendung sind. Eine Nachtragung kann grundsätzlich nur auf Basis eines eindeutig nachvollziehbaren Impfdokuments erfolgen, z.B. über den gelben Papier-Impfpass. 
''Abgrenzung'': Beim Nachtrag handelt es sich ''nicht'' um das zeitlich verzögerte Dokumentieren einer ''"eigenen" Impfung'', etwa wenn das IT-System gerade nicht verfügbar war. Dazu muss das Impfdatum auch auf einen Zeitpunkt in der Vergangenheit gesetzt werden können, um eine korrekte asynchrone Erfassung der tatsächlichen Impfung durchführen zu können.
|-
|'''Hersteller eines Impfstoffes'''
|Unter Hersteller wird in diesem Leitfaden jenes Pharmaunternehmen verstanden, das gleichzeitig der "Zulassungsinhaber“ eines Impfstoffes ist. Wer die verschiedenen Schritte der Herstellung tatsächlich durchführt (wie Gewinnen, Anfertigen, Zubereiten, Be- oder Verarbeiten, Umfüllen einschließlich Abfüllen, Abpacken oder Kennzeichnen), wird nicht näher angegeben.
|}
<references />

elga-cdaem-2.06.2:Anhang

2022-03-21T10:52:31Z

Kuttin: /* Revisionsliste */

=Anhang=
==Referenzen==
{|
|-
|[1]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.1.6], http://www.elga.gv.at

|-
|[2]|| ELGA GmbH (2014) Usability Styleguide Anforderungen an die Benutzerfreundlichkeit der ELGA-Funktionen für Arztpraxis-Informationssysteme (2.0). OID {1.2.40.0.34.3.1.2.1.21}. http://www.elga.gv.at

|-
|[3]|| ELGA GmbH (2014) Usability Styleguide Anforderungen an die Benutzerfreundlichkeit der ELGA-Funktionen für Krankenhaus-Informationssysteme (2.0). OID {1.2.40.0.34.3.1.2.1.22}. http://www.elga.gv.at

|-
|[4]|| ELGA GmbH (2014) Usability Styleguide Anforderungen an die Benutzerfreundlichkeit der ELGA-Funktionen für Apotheken-Softwaresysteme (2.0). OID {1.2.40.0.34.3.1.2.1.23}. http://www.elga.gv.at
|}

==Revisionsliste==
{| class="wikitable"
!Vers.
!Datum
!Änderungsgrund
|-
|1.00
|05.11.2013
|Erste Version des Implementierungsleitfadens.
|-
|1.01
|02.01.2014
|Einarbeitung des Feedbacks und Abstimmung des Dokuments mit dem Anforderungsdokument
|-
|1.02
|24.02.2014
|Ballot-Kommentare eingearbeitet, Value Sets und OID mit auf vollständigen und korrekten Werten.
|-
|1.03
|18.03.2014
|TemplateIds eingearbeitet. Finale Version zur Veröffentlichung.
|-
|1.03a
|31.03.2014
|Zahlendreher in OID des AbgabeEntry 1.2.40.0.34.11.8.2.3.1 (korrekt) statt 1.2.40.0.34.11.8.1.3.2
|-
|1.04
|27.07.2014
|4.4.4.2.4.2 Optionalität für name von M auf R korridiert
|-
|1.04
|27.07.2014
|XML-Elemente in CDA beginnen mit Kleinbuchstaben,
|-
|1.04
|27.07.2014
|4.1 Präzisiert: EIS Full Support ist verpflichtend 4.4.1.1. Strukturbeispiel neu 4.4.1.2.2. Template IDs "IHE PHARM Dosage Instructions" hinzugefügt 4.4.1.2.4. Therapieart gelöscht 4.4.1.2.6.2 Spezifikation: Nur NullFlavor UNK ist erlaubt (NI nicht) 4.4.1.2.7.1.2, 4.4.1.2.7.2.2, 4.4.1.2.7.3.2, 4.4.1.2.7.4.2 Spezifikation nun mit konditionaler Konformität (Dosierung angegeben/nicht angegeben) 4.4.1.2.14. Ergänzende Informationen zur Abgabe und magistralen Zubereitung: Beschreibungstext neu 4.4.1.2.14.1 Strukturbeispiel neu 4.4.1.2.14.2 Spezifikation geändert 4.4.1.2.13. Hinzugefügt "Informationen zur Arznei" 4.4.1.2.15. Hinzugefügt „Therapieart“
|-
|1.04
|27.07.2014
|4.4.2.1. Strukturbeispiel Korrekturen 4.4.2.2.4. Abgabeart neu spezifiziert, Value Set geändert 4.4.2.2.11.1 Strukturbeispiel geändert 4.4.2.2.11.2 Spezifikation gändert 4.4.2.2.12. "Ergänzende Informationen zur Abgabe und magistralen Zubereitung" geändert 4.4.2.2.12.1 Strukturbeispiel geändert 4.4.2.2.12.2 Spezifikation geändert 4.4.2.2.13.1 Strukturbeispiel TemplateId hinzugefügt 4.4.2.2.13.2 Spezifikation TemplateId hinzugefügt 4.4.2.2.14. Therapieart Neu
|-
|1.04
|27.07.2014
|4.4.3.1. Korrekturen 4.4.3.2.5. Text Neu 4.4.3.2.6.2 Spezifikation geändert 4.4.3.2.9.1 TemplateId geändert 4.4.3.2.10.1 Strukturbeispiel geändert 4.4.4.2.7.2 Änderungen: Value Set binding erweitert, OriginalText und Translation hinzugefügt, ClassCode und DeterminerCode hinzugefügt
|-
|1.04
|18.08.2014
|2.5 und 2.6: Hinzugefügt "Besorger" 2.2, 2.9, 2.12: Kleine Korrekturen
|-
|1.04
|18.08.2014
|Korrekturen: 4.3.1.4.5.1.2 Tabelle zur Darstellung der Verordnungen 4.3.2.4.5.1.1 Tabelle zur Darstellung der Abgabe
|-
|1.04
|18.08.2014
|Kapitel 4.3.3.4.5.1 eingefügt: Vorgaben zur Gestaltung des narrativen Textes
|-
|1.04
|18.08.2014
|4.4.1.2.12.Korrekturen des Textes
|-
|1.04
|18.08.2014
|4.4.4.2.7.1 Neue Strukturbeispiele hinzugefügt
|-
|1.04
|18.08.2014
|Seite 2: Hinweis auf Revisionsliste und Weitere unterstützende Dokumente hinzugefügt Dokumenteninformation auf Seite 6: Haftungsausschuss gelöscht, Hinweis zur Verbindlichkeit eingefügt.
|-
| colspan="3" |'''Version 2.05'''

|-
|2.05
|27.11.2014
|Typos und Formatierungen verbessert
|-
|2.05
|23.12.2014
|Dokumenteninformation (Seite 2) ergänzt mit Hinweis auf Einhaltung der Rechtsordnung und relevanten Materiengesetzen.
|-
|2.05
|15.01.2015
|Status (Seite 2): Satz geändert, der die Einbeziehung von Stakeholdern beschreibt.
|-
|2.05
|12.03.2014
|Seite 4: Formulierung zur Verbindlichkeit aktualisiert
|-
|2.05
|15.01.2015
|1.2: Dokumentenklassen: Fußnote zur Erklärung der Dokumentenklassen hinzugefügt. Ergänzung der Bezeichnung der Dokumentenklasse „Pharmazeutische Empfehlung“ als „Korrekturmeldung“.
|-
|2.05
|23.12.2014
|1.2: und 3.1.2.4.4. Fußnote zur Erklärung der „Pharmazeutischen Empfehlung“ hinzugefügt
|-
|2.05
|23.12.2014
|Kapitel 2, Angabe der Akteure: bei den Vertretern des Teilnehmers „oder pflegender Angehöriger“ gestrichen.
|-
|2.05
|03.03.2015
|2.1 bis 2.12: Beschreibung der Anwendungsfälle zum besseren Verständis überarbeitet
|-
|2.05
|09.03.2015
|2.1.4. Verordnung(en) mit Rezept anlegen - Ablauf: Beschreibung der Auswahl eines Arzneimittels hinzugefügt
|-
|2.05
|16.03.2015
|2.1.4. Ablauf: Hinweis auf „Löschen von nicht eingelösten Verordnungen nach 1 Monat“ entfernt
|-
|2.05
|16.03.2015
|2.2.4. Ablauf: Verordnungen können mit Status „OFFEN“ und zusätzlich mit „ABGELAUFEN" abgerufen werden
|-
|2.05
|15.01.2015
|2.12.5. Alternativer Ablauf beim Abrufen der Medikationsliste hinzugefügt
|-
|2.05
|23.12.2014
|Vorkommen von „Befüllungsvorschrift gemäß Rezeptpflichtgesetz“ gestrichen, betrifft: 3.4.1.3.3., 4.4.1.2.8.2
|-
|2.05
|25.02.2015
|3.4.1.3.2. Konformität der Rezeptart auf [R] gesetzt
|-
|2.05
|25.02.2015
|3.4.1.3.3. Konformität der Gültigkeitsdauer des Rezepts auf [R] gesetzt, Fußnote hinzugefügt
|-
|2.05
|27.11.2014
|Zulassungsnummer wird nur in der Medikationsliste benötigt und daher aus den anderen Dokumenten entfernt, betrifft: 4.3.1.4.5.1, 4.3.2.4.5.1., 4.4.4.2.3., 4.4.4.2.4., 4.4.4.2.6.2
|-
|2.05
|23.12.2014
|3: Hinweis auf allgemeinen Leitfaden mit der Angabe der Konformitätskriterien (Optionalität, Kardinalität) und ein Beispiel hinzugefügt
|-
|2.05
|27.11.2014
|3.1.2.3. Korrekte Benennungen der clinicalDocument. code LOINC angegeben (Änderung im LOINC): 60593-1, 61356-2, 57833-6
|-
|2.05
|23.12.2014
|4.2.4. Zur Kapitelüberschrift „Pharmazeutische Empfehlung“ hinzugefügt: ‚(„Korrekturmeldung“)‘
|-
|2.05
|23.12.2014
|4.3.1.4.5., 4.3.2.4.5., 4.3.3.4.5., 4.3.4.4.5.: "Vorgaben zur Gestaltung" in "Empfehlung zur Gestaltung" geändert
|-
|2.05
|10.03.2015
|4.3.1.4.5.1.2, 4.3.2.4.5.1.1, 4.3.2.4.5.1.2, 4.3.3.4.5.1.1 : „Vorgaben zum Layout der Tabelle“ geändert in „Empfehlung zum Layout der Tabelle“
|-
|2.05
|25.02.2015
|4.3.2.4.6. Maschinenlesbare Elemente der Sektion: Kardinalität auf 1..1 korrigiert
|-
|2.05
|25.02.2015
|4.3.1. Korrekte Benennungen der LOINC für Rezept section.code angegeben (Änderung im LOINC): 57828-6 „Prescription list“
|-
|2.05
|11.12.2014
|4.3.3.4.5.1: Abgaben: Pfade, die „<product“ enthalten, wurden auf „<consumable geändert werden.
|-
|2.05
|25.02.2015
|4.3.3.4.5.1.1 Tabelle zur Darstellung der Medikationsliste: Korrekturen (Pfade) und klarere Gestaltung. Beschreibung der Defaultsortierung hinzugefügt
|-
|2.05
|25.02.2015
|4.3.4.4.5.1.1 Überschrift in Beispieltabelle korrigiert (Item-ID statt DokumentenID)
|-
|2.05
|25.02.2015
|4.3.4.4.6. Maschinenlesbare Elemente der Sektion: Kardinalität des Entry auf 1..1 korrigiert
|-
|2.05
|11.12.2014
|Alle Vorkommen von <entry> durch <entry typeCode="DRIV"> ersetzt, da der narrative Text gänzlich aus codierten Entries abgeleitet ist
|-
|2.05
|05.03.2015
|4.4.1.2.1. ELGA MedikationVerordnung-Entry: Spezifikation der TemplateIDs verändert
|-
|2.05
|12.12.2014
|4.4.1.2.2. Template ID für „Delay Start Dosing“ korrigiert, Fußnote dazu eingefügt
|-
|2.05
|25.02.2015
|4.4.1.2.2. TemplateID[7] Variante c) hinzugefügt für "Keine Dosierung"
|-
|2.05
|05.03.2015
|4.4.1.2.3. ID des MedikationVerordnung-Entry: Einführung einer zweiten ID als Referenz auf das VerordnungsEntry und 4.4.1.2.3.2 Spezifikation erweitert.
|-
|2.05
|04.03.2015
|4.4.1.2.6. Einnahmedauer: Ergänzende Bestimmung für Einnahmedauer
|-
|2.05
|15.12.2014
|4.4.1.2.6.1 Strukturbeispiele: Datenstruktur um die „Patient Medication Instructions“ xsi:type fehlte, wurde nachgezogen
|-
|2.05
|04.03.2015
|4.4.1.2.6.1 Strukturbeispiel für "Dosierungsinformationen sind generell nicht angegeben" Low und High Elemente entfernt Strukturbeispiel 5 für Einnahmedauer gelöscht ("generell keine Dosierungsinformation angegeben")
|-
|2.05
|15.12.2014
|4.4.1.2.6.2 Spezifikation: Unterscheidung der Fälle „Einnahmedauer unbekannt“ und „generell keine strukturellen Dosierungsinformationen angegeben“. Lösung durch zusätzliches nullFlavor=“NA“ auf der Ebene des effectiveTime.
|-
|2.05
|04.03.2015
|4.4.1.2.6.2 Spezifikation geändert
|-
|2.05
|25.02.2015
|4.4.1.2.8. Titel von "Anzahl der Einlösungen" präzisiert auf "Anzahl der (zusätzlichen) Einlösungen"
|-
|2.05
|25.02.2015
|4.4.1.2.8.2 Konformität der Anzahl der Einlösungen auf [R], Kard 1..1 gesetzt, Fußnote hinzugefügt
|-
|2.05
|27.11.2014
|4.4.1.2.11. Verfasser der Verordnung: Bezug auf Rezept im Text hinzugefügt, im Strukturbeispiel ergänzt 4.4.1.2.11.2 Korrektur: Container zur Dokumentation de s Verfassers der Verordnung (nicht Abgabe)
|-
|2.05
|25.02.2015
|4.4.1.2.11.2 Spezifikation für den Verfasser der Abgabe: Time-Element ist M
|-
|2.05
|13.03.2015
|4.4.1.2.12. Packungsanzahl ist mindestens 1
|-
|2.05
|25.02.2015
|4.4.1.2.12.2 Konformität der Anzahl der auszugebenden Packungen auf [R] gesetzt, Fußnote hinzugefügt
|-
|2.05
|27.11.2014
|4.4.1.2.13.1 und ff TemplateID 1.2.40.0.34.11.8.0.3.1 bzw 1.2.40.0.34.11.8.0.3.2 statt 1.3.6.1.4.1.19376.1.5.3.1.4.3
|-
|2.05
|02.02.2015
|4.4.1.2.13.2: "inversionInd" wurde zwei mal als Element angegben, korrekt ist es ein Attribut der entryRelationship
|-
|2.05
|04.03.2015
|4.4.1.2.16. ID des Verordnungs-Entry Containers (Rezept-Dokument): Kapitel EINGEFÜGT
|-
|2.05
|12.12.2014
|4.4.2.1. Strukturbeispiel im ELGA MedikationAbgabe-Entry korrigiert
|-
|2.05
|05.03.2015
|4.4.2.2.3. ID des MedikationAbgabe-Entry: Einführung einer zweiten ID als Referenz auf das VerordnungsEntry und 4.4.2.2.3.2 Spezifikation erweitert.
|-
|2.05
|27.11.2014
|4.4.2.2.4.2 Präfix HL7: von ActCode entfernt
|-
|2.05
|06.03.2015
|4.4.2.2.6.2 Spezifikation Abgegebene Packungsanzahl: Packungsanzahl für Mag. Zubereitung auf R geändert
|-
|2.05
|12.03.2014
|4.4.2.2.6 Abgegebene Packungsanzahl: Text zu Magistralen Zubereitungen geändert
|-
|2.05
|27.11.2014
|Kapitel vertauscht und geändert: 4.4.2.2.8. Verfasser der Verordnung zu dieser Abgabe 4.4.2.2.9. Verfasser der Abgabe
|-
|2.05
|05.03.2015
|4.4.2.2.8.2 Spezifikation korrigiert (time ist ein Unterelement)
|-
|2.05
|25.02.2015
|4.4.2.2.8.2 Spezifikation für den Verfasser der Abgabe: Time-Element ist M
|-
|2.05
|05.03.2015
|4.4.2.2.9.2 Spezifikation korrigiert (time ist ein Unterelement)
|-
|2.05
|25.02.2015
|4.4.2.2.9.2 Spezifikation für den Verfasser der Abgabe: Time-Element ist M
|-
|2.05
|25.02.2015
|4.4.2.2.10., 4.4.3.2.7. und 4.4.3.2.8. Typo in Überschrift
|-
|2.05
|05.03.2015
|4.4.2.2.10. Referenz zur Verordnung: Hinweis zur Verwendung hinzugefügt
|-
|2.05
|15.01.2015
|4.4.2.2.13: Formulierung verändert: Statt „Es ist möglich…“ „Es ist technisch möglich…“. Eine Fußnote zur Erinnerung der notwendigen Absprache mit dem verordnenden Arzt hinzugefügt.
|-
|2.05
|04.03.2015
|4.4.2.2.15. ID des Abgabe-Entry Containers (Abgabe-Dokument): Kapitel EINGEFÜGT
|-
|2.05
|25.02.2015
|4.4.3.2.3.2 Typo in Spezifikation
|-
|2.05
|11.12.2014
|4.4.3.2.4.2 Code geändert auf [M], Kard. entsprechend [1..1]
|-
|2.05
|25.02.2015
|4.4.3.2.6.1 Strukturbeispiel korrekter Wert ist completed
|-
|2.05
|05.03.2015
|4.4.3.2.7. Referenz zur Verordnung: Hinweis zur Verwendung hinzugefügt
|-
|2.05
|05.03.2015
|4.4.3.2.9. Geänderte Verordnung: Satz ergänzt (..und Informationen zur alternativen Einnahme...)
|-
|2.05
|15.12.2014
|4.4.3.2.10: Geänderte Abgabe (betrifft PADV, der einen CHANGE der Dosierungsinformationen auf ein DIS-Item abbildet). Datenstruktur um die „Patient Medication Instructions“ erweitert
|-
|2.05
|04.03.2015
|4.4.3.2.10. Geänderte Abgabe: Beschreibungstext geändert
|-
|2.05
|04.03.2015
|4.4.4.1. Strukturbeispiel Arznei-Entry: Beispiel geändert
|-
|2.05
|04.03.2015
|4.4.4.2.3. Code des Arznei-Entry: Beispiele geändert
|-
|2.05
|25.02.2015
|4.4.4.2.3.2 Spezifikation PZN: Translation ist [R2] statt [C] (wenn nicht vorhanden, Element nicht angeben)
|-
|2.05
|11.12.2014
|4.4.4.2.4: „Name der Arznei“ zu „Bezeichnung der Arznei“ geändert, auch im Strukturbeispiel und der Spezifikation
|-
|2.05
|04.03.2015
|4.4.4.2.4. Bezeichnung der Arznei: Beispiel geändert
|-
|2.05
|25.02.2015
|4.4.4.2.5. Darreichungsform: Einschränkung auf magistrale Zubereitung aufgehoben
|-
|2.05
|25.02.2015
|4.4.4.2.7. Angaben zu Wirkstoff(en): Textuelle Optionalität bei magistralen Zubereitungen auf SOLL heruntergesetzt
|-
| colspan="3" |'''Version 2.06 (Hauptversion)'''
|-
|2.06
|10.09.2015
|Buchstabendreher korrigiert für (richtig) POCD_MT000040
|-
|2.06
|12.10.2015
|Neu organisiert: Dokumententeninformation, Harmonisierung, Hinweise zur Nutzung des Leitfadens, Verbindlichkeit, Hinweis auf verwendete Grundlagen, Danksagung, Bedienungshinweise und Inhaltsverzeichnis
|-
|2.06
|01.10.2015
|2.1 Formulierung des Anwendungsfalls verbessert
|-
|2.06
|01.10.2015
|2.2 Formulierung des Anwendungsfalls verbessert
|-
|2.06
|08.04.2015
|2.4.4. Ablauf: Satz "Der Arzt kann folgende Datenfelder eines Rezepts ändern" geändert in "Der Arzt kann folgende Datenfelder von Verordnungen eines Rezepts ändern"
|-
|2.06
|11.11.2015
|3.1.2.1. ELGA Implementierungsleitfaden-Kennzeichnung („templateId“): In Strukturbeispiel und Spezifikation TemplateID für EIS Full Support korrigiert in 1.2.40.0.34.11.8.0.3
|-
|2.06
|20.07.2015
|3.2.1. Übersicht: Konformitätsangaben für Rechtlicher Unterzeichner (legalAuthenticator) für Medikationsliste auf NP gesetzt
|-
|2.06
|20.07.2015
|3.2.4. Elemente mit speziellen Vorgaben hinzugefügt, um die Spezifikation des Rechtlichen Unterzeichners (legalAuthenticator) abzugrenzen: NP für Medikationsliste, M für die anderen Dokumentenklassen
|-
|2.06
|16.07.2015
|3.4.1.3.2. Spezifikation Rezepart, Fußnote für Verwendung des NullFlavors hinzugefügt
|-
|2.06
|20.08.2015
|Kapitel 4.1.2. „Menschen- und maschinenlesbare Daten“ neu eingefügt, Erklärung der Verwendung der maschinenlesbaren Elemente.
|-
|2.06
|16.07.2015
|4.3.1.4.5.1.2 Tabelle zur Darstellung der Verordnungen: Im Beispiel den korrekten Zulassungsnamen eingetragen
|-
|2.06
|31.07.2015
|4.3.1.4.5.1.2 Tabelle zur Darstellung der Verordnungen: Textänderung bei Zeile „Ergänzende Informationen“
|-
|2.06
|31.07.2015
|4.3.2.4.5.1.1 Tabelle zur Darstellung der Verordnungen: Textänderung bei Zeile „Ergänzende Informationen“
|-
|2.06
|11.11.2015
|4.3.2.4.5.1.1 Tabelle zur Darstellung der Abgabe: Vorgabe für Therapieart hinzugefügt
|-
|2.06
|31.07.2015
|4.3.4.4.5.1.4 Tabelle zur Darstellung der geänderten Patienteninformationen bei einer Abgabe: hinzugefügt
|-
|2.06
|01.04.2015
|4.4.1.2.16.2 ID des Verordnungs-Entry Containers (Rezept-Dokument): Zur Spezifikation das Element <externalDocument> hinzugefügt
|-
|2.06
|01.10.2015
|4.4.2.1. ELGA MedikationAbgabe-Entry Strukturbeispiel: CodeSystemName für CCF verbessert
|-
|2.06
|16.07.2015
|4.4.2.2.4.2 Spezifikation: Bezeichnung des Value Sets und Codesystems korrigiert
|-
|2.06
|30.04.2015
|4.4.2.2.8.1 Strukturbeispiel 2 (Verfasser der Verordnung nicht verfügbar): Korrigiert, nullFlavor='NA' hinzugefügt
|-
|2.06
|01.04.2015
|4.4.2.2.15.2 ID des Abgabe-Entry Containers (Abgabe-Dokument): Zur Spezifikation das Element <externalDocument> hinzugefügt
|-
|2.06
|07.05.2015
|4.4.2.2.6.2 Spezifikation: technische Korrektur der Notation des NullFlavors
|-
|2.06
|16.07.2015
|4.4.3.2.9. Geänderte Verordnung: Es sind immer vollständige Dosierungsinformationen anzugeben. Zusatzinformationen für den Patienten müssen angegeben werden, wenn vorhanden
|-
|2.06
|16.07.2015
|4.3.3.4.5.1.1 Tabelle zur Darstellung der Medikationsliste Abgabe(n) Spezifikation korrigiert (Arzneimittel, Dosierung, Hinweis, Ergänzende Information zur magistralen Zubereitung, Ergänzende Information) Verordnung(en) Spezifikation korrigiert (Arzneimittel, Dosierung, Hinweis, Ergänzenden Informationen zur magistralen Zubereitung, Ergänzende Information, Zusatzinformation Patient, Alternative Einnahme, Mögliche Arten der Anwendung, Art der Anwendung)
|-
|2.06
|16.07.2015
|4.3.3.4.5.1.1 Layout der Medikationsliste: Fußnote zur Erklärung der Sortierung geändert (chronologisch statt nach Zulassung gruppiert)
|-
|2.06
|01.10.2015
|4.3.3.4.5.1.1 Tabelle zur Darstellung der Medikationsliste: Kleine Anpassungen zur inhaltlichen Konsistenz des Beispiels (Verordnungsdatum)
|-
|2.06
|08.09.2015
|4.4.1.2.6.2 Spezifikation Einnahmedauer - Korrektur: <width> Kardinalität bei [M] muss 1..1 sein.
|-
|2.06
|10.08.2015
|4.4.1.2.6.2 Element effectiveTime.high ist [R], die Kardinalität muss daher 1..1 sein (war 0..1)
|-
|2.06
|06.10.2015
|4.4.1.2.7 Dosierungsvarianten/Zeitpunkt(e) der Einnahme: Bessere Beschreibung der freitextlichen ANgabe der Dosierung
|-
|2.06
|08.09.2015
|4.4.1.2.7.4.2 Datentyp von phase@value korrigiert auf TS
|-
|2.06
|08.09.2015
|4.4.1.2.13 Zusatzinformation für den Patienten, alternative Einnahme und Informationen zur Arznei: Beispiele für die Informationskategorien hinzugefügt
|-
|2.06
|11.11.2015
|4.4.2.1. Abgabe-Entry Strukturbeispiel: korrigiert, falsche TemplateIDs bei ELGA MedikationVerordnung-Entry entfernt
|-
|2.06
|16.07.2015
|4.4.4.1. Strukturbeispiel: Darreichungsform und Translation beim Code hinzugefügt
|-
|2.06
|01.10.2015
|4.4.4.2.3. Code des Arznei-Entry: Erklärung des Zusammenhangs Pharmazentralnummer (PZN), Zulassungsnummer und ASP-Liste hinzugefügt
|-
|2.06
|12.10.2015
|4.4.4.2.4 Bezeichnung der Arznei: Festlegung auf „Handelsname“
|-
|2.06
|08.09.2015
|4.4.4.2.3.2 Arznei-Entry Wirkstoff: Translation-Element von [R2] auf [C] korrigiert
|-
|2.06
|31.08.2015
|4.4.4.2.7. Angaben zu Wirkstoff(en): Genauere Beschreibung der Verwendung des ATC und seiner deutschen Bezeichnungen
|-
| colspan="3" |''' Version 2.06.1 (Nebenversion)''' x …betrifft Implementierung (erste Spalte)
|-
|x
|04.01.2016
|4.4.1.2.7.3 Dosierungsvariante 3: Spezifikation der Einnahmedauer – Unterscheidung der Fälle EINMAL und MEHRMALS pro Woche.
Wenn die Einnahme nur einmal pro Woche erfolgt, ist die Datentyperweiterung für effectiveTime[2] PIVL_TS. Wenn die Einnahme mehrmals pro Woche erfolgt SXPR_TS, da es dann mehrere <comp> Unterelemente geben muss. Korrektur: Der Datentyp für phase ist PIVL_TS, nicht IVL-TS. Korrektur: Der Datentyp für phase@value ist ts, nicht real.
|-
|x
|04.01.2016
|4.4.1.2.7.4 Dosierungsvariante 4: Spezifikation der Einnahmedauer – Darstellung der Fälle EINMAL und MEHRMALS pro Woche. Da immer <comp>-Unterelemente notwendig sind, ist die Datentyperweiterung für effectiveTime[2] immer SXPR_TS. Korrektur: Der Datentyp für phase ist PIVL_TS, nicht IVL-TS. Korrektur: Der Datentyp für phase@value ist ts, nicht real. Korrektur: überflüssige TemplateId in SubstanceAdministration entfernt
|-
|
|02.02.2016
|4.4.1, 4.4.2, 4.4.3, 4.4.4: Ausschnitte ausdem R-MIM (L-POCD_RM000040) hinzugefügt
|-
| colspan="3" |'''Version 2.06.2 (Nebenversion)''' x …betrifft Implementierung (erste Spalte)
|-
|
|01.08.2016
|Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
|-
|
|14.07.2016
|1.1.1. e-Medikation: Hinweis hinzugefügt, dass die e-Medikation keine Funktion zur Reichweiten- oder Wechselwirkungsprüfung bereitstellt.
|-
|
|14.07.2016
|Anwendungsfälle hinzugefügt: 2.1. eMED-ID-Assertion anfordern 2.2. eMED-ID (Dokumenten-ID) anfordern
|-
|
|14.07.2016
|2.3.2. Vorbedingung für "Verordnung(en) mit Rezept anlegen": Anfordern einer eMED-ID (Dokumenten-ID)
|-
|
|14.07.2016
|2.3.4.2. Ergebnis im Fehlerfall: neu beschrieben Vereinheitlichung: Im Folgenden alle Vorkommen von „bei Gutfall/Fehlerfall“ durch „im Gutfall/Fehlerfall“ ersetzt
|-
|
|14.07.2016
|2.4.2. Vorbedingung: Alternativ-Vorbedingung hinzugefügt
|-
|
|14.07.2016
|2.4.4. Ablauf: Hinweis auf Datenmodell entfernt.
|-
|
|14.07.2016
|2.5.1. Verordnung/Rezept stornieren - Beschreibung korrigiert
|-
|
|14.07.2016
|2.5. Verordnung stornieren: Beschreibung, Vorbedingungen und Ablauf des Anwendungsfalls inhatlich geändert.
|-
|
|14.07.2016
|2.6. Verordnung/Rezept ändern: Beschreibung geändert, Hinweis auf Wecheselwirkungsprüfung entfernt.
|-
|
|15.07.2016
|2.7 Abgabe mittels eMED-ID durchführen: Beschreibung, Vorbedingung, Akteure, Ablauf geändert; Ergebnis im Schlechtfall vereinfacht.
|-
|
|15.07.2016
|2.8. Abgabe über e-card durchführen: Akteure, Ablauf und Ergebnis im Schlechtfall korrigiert
|-
|
|15.07.2016
|2.9. Abgabe ohne Verordnung durchführen: Ablauf korrigiert
|-
|
|15.07.2016
|2.10. Abgabe abrufen: Ergebnis im Fehlerfall vereinheitlicht
|-
|
|15.07.2016
|2.11. Abgabe stornieren: Beschreibung, Akteure, Ablauf und Ergebnis im Fehlerfall korrigiert
|-
|
|15.07.2016
|2.12. Abgabe absetzen: Vorbedingung, Ablauf und Ergebnis im Fehlerfall korrigiert
|-
|
|15.07.2016
|2.13. Abgabe ändern: Beschreibung korrigiert
|-
|
|15.07.2016
|2.14. Medikationsliste abrufen: Ablauf korrigiert
|-
|
|27.07.2016
|4.x (mehrere Stellen) Vereinheitlichung der Bezeichungen: Immer „Packungsanzahl“ statt „Anzahl der Packungen“
|-
|
|26.04.2016
|4.4.1.2.3.2 Spezifikation (ID des MedikationVerordnung-Entry): Für die Anwendung im e-Befund ist es zulässig, eine andere ID zu verwenden, wenn keine VerordnungsID vorhanden ist.
|-
|
|18.07.2016
|4.4.1.2.6.2 Einnahmedauer, Spezifikation: Die Einnahmedauer DARF nun auch ohne Dosierungsvariante angegeben werden.
|-
|
|22.08.2016
|4.4.1.2.7.2 Dosierungsvariante 2: Bei Strukturbeispiel und Spezifikation das text-Element erlaubt [O]
|-
|
|22.08.2016
|4.4.1.2.7.4 Dosierungsvariante 4: Bei Strukturbeispiel und Spezifikation das text-Element erlaubt [O]
|-
|
|18.07.2016
|4.4.1.2.12.2 Packungsanzahl, Spezifikation: Einschränkung auf positive Werte formuliert.
|-
|
|27.07.2016
|4.4.2.2.6.2 Spezifikation Packungsanzahl: Einschränkung auf Null und positive Werte formuliert
|-
|
|04.08.2016
|3.1.2.2.2, 3.4.1.1, 3.4.1.3.3, 4.3..4.5.1.2, 4.4.1.2.3, 4.4.1.2.6.1, 4.4.1.2.6.2, 4.4.1.2.13.2, 4.4.1.2.14.2, 4.4.2.2.3, 4.4.2.2.4, 4.4.2.2.11.2, 4.4.2.2.12.2, 4.4.3.2.3, 4.4.3.2.7, 4.4.3.2.8, 4.4.3.2.9, 4.4.1.2.7.4.2, 4.4.1.2.8, 4.3.1.4.5.1, 4.3.1.4.5.1.2, 4.3.2.4.5.1, 4.3.3.4.5.1, 4.4.1.2.6, 4.4.4.2.4, 3.2.3, 3.3, 3.4.1, 3.6, 3.7, 4.4.1.2.13, 4.4.1.2.14, 4.4.2.2.11, 4.4.2.2.12 Korrektur der Großschreibung bei normativen Vorgaben
|-
|
|21.03.2022
|4.9.4 Ablauf: Korrektur der Vorgaben für den Fall der Nacherfassung von bereits erfolgten Abgaben
|}

elga-cdaem-2.06.2:Anwendungsfälle

2022-03-21T09:22:50Z

Kuttin: /* Ablauf */

{{#css:
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
}}
{{#customtitle:Anwendungsfälle}}

=Anwendungsfälle=
Zum besseren Verständnis des Implementierungsleitfaden „e-Medikation“ sowie dem Zusammenspiel der CDA-Dokumente werden im Folgenden die Anwendungsfälle für die e-Medikation kurz dargestellt.

Folgende ''Akteure'' werden in der ELGA-Anwendung e-Medikation (eMEDAT) definiert:
* Akteure im niedergelassenen Bereich
** Arzt: Kassenarzt, Hausapotheker5, Wahlarzt, Facharzt, etc.
** ArztpraxisassistentIn
* Krankenanstalt
** In der e-Medikation erfolgt keine Unterscheidung in stationären und ambulanten Bereich. Die Umsetzung der Berechtigungen (z.B. darf nur ein Arzt eine Verordnung in e-Medikation speichern), obliegt der GDA-Software.
* Akteure in der Apotheke
** Pharmazeut/In
** Pharmazeutisch-kaufmännisch(er/e) AssistentIn
* Einrichtung der Pflege
** Die Umsetzung der Berechtigungen (z.B. darf nur ein Arzt eine Verordnung in e-Medikation speichern), obliegt der GDA-Software.
** Pflegeperson (siehe Vertreter, Vollmachtnehmer)
* ELGA-Teilnehmer
** Vertreter (z.B. Ombudsstelle oder Vollmachtnehmer, gesetzlicher Vertreter)
Der gegenständliche Implementierungsleitfaden „e-Medikation“ definiert die folgenden CDA-Dokumente: Rezept, Abgabe, Korrekturmeldung (Pharmazeutische Empfehlung) und Medikationsliste. Um den Medikationsprozess und die folgend beschriebenen Anwendungsfälle abbilden zu können, werden diese Dokumente mit den folgenden Status in der e-Medikation abgebildet:
* Rezept/ Verordnung (PRESCRIPTION)
** OFFEN, EINGELÖST, STORNIERT, ABGELAUFEN, NICHT_ABGEGEBEN
* Abgabe (DISPENSE)
** ABGEGEBEN, ABGESETZT, STORNIERT
* Korrekturmeldung (Pharmazeutische Empfehlung, Pharmaceutical Advice)
** STORNIERT (deprecated)
* Medikationsliste
** ERSETZT (deprecated)

5 Da im GDA-Index jeder GDA nur eine Rolle besitzt und es eine Rolle „Hausapotheker“ nicht gibt, haben Hausapotheker dieselbe Rolle wie niedergelassene Ärzte ohne Hausapotheke. Somit hat jeder Arzt auch die Funktionalitäten zur Abgabe zur Verfügung.

==eMED-ID-Assertion anfordern==
===Beschreibung===
Für den Zugriff auf die e-Medikationsdokuments ist neben einem Patientenkontakt im ELGA-Berechtigungssystem auch die Verwendung einer eMED-ID-Assertion zulässig. Diese ermöglicht den Zugriff auf die zugehörigen Dokumente zur eMED-ID. Eine eMED-ID-Assertion wird immer für ein Rezept (Prescription-Dokument) ausgestellt und ermöglicht den Zugriff auf alle zu diesem Prescription-Dokument zugehörigen Dokumente und das Speichern einer zugehörigen Abgabe.

===Vorbedingung ===
Alle Zugriffe auf die ELGA-Applikation e-Medikation erfolgen ausschließlich durch das ELGA-Berechtigungssystem. Es müssen somit alle Vorbedingungen des ELGA-Berechtigungssystem erfüllt sein um Funktionen der e-Medikation nutzen zu können. Keiner der in den Anwendungsfällen angeführten Akteure hat eine direkte Zugriffsmöglichkeit auf die e-Medikation. Der Zugriff passiert ausschließlich über das ELGA-Berechtigungssystem. Es gelten die Vorbedingungen des ELGA-Berechtigungssystem analog e-Befunde mit Ausnahme
* der eingeschränkten Zugriffsmöglichkeit auf ein konkretes Rezept mit seinen Verordnungen per eMED-ID und
* den Funktionen zum Anfordern der eMED-ID (GenerateDocumentId) und Anfordern der eMED-ID-Assertion (RequestSecurityToken).

Der Zugriff per eMED-ID-Assertion ist alternativ zum Zugriff mit einem Patientenkontakt im ELGA-Berechtigungssystem zu sehen. Beim Zugriff mit eMED-ID-Assertion ermöglicht die e-Medikation nur eine eingeschränkte Sicht auf die Daten des ELGA-Teilnehmers.

Die Transaktionen haben keinen direkten Bezug zu einem ELGA-Teilnehmer und können über das ELGA-Berechtigungssystem nur mit einer gültigen Assertion aufgerufen werden.

===Akteure===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Einrichtung der Pflege
* Apotheke
===Ablauf===
Der Akteur möchte die Rezeptdaten (Prescription Dokument) ohne vorhandener Kontakbestätigung bzw. ohne Stecken der e-card mit einer eMED-ID abrufen und eine zugehörige Abgabe speichern. Dazu muss eine eMED-ID Assertion angefordert werden. Dazu wird die eMED-ID über das ELGA-Berechtigungssystem an die e-Medikation übermittelt. Diese validiert die eMED-ID und stellt nach positiver Prüfung eine Assertion aus. Diese ermöglicht den Zugriff auf die der eMED-ID zugeordneten Rezeptdaten innerhalb einer konfigurierbaren Gültigkeitsdauer (Default: 2 Stunden).

==eMED-ID (Dokumenten-ID) anfordern==
===Beschreibung===
Zur Speicherung eines e-Medikations-Dokuments muss als Dokumenten-ID eine eMED-ID verwendet werden. Diese ID wird von der e-Medikation generiert. eMED-IDs können auf Vorrat angefordert werden.

===Vorbedingung ===
Siehe Vorbedingung im Anwendungsfall „[[ILF:e-Medikation#eMED-ID-Assertion_anfordern|eMED-ID-Assertion anfordern“]].

===Akteure===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Einrichtung der Pflege
* Apotheke

===Ablauf===
Der Akteur möchte ein e-Medikations-Dokument speichern und fordert dazu eine eMED-ID an.

Die eMED-ID kann als Data-Matrix-Code im JPG-Format und als Zeichenkette zur Verfügung gestellt werden.

Der Data-Matrix-Code beinhaltet zusätzliche Daten zum Rezept und ermöglicht eine Vereinfachung des Prozesses bei der Abgabe.

Beispiele (1. mit und 2. ohne Versicherungsnummer):
# eMED^12^XST3KU892344^20131025^1234010170
# eMED^11^XST3KU892344^20131025
Die erstellten e-Medikation-Dokumente werden zu der angeforderten eMED-ID gespeichert und sind in weiterer Folge über diese abrufbar.

==Verordnung(en) mit Rezept anlegen==
===Allgemein===
Im Zuge der Behandlung stellt der Arzt fest, dass dem ELGA Teilnehmer ein oder mehrere Arzneimittel verordnet werden müssen. Eine Verordnung besteht immer nur aus genau einer Medikation (= ein Arzneimittel). Das Rezept kann aus mehreren Verordnungen bestehen und bildet somit die Klammer über die Verordnungen. Das Rezept mit den Verordnungen wird mit einer eindeutigen eMED-ID versehen.

Die Prüfungen der Arzneimittel z.B. auf potentielle Wechselwirkungen, Kontraindikationen, Dosierungen, etc. erfolgt in der Eigenverantwortung des Arztes und ist nicht Gegenstand der e-Medikation.

Eine Speicherung von Verordnungen ohne Zuordnung eines Rezeptes ist nicht gültig. Die Verordnung wird als geprüft angesehen, wenn die zugeordnete Verordnung in e-Medikation gespeichert ist.

===Vorbedingung ===
* ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/ Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
* e-Medikation Vorbedingung: Anfordern einer eMED-ID (Dokumenten-ID)

===Akteure===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Einrichtung der Pflege

===Ablauf===
Die Erfassung eines Rezepts mit Verordnung stellt folgende Prozessschritte in der GDA-Software dar:
* Arzneimittel auswählen: Der Arzt wählt eine oder mehrere Arzneimittelspezialitäten aus einem Katalog („''ASP-Liste''“, die Liste der humanen Arzneispezialitäten gelistet nach PZN) aus, wobei Handelsname, Pharmazentralnummer (PZN) sowie andere Daten zur Beschreibung des Arzneimittels (Stärke, Darreichungsform, Packungsgröße, Zulassungsnummer etc.) automatisch aus einem Katalog6 mit allen ELGA-relevanten Arzneimittelspezialitäten übernommen werden können.
* eMED-ID anfordern: Die Vergabe der eindeutigen eMED-ID erfolgt zentral durch die Serverkomponente e-Medikation und kann über eine entsprechende Schnittstelle angefordert werden.
* Arzneimittel ausnehmen: Arzneimittel können von der Speicherung in e-Medikation ausgenommen werden (funktionale Anforderung an die GDA-Software, siehe ELGA Usability-Styleguide & Situatives Opt-Out [2],[3],[4])
* Rezept mit Verordnung in e-Medikation speichern: Prüfung der Eingabedaten
* Rezept drucken (Anforderung an die GDA-Software, kein Teil in der e-Medikation). Die eMED-ID soll, sofern technisch möglich, sowohl als Klartext als auch als maschinenlesbarer Code (2D-Matrix-Code) auf dem Papierrezept aufgedruckt werden (§18 Abs. 4 Z. 4 GTelG 2012) um die Versorgungskontinuität (verbesserte Arbeitsabläufe) als auch die anwenderfreundliche Umsetzung der e-Medikation zu unterstützen. Wird die eMED-ID nicht aufgedruckt, ist die Usability in den Apotheken stark eingeschränkt, da immer die e-card für den Zugriff auf die e-Medikation gesteckt werden muss. Darüber hinaus ist die Prüfhoheit für Verordnungen, die bei ÄrztInnen liegt, aufgelöst, da der Apotheker die e-card stecken muss, und bei jeder Abgabe die vollständige Medikationsliste zur Prüfung vorgelegt bekommt. Folglich kann eine Abgabe nicht in der eMedikation registriert werden, falls ein Patient das Rezept nicht persönlich einlösen kann (z.B. weil er bettlägrig ist), denn die e-card darf nicht weitergegeben werden.

Der Arzt kann pro „Patientenkontakt“ (Besuch) mehrere Rezepte mit Verordnungen in e-Medikation speichern; Rezepte können jedoch nur einzeln übermittelt werden. Das Rezept mit den Verordnungen ist sofort nach Speicherung in e-Medikation gültig.

Anmerkungen zu den Datenfeldern:

Das Rezept wird durch eine Rezeptart gekennzeichnet, um die Gültigkeitsdauer prüfen zu können. In e-Medikation werden folgende Rezeptarten berücksichtigt:
* Kassenrezept – 1 Monat gültig; eine Einlösung möglich;
* Privatrezept - 1 Monat gültig
** Das 1 Monat bezieht sich auf die erste Einlösung. Der Akteur kann eine erweiterte Gültigkeitsdauer mit maximal einem Jahr festlegen.
** bis zu 365 Tage bzw. 6 Einlösungen, sofern nicht durch den Arzt eine verringerte Gültigkeitsdauer oder Einlösungsanzahl vermerkt wurde. Dabei muss das Privatrezept innerhalb des ersten Monats erstmalig eingelöst werden (§ 4 Abs. 1 RezeptpflichtG).
* Substitutionsrezept – Angabe eines „von Datums“ und „bis Datums“

Die Gültigkeitsdauer je Rezeptart folgt den rechtlichen Vorgaben. Es wird daher der Ausstellungstag in die Berechnung der Einlösefrist nicht mit eingerechnet. Die Gültigkeiten von Rezepten und somit die Verfügbarkeit in e-Medikation ergeben sich folgendermaßen:
* Wenn ein Rezept mit den Verordnungen in e-Medikation gespeichert ist, dann erhält das Rezept/Verordnung den Status OFFEN.
* Ein Kassenrezept muss innerhalb von 1 Monat eingelöst werden, sonst erhält das Rezept den Status ABGELAUFEN.
* Ein Privatrezept muss innerhalb von 1 Monat eingelöst werden, sonst erhält es den Status ABGELAUFEN.
* Ein Substitutionsrezept ist im Status ABGELAUFEN, wenn das „bis Datum“ erreicht ist.
* Die Anzahl der Einlösungen bei Privatrezepten, gibt an wie viele Einlösungen auf ein Rezept durchgeführt werden dürfen bis die Verordnung auf dem Rezept und das Rezept den Status=EINGELÖST erhält. Anzahl der Einlösungen bezieht sich immer auf ein Rezept. Solange die Anzahl der Einlösungen (Abgaben) nicht erreicht wurde, haben die Verordnung und Rezept den Status=OFFEN.
* Die Rezeptart ist für die Regeln der Einlösung notwendig. Siehe dazu Use Case “Medikationsabgabe über Verordnung einlösen“ und „[[ILF:e-Medikation#Abgabe_mittels_eMED-ID_durchf.C3.BChren|Medikationsabgabe mit eMED-ID]]“
Es können nur Arzneimittel verordnet werden, die in der Liste der Arzneimittelspezialitäten („ASP-Liste“) vorkommen und als gültig vermerkt sind (ELGA_Gültigkeit = true). Ohne Verordnungsbezug kann nur die Abgabe jener OTC-Präparate in der e-Medikation gespeichert werden, die auch wechselwirkungsrelevant sind.

6 Der aktuelle Katalog „Liste der humanen Arzneispezialitäten gelistet nach PZN“ (ASP-Liste) wird von der AGES, der Österreichischen Agentur für Ernährungssicherheit bereitgestellt und kann über den Terminologieserver frei bezogen werden: https://termpub.gesundheit.gv.at/.

====Ergebnis im Gutfall====
Die am Rezept angegebenen Verordnungen sind im Status OFFEN in e-Medikation gespeichert. Die eMED-ID wurde vergeben (und ist am Rezept aufgedruckt).

====Ergebnis im Fehlerfall====
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Information über den Fehler. 
''Hinweis: Die Ausstellung eines Papierrezeptes darf durch eine etwaiges „Nicht-funktionieren“ der e-Medikation '''nicht''' verhindert werden.''

==Rezept mit Verordnung(en) abrufen==
===Beschreibung ===
Im Zuge der Abgabe eines Arzneimittels in einer Apotheke (nach Identifikation mittels e-card) kann der Akteur die Rezepte samt Verordnungen zu einem ELGA Teilnehmer abrufen. Alternativ zur Identifikation mit e-card kann mittels eMED-ID ein Rezept abgerufen werden
===Vorbedingung ===
* ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
Alternativ zu einem Patientenkontakt kann dieser Anwendungsfall auch mit einer eMED-ID-Assertion erfolgen.
* e-Medikation Vorbedingung: Verordnungen vorhanden

===Akteure===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Apotheke
* Einrichtung der Pflege

===Ablauf===
Der Akteur kann die Verordnungen des ELGA-Teilnehmers mit den folgenden Suchfunktionen abfragen:
* Alle Verordnungen zu einer eMED-ID
* Alle Verordnungen in einem bestimmten Zeitraum
* Alle Verordnungen mit dem Status „OFFEN“ und „ABGELAUFEN“
Es gibt keine Einschränkung bei der Anzeige der Datenfelder (z.B. ausstellender GDA darf angezeigt werden). Es werden über die Schnittstelle alle verfügbaren Datenfelder zu einer Verordnung/Rezept geliefert.

====Ergebnis im Gutfall====
Im Gutfall werden dem Akteur die angeforderten Rezepte/ Verordnungen sowie die dazugehörigen Korrekturmeldungen („Phamrmazeutischen Empfehlungen“) zurückgeliefert und stehen zur weiteren Verwendung zur Verfügung.

====Ergebnis im Fehlerfall====
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Information über den Fehler.

==Verordnung/Rezept stornieren==
===Beschreibung ===
Der Akteur kann das Rezept oder die Verordnung stornieren. Es sind folgende Fälle möglich:
* Eine einzelne Verordnung stornieren (über eine Korrekturmeldung; entspricht einer Pharmazeutischen Empfehlung). Dieser Fall ist für die Änderung des Rezeptes durch einen vom Aussteller unterschiedlichen Arzt vorgesehen. Die stornierte Verordnung kann weiterhin über die e-Medikation abgefragt, jedoch nicht mehr abgegeben werden
* Ein ganzes Rezept stornieren (über ein Update der XDS-Metadaten oder alle Verordnungen über eine Korrekturmeldung stornieren). Dieser Fall ist für die Korrektur eines Irrtums durch den ausstellenden Arzt vorgesehen. Das stornierte Rezept ist in der e-Medikation nicht mehr verfügbar. Das Storno über ein Update der XDS-Metadaten entspricht dem Storno eines Dokumentes und ist deshalb technisch vom Storno einer Verordnung, welche ein Teil eines Rezepts (Dokuments) ist, zu unterscheiden.

===Vorbedingung ===
* ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/ Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
* Vorbedingung Storno Rezept: Alle Verordnungen des Rezeptes sind im Status=OFFEN und keine Verordnung wurde durch eine Korrekturmeldung (=Pharmazeutischen Empfehlung) geändert. Nur innerhalb eines beschränkten Zeitraums (Defaultwert 2 Stunden) nach Erstellung des Rezepts durch den Ersteller selbst möglich.
* Vorbedingung Storno Verordnung: Das Storno einer Verordnung via Korrekturmeldung (=Pharmazeutischen Empfehlung) ist möglich, wenn die Verordnung im Status=OFFEN ist. Dieses Storno ist durch jeden behandelnden Arzt möglich, auch wenn dieser nicht der Ersteller der Verordnung ist.

===Akteure===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Einrichtung der Pflege
===Ablauf===
* Einzelne Verordnung stornieren:
** Eine Verordnung kann mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) storniert werden. Der Akteur bestimmt die Verordnung (oder mehrere), welche storniert werden soll/sollen. Die Auswahl erfolgt über die VerordnungsID. Die Verordnung erhält den Status „STORNIERT“. Eine Stornierung ist nur zulässig, falls die referenzierte Verordnung bereits in e-Medikation vorhanden ist und den Status „OFFEN“ besitzt. Bereits abgegebene Verordnungen können nicht mehr verändert bzw. storniert werden. Ein Storno via pharmazeutische Empfehlung kann von jedem Arzt (unabhängig ob er der Ersteller der Verordnung ist) vorgenommen werden.
** Da das Storno einer Verordnung über eine pharmazeutische Empfehlung getätigt wird und diese selbst wiederum ein Dokument ist, kann die pharmazeutische Empfehlung storniert werden (nur vom Ersteller innerhalb eines definierten Zeitraums) und somit die Verordnung wieder in den Status = OFFEN gesetzt werden. Das Storno eines Dokuments (z.B. von einem Rezept) kann aber nicht rückgängig gemacht werden.
* Ganzes Rezept stornieren: Ein Rezept gilt als storniert, wenn einer der folgenden beiden Methoden angewandt wird:
** Der Akteur bestimmt alle Verordnung des Rezepts und storniert jede einzelne Verordnung des Rezepts. Das Rezept erhält den Status = STORNIERT, wenn alle zugeordneten Verordnungen den Status = STORNIERT aufweisen.
** Der Akteur bestimmt das Rezept mit den Verordnungen (über eMED-ID). Es wird ein Update der Metadaten des Rezepts ausgeführt. Dies kann nur vom Ersteller des Rezepts, innerhalb eines beschränkten Zeitraums (Defaultwert 2 Stunden) durchgeführt werden.

Ein Storno des ganzen Rezepts (Dokuments) kann nicht mehr rückgängig gemacht werden
====Ergebnis im Gutfall====
Die Verordnung bzw. das Rezept erhalten den Status= STORNIERT.
====Ergebnis im Fehlerfall====
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Die Verordnung bzw. das Rezept behält den Status „OFFEN“.

==Verordnung/Rezept ändern==
===Beschreibung===
Der Arzt ändert eine bereits in e-Medikation gespeicherte Verordnung. Die Änderung darf von jedem Arzt vorgenommen werden, unabhängig davon, ob der Arzt die Verordnung erstellt hat oder nicht.
===Vorbedingung===
* ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
* e-Medikation Vorbedingung: Verordnung mit dem Status=OFFEN ist vorhanden.

===Akteure ===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Einrichtung der Pflege

===Ablauf===
Eine Verordnung kann mittels einer Korrekturmeldung (=Pharmazeutischen Empfehlung) geändert werden. Der Arzt kann nur die folgenden Datenfelder einer Verordnung ändern, nicht aber das verordnete Arzneimittel oder die Menge selbst:
* Art der Anwendung
* Zusatzinformation
* Alternative Einnahme
* Tagesdosierung
* Morgen Dosierung
* Mittags Dosierung
* Abends Dosierung
* Nachts Dosierung
* Frequenz
* Therapieart
* Tagesangabe
Verordnungen mit dem Status ABGELAUFEN, NICHT DISPENSIERT, EINGELÖST, STORNIERT können nicht geändert werden. Die Medikation (z.B. Handelsname) einer Verordnung kann NICHT geändert werden.

Ist eine Änderung der Medikation notwendig, kann der Akteur eine neue Verordnung anlegen und eine Stornierung der zu ändernden Verordnung veranlassen (Rücksprache). Das gleiche gilt für die Angabe „Menge“, dazu muss der Arzt ein weiteres Rezept mit einer entsprechenden Verordnung ausstellen. Die Verringerung der Menge kann nicht abgebildet werden.
* Die eMED-ID am Rezept bleibt bei einer Änderung der Verordnung gleich.

Der Aussteller des Rezepts mit der entsprechenden Verordnung bleibt gleich und wird nicht durch die Änderung der Verordnung verändert.

Der Arzt kann folgende Datenfelder von Verordnungen eines Rezepts ändern:
* Zusatzinformation (im narrativen Teil des CDA)
* Alternative Einnahme
* Dosierung
* Frequenz (Einnahmedauer)
* Therapieart
Rezeptart und Gültigkeitsdauer können nicht geändert werden.

====Ergebnis im Gutfall====
Im Gutfall wird die Änderung der Datenfelder der Verordnung über eine Korrekturmeldung durchgeführt und in e-Medikation gespeichert.

====Ergebnis im Fehlerfall====
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Die in e-Medikation gespeicherte Verordnung wurde nicht verändert. Der Akteur erhält eine Information über den Fehler.

==Abgabe mittels eMED-ID durchführen==
===Beschreibung===
Der ELGA Teilnehmer will ein Rezept einlösen und übergibt hierzu in der Apotheke das Rezept. Die Verordnungen am Rezept sind in e-Medikation gespeichert.

Um eine Vereinfachung des Prozessablaufes der Einlösung eines Rezepts in der Apotheke zu ermöglichen, kann über einen maschinenlesbaren Code (eMED-ID) das Rezept samt den zugeordneten Verordnungen ohne Übergabe der e-card abgerufen werden.

Es dürfen dem Apotheker bzw. hausapothekenführenden Arzt nur die dem Rezept zugeordneten Verordnungen angezeigt werden. Die Apotheke bzw. der hausapothekenführende Arzt kann eine Abgabe nur zu den abgerufenen Verordnungen in e-Medikation speichern.

===Vorbedingung===
* ELGA-Vorbedingung: GDA ist autorisiert
* e-Medikation Vorbedingung: Rezept mit aufgedruckter, lesbarer eMED-ID ist vorhanden
===Akteure===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Einrichtung der Pflege
* Apotheke

===Ablauf===
Die Erfassung einer Abgabe stellt folgende Prozessschritte in der GDA-Software dar:
* eMED-ID anfordern: Die Vergabe der eMED-ID erfolgt zentral durch die e-Medikation und kann über eine entsprechende Schnittstelle angefordert werden.
* Rezept mit Verordnung über die eMED-ID abrufen
* Abgabe mit der eMED-ID in e-Medikation speichern: Prüfung der Eingabedaten
Bei der automatischen Übernahme scannt der Apotheker bzw. hausapothekenführende Arzt den Datamatrixcode (eMED-ID) des Rezepts ein. Somit wird das Rezept identifiziert und die angeführten Verordnungen aus e-Medikation abgerufen.

Der Apotheker bzw. hausapothekenführende Arzt kann die Daten aus der Verordnung für die Speicherung der Abgabe übernehmen bzw. kann diese neu erfassen oder ändern.

Anmerkungen zur Fachlogik: Folgende Regeln werden durchgeführt:
* Damit die Verordnung eingelöst werden kann (Verordnung zu einer Medikationsabgabe), muss die Verordnung den Status OFFEN haben.
* Rezepte mit der Rezeptart=Privatrezepte können von mehreren Akteuren eingelöst werden, z.B. verschiedene Apotheken.
* Rezepte mit der Rezeptart=Kassenrezept und Substitutionsrezept kann nur von einem Akteur eingelöst werden – somit müssen alle Verordnungen zu einem Rezept abgegeben werden. Verordnungen, die nicht abgegeben werden, erhalten den Status NICHT DISPENSIERT
* Rezepte mit dem Status ABGELAUFEN können organisatorisch weiterhin eingelöst werden, zur Speicherung der Abgaben in e-Medikation ist dann jedoch die Identifikation der ELGA-TeilnehmerInnen mittels e-card erforderlich (die Einlösung über eMED-ID ist in diesem Fall nicht möglich, die Abgabe erfolgt im Sinne einer „Abgabe ohne Verordnung“).

====Sonderfall====
'''Austausch:''' Wird ein Arzneimittel verordnet, welches in der Apotheke nicht vorhanden ist, so kann im Rahmen der gesetzlichen Bestimmungen, der Apotheker bzw. hausapotheken-führender Arzt ein wirkstoffgleiches Arzneimittel bzw. nach Rücksprache mit dem Arzt ein alternatives Arzneimittel abgeben.

Jedenfalls ist das tatsächlich abgegebene Arzneimittel in e-Medikation zu speichern und trotzdem der Verordnung oder dem Rezept zuzuordnen, um die zugrunde liegende Verordnung einzulösen. Etwaige weitere nicht eingelöste Verordnungen eines Rezeptes können dann nicht mehr abgegeben werden, da sie in den Status „abgegeben“ gesetzt werden.

Die Zuordnung erfolgt durch die Übergabe der VerordnungsID in den Abgabedaten. Es wird nicht geprüft, ob das Arzneimittel in der Abgabe mit dem verordneten Arzneimittel übereinstimmt bzw. wirkungsgleich ist. Das Ergebnis der Rücksprache kann als „ergänzende Informationen zur Abgabe“ miterfasst werden.

'''Besorger:''' Der Prozess des „Besorgers“ (ein Arzneimittel ist nicht lagernd und muss bestellt werden) wird in e-Medikation abgebildet. Das Rezept wird von der Apotheke eingelöst und die Abgabe wird als „Teilabgabe“ gekennzeichnet (siehe Markierung FFP „First Fill, Part Fill“ oder RFP „Refill - Part Fill“). Es wird die Verordnung nicht in den Status „EINGELOEST“ versetzt und es können solange weitere Abgaben dispensiert werden, bis eine Abgabe mit der Markierung RFC „Refill - Complete“ gespeichert wird. Die Kennzeichnung zeigt, dass das Arzneimittel dem Patienten noch nicht ausgehändigt wurde. Die Kennzeichnung zeigt auch, ob alle Packungen einer Verordnung bzw. teilweise Packungen einer Verordnung bestellt werden. Solange eine Abgabe mit der Kennzeichnung „Besorger“ vorhanden ist, ist die Abgabe mit der eMED-ID abrufbar.

Der Prozess einer „Teilabgabe“ eines Rezeptes kann mit obiger Logik des „Besorgers“ auch abgebildet werden.

====Ergebnis im Gutfall====
Die Verordnung ist eingelöst und die Medikationsabgabe ist gespeichert. Die Verknüpfung von Verordnung und Abgabe ist vorhanden. Teilabgaben sind entsprechend markiert.

====Ergebnis im Schlechtfall====
* Der Akteur erhält eine Fehlermeldung.

==Abgabe über e-card durchführen ==
===Beschreibung ===
Der ELGA Teilnehmer will ein Rezept einlösen und übergibt hierzu die e-card und das Rezept. Die Verordnungen am Rezept sind in e-Medikation gespeichert.

Der Apotheker bzw. hausapothekenführende Arzt ruft die offenen Verordnungen des ELGA-Teilnehmers ab. Der Apotheker wählt die entsprechende(n) Verordnung(en) und erfasst die Medikationsabgabe.
===Vorbedingung ===
* ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer wurde mittels e-card identifiziert, eine gültige Kontaktbestätigung/ Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
* e-Medikation Vorbedingung: Verordnungen sind in e-Medikation gespeichert

===Akteure===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Einrichtung der Pflege
* Apotheke

===Ablauf===
Es werden 3 Prozessschritte durchlaufen:

Die Erfassung einer Abgabe stellt folgende Prozessschritte in der GDA-Software dar:
* eMED-ID anfordern: Die Vergabe der eMED-ID erfolgt durch die „e-Medikation“ und kann über eine entsprechende Schnittstelle angefordert werden.
* Rezept mit Verordnung abrufen: Der Apotheker bzw. hausapothekenführende Arzt kann die Daten aus der Verordnung übernehmen bzw. kann er diese neu erfassen oder ändern.
* Abgabe mit der eMED-ID in e-Medikation speichern: Prüfung der Eingabedaten. Das Übermitteln von mehreren Abgaben kann innerhalb einer Transaktion erfolgen, sofern sich alle Abgaben auf dasselbe Rezept beziehen. Bei der Abgabe eines Kassenrezeptes ist es erforderlich alle Abgaben innerhalb einer Transaktion zu speichern, wird eine Verordnung nicht abgegeben so muss als Leerabgabe übermittelt werden.

Das Einlösen eines Rezepts nach Ablauf der Gültigkeit wird durch e-Medikation nicht verhindert. Die Abgabe wird in diesem Fall ohne Verordnungsbezug in e-Medikation gespeichert.

Anmerkung zur Fachlogik: 
Die Abgabe mittels e-card unterliegt den folgenden Regeln:
* Damit die Verordnung eingelöst werden kann (Verordnung zu einer Medikationsabgabe) muss die Verordnung den Status= OFFEN haben.
* Rezepte mit der Rezeptart=Privatrezepte können von mehreren Akteuren eingelöst werden – z.B. verschiedene Apotheken
* Rezepte mit der Rezeptart=Kassenrezept und Substitutionsrezept können nur von einem Akteur eingelöst werden – somit müssen alle Verordnungen zu einem Rezept abgegeben werden. Verordnungen, die nicht abgebgeben werden, müssen als „Nichtabgabe“ dokumentiert werden und erhalten demnach den Status=NICHT DISPENSIERT. Der Apotheker kann in einem Freitextfeld Anmerkungen zur Nichtabgabe erfassen.

====Sonderfall====
* '''Austausch''': siehe Anwendungsfall „[[ILF:e-Medikation#Abgabe_mittels_eMED-ID_durchf.C3.BChren|Abgabe mittels eMED-ID durchführen]]“
* '''Besorger''': siehe Anwendungsfall „[[ILF:e-Medikation#Abgabe_mittels_eMED-ID_durchf.C3.BChren|Abgabe mittels eMED-ID durchführen]]“
* '''OTC:'''
** Erfolgt die Abgabe eines OTC auf Basis einer Verordnung, wird die Abgabe immer in e-Medikation gespeichert, auch wenn dieses OTC nicht in der AGES Liste als wechselwirkungsrelevanten Arzneispezialitäten geführt ist.
** Erfolgt die Abgabe eines OTC ohne Verordnung bzw. Verordnungsbezug, darf die Abgabe nur in e-Medikation gespeichert werden, wenn dieses OTC in der ASP-Liste als wechselwirkungsrelevante Arzneispezialität geführt ist

====Ergebnis im Gutfall====
Die Verordnung ist eingelöst und die Medikationsabgabe ist gespeichert. Die Verknüpfung von Verordnung und Abgabe ist vorhanden.

====Ergebnis im Schlechtfall====
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Fehlermeldung.

==Abgabe ohne Verordnung durchführen==
===Beschreibung===
Der Akteur speichert die abgegebenen Arzneimittel in e-Medikation, welche tatsächliche abgegeben werden. Dieser Prozess wird durchgeführt bei
* Abgabe von nicht verordneten Arzneimitteln (Abgabe von OTC)
* wenn ein Papierrezept vorhanden ist und keine Verordnung(en) in e-Medikation eingetragen wurde(n)
* Abgabe eines Arztmusters
* Nacherfassung von bereits abgegebenen Arzneimitteln
===Vorbedingung ===
* ELGA-Vorbedingung: ELGA Teilnehmer wurde mittels e-card identifiziert bzw. gültige Kontaktbestätigung von Akteur und ELGA Teilnehmer ist vorhanden.
* e-Medikation Vorbedingung: keine
===Akteure===
* Arzt im niedergelassenen Bereich
* Apotheke
* Krankenanstalt
* Einrichtung der Pflege
===Ablauf===
Die Erfassung einer Abgabe stellt folgende Prozessschritte in der GDA-Software dar:

*eMED-ID anfordern: Die Vergabe der eMED-ID erfolgt zentral durch die e-Medikation und kann über eine entsprechende Schnittstelle angefordert werden.
*Abgabe mit der eMED-ID in e-Medikation speichern: Prüfung der Eingabedaten

Der Akteur erfasst die Medikationsabgabe. Wenn eine Medikationsabgabe (ohne Rezept/Verordnung) in e-Medikation gespeichert wird, dann gilt die Medikationsabgabe als vom Akteur geprüft. Wenn ein Papierrezept ohne e-Medikations-Verordnung vorhanden ist, dann obliegt es dem abgebenden Akteur diese zu prüfen.

Im Rahmen der Nacherfassung von bereits erfolgten Abgaben wird als Erfassungsdatum der Zeitpunkt der Nacherfassung gesetzt während als Abgabedatum das in der Vergangenheit liegende Datum der tatsächlichen Abgabe eintetragen wird.

Beispiele für Nacherfassungsgründe:

*Arzneimittel im Ausland bezogen
*Medikationsdaten aus der GDA-Software vor Start der e-Medikation

====Ergebnis im Gutfall====
Die Medikationsabgabe ist in e-Medikation gespeichert.

====Ergebnis im Fehlerfall====
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Fehlermeldung.

==Abgabe abrufen==
===Beschreibung ===
Im Zuge der Behandlung eines ELGA Teilnehmers kann der Akteur die Medikationsabgaben eines ELGA Teilnehmers abrufen.
===Vorbedingung ===
* ELGA-Vorbedingung: ELGA Teilnehmer wurde mittels e-card identifiziert bzw. gültige Kontaktbestätigung von Akteur und ELGA Teilnehmer ist vorhanden.
* e-Medikation Vorbedingung: Abgaben in den letzten 365 Tagen vorhanden
===Akteure===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Apotheke
* Einrichtung der Pflege
===Ablauf===
Der Akteur fragt die Medikationsabgabe des identifizierten ELGA-Teilnehmers ab. Folgende Filterungen/Suchfunktionen können vorgenommen werden:
* eMED-ID
* Zeitraum
Stornierte Abgaben können nicht abgerufen werden. Es gibt keine Einschränkung bei der Anzeige der Datenfelder (z.B. abgebender GDA darf angezeigt werden). Es werden alle Datenfelder zu einer Abgabe über die Schnittstelle zur Verfügung gestellt.

====Ergebnis im Gutfall====
Im Gutfall werden dem Akteur die angeforderten Medikationsabgaben als auch zugehörige Korrekturmeldungen zurückgeliefert und stehen zur weiteren Verwendung zur Verfügung.
====Ergebnis im Fehlerfall====
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Fehlermeldung.

== Abgabe stornieren==
===Beschreibung ===
Der Akteur kann die Abgabe stornieren (z.B., wenn versehentlich das „falsche“ Arzneimittel eingelesen wurde oder der ELGA Teilnehmer das Arzneimittel nicht bezahlen kann und daher nicht ausgehändigt bekommt). Das Stornieren der Abgabe ist zeitlich begrenzt7 und darf nur vom Ersteller der Abgabe durchgeführt werden.

7 Die derzeitige Regelung für den Zugriff sieht eine Begrenzung auf 2 Stunden vor.

===Vorbedingung ===
* ELGA-Vorbedingung: Akteur und ELGA Teilnehmer wurden identifiziert. Ein gültiges Berechtigungsticket wurde vom ELGA-Berechtigungssystem ausgestellt
* e-Medikation Vorbedingung: Abgabe vorhanden, Status= ABGEGEBEN

===Akteure===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Einrichtung der Pflege
* Apotheke

===Ablauf===
Der Akteur bestimmt die Medikationsabgabe, welche storniert werden soll. Das Stornieren der Abgabe ist zeitlich begrenzt auf 2 Stunden und kann nur vom Ersteller der Abgabe vorgenommen werden. Die Abgabe erhält den Status=STORNIERT und kann nicht mehr abgerufen werden. Handelt es sich bei der Abgabe um eine Medikation mit einem Verordnungsbezug, dann wechselt der Status der Verordnung auf „OFFEN“.

Bei Kassen- und Substitutionsrezepten ist die Stornierung einzelner Abgaben nicht möglich, da diese Rezepte immer als ganzes abgegeben werden müssen. Durch Storno einer einzelnen Abgabe, wäre die entsprechende Verordnung offen und die restlichen Verordnungen des Kassen- oder Substitutionsrezeptes abgegeben. Daher müssen bei diesen beiden Rezeptarten immer alle Abgaben gemeinsam storniert werden.

Handelt es sich bei der Abgabe um eine Medikation ohne Verordnungsbezug, dann wird die Abgabe aus den Medikationsabgaben des ELGA Teilnehmers storniert (Status = STORNIERT).
====Ergebnis im Gutfall====
Im Gutfall wird die Stornierung der Medikationsabgabe durchgeführt. Die Abgabe erhält den Status STORNIERT, die entsprechende Verordnung den Status OFFEN.
====Ergebnis im Fehlerfall====
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Fehlermeldung.

==Abgabe absetzen==
===Beschreibung ===
Im Patientengespräch erfährt der Akteur, dass eine erfolgte Medikationsabgabe vom ELGA Teilnehmer nicht eingenommen wird. In diesem Fall wurde ein Arzneimittel zwar in der Apotheke abgegeben, es wird bzw. wurde aber nicht mehr (z.B. ELGA Teilnehmer verträgt ein abgegebenes Arzneimittel nicht) eingenommen. Ein Absetzen einer Medikationsabgabe kann von jedem Akteur (außer ELGA-Teilnehmer selbst) durchgeführt werden.

===Vorbedingung ===
* ELGA-Vorbedingung: Akteur und ELGA Teilnehmer wurden identifiziert. Ein gültiges Berechtigungsticket wurde vom ELGA-Berechtigungssystem ausgestellt
* e-Medikation Vorbedingung: Abgabe vorhanden, Status= ABGEGEBEN

===Akteure===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Apotheke
* Einrichtung der Pflege

===Ablauf===
Eine Abgabe kann mittels einer Korrekturmeldung (=Pharmazeutischen Empfehlung) abgesetzt werden. Der Akteur bestimmt die abzusetzende Medikationsabgabe durch Übergabe der AbgabeID.

Der Akteur muss das Datum der Absetzung angeben. Da es kein Aufsummieren der Medikationsabgaben gibt, müssen etwaige dazugehörige Medikationsabgaben explizit abgesetzt werden.

Das Datum der Absetzung wird beim Abruf der Medikationsabgaben zur Verfügung gestellt.

Solange eine Medikationsabgabe abgerufen werden kann, kann die Medikationsabgabe auch abgesetzt werden. Im Zuge einer Absetzung erfolgen keine weiteren Prüfungen.

Das Absetzten kann via Metadatenupdate der entsprechenden Pharmazeutischen Empfehlung wieder rückgängig gemacht werden.

====Ergebnis im Gutfall====
Im Gutfall wird das Absetzen der Medikationsabgabe durchgeführt und in e-Medikation gespeichert (Status=ABGESETZT). Das Absetzdatum ist in den Abgabedatenfeldern vorhanden.

====Ergebnis im Fehlerfall====
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. . Der Akteur erhält eine Fehlermeldung. Der Status der Abgabe ist „ABGEGEBEN“.

==Abgabe ändern==
===Beschreibung===
Der Akteur kann die Daten einer Medikationsabgabe ändern (z.B. bei Einstellungen der Dosierung eines Arzneimittels). Es dürfen nur definierte Datenfelder geändert werden.
===Vorbedingung===
* ELGA-Vorbedingung: Akteur und ELGA Teilnehmer wurden identifiziert. Ein gültiges Berechtigungsticket wurde vom ELGA-Berechtigungssystem ausgestellt
* e-Medikation Vorbedingung: Abgabe vorhanden, Status=ABGEGEBEN
===Akteure ===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Apotheke
* Einrichtung der Pflege

===Ablauf===
Der Akteur bestimmt die zu ändernde Medikationsabgabe durch Übergabe der AbgabeID.

Der Akteur kann nur bestimmte Datenfelder einer Medikationsabgabe ändern, nicht aber das Arzneimittel oder die Menge selbst. Folgende Datenfelder können verändert werden:
* Art der Anwendung
* Zusatzinformation
* Alternative Einnahme
* Tagesdosierung
* Morgen Dosierung
* Mittags Dosierung
* Abends Dosierung
* Nachts Dosierung
* Tagesangabe
* Frequenz
* Therapieart
* Die Medikation (z.B. Handelsname) einer Medikationsabgabe kann NICHT geändert werden. Der GDA der Medikationsabgabe bleibt der gleiche und darf nicht durch die Änderung verändert werden.

====Ergebnis im Gutfall====
Im Gutfall wird die Änderung der Medikationsabgabe durchgeführt und in e-Medikation gespeichert.

====Ergebnis im Fehlerfall====
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden.

==Medikationsliste abrufen==
===Beschreibung ===
Im Zuge der Behandlung eines ELGA Teilnehmers möchte der Akteur die Medikationsliste des ELGA Teilnehmers abrufen. Die Medikationsliste fasst offene Verordnungen und Abgaben zusammen.

===Vorbedingung ===
* ELGA-Vorbedingung: Akteur und ELGA Teilnehmer wurden identifiziert. Ein gültiges Berechtigungsticket wurde vom ELGA-Berechtigungssystem ausgestellt
* e-Medikation Vorbedingung: keine

===Akteure===
* Arzt im niedergelassenen Bereich
* Krankenanstalt
* Apotheke
* Einrichtung der Pflege
* ELGA-Teilnehmer

===Ablauf===
Der Akteur kann die gesamte, konsolidierte Medikationsliste (sortierbare Zusammenfassung über Zulassungsnummer und Abgabe bzw. Verordnungsdatum) abrufen.

Die Medikationsliste wird beim Aufruf von der e-Medikation erstellt und enthält die aktuell gültigen Abgaben bzw. Verordnungen (z.B. bei einer Änderung wird nur die geänderte Dosierung angezeigt).

====Ergebnis im Gutfall====
Im Gutfall wird dem Akteur die angeforderte Medikationsliste zurückgeliefert und steht zur weiteren Verwendung zur Verfügung. Sind keine relevanten Verordnungen und Abgaben vorhanden, so wird eine „leere Liste“ retourniert.

====Ergebnis im Fehlerfall====
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Information über den Fehler.

===Alternativer Ablauf===
Bei der Ermittlung der aktuellen Medikation eines Patienten ist die Verwendung der konsolidierten Medikationsliste optional.

Alternativ können alle verfügbaren (Quell)Daten der e-Medikation (das sind die Dokumenten-klassen Rezept (Prescription), Abgabe (Dispense), und die entsprechenden Korrektur-meldungen bzw. Pharmazeutische Empfehlungen (Pharmaceutical Advice) separat entsprechend dem im IHE Pharmacy Profil definierten Abfragen („Queries“) abgerufen und in der lokalen Software weiterverarbeitet werden.

Dies hat den Vorteil, dass man auch die Historie der Änderungen sehen kann, welche in der Implementierung der Medikationsliste bereits eingearbeitet sind.

Andererseits fehlen aber dann die Zusatzinformationen, mit denen die Arznei-Entries in der Medikationsliste ergänzt werden (z.B. die Zulassungsnummer).

ILF Diskussion:E-Impfpass

2021-05-20T07:48:34Z

Kuttin:

=Bekannte Probleme=
-
=Diskussion=
''Zu diesen Punkten besteht noch Diskussionsbedarf.''
Diskussionsbeiträge bitte an [mailto:office@hl7.at office@hl7.at] senden.
===Kontraindikationen (Allergien etc.)===
Die AG hat im Oktober 2018 beschlossen, Kontraindikationen nicht in den e-Impfpass aufzunehmen.
===Impfreaktionen und Nebenwirkungen===
Die AG hat im Oktober 2018 beschlossen, Impfreaktionen und Nebenwirkungen nicht in den e-Impfpass aufzunehmen.
===Passive Immunisierung und Hyposensibilisierung ("Allergieimpfungen")===
Die AG hat im Oktober 2018 beschlossen, nur als Impfungen NUR aktive Immunisierungen in den e-Impfpass aufzunehmen. Nicht dokumentiert wird die Gabe von Immunglobulinen (Passive Immunisierung) oder die Verabreichung von Allergenen zur Hyposensibilisierung ("Allergieimpfung")
===Custodian / Verwahrer des originalen Dokuments bei Update Immunisierungsstatus===
Beim e-Impfpasses kann die Originaldokumentation ausschließlich in der zentralen e-Impfpass Applikation erfolgen, diese wäre dann auch als Verwahrer anzugeben.

 

=Release-Log=
==Version 1.1.0==
Folgende Änderungen wurden mit Version 1.1.0+20210512 eingeführt
===[https://jira-neu.elga.gv.at/browse/ELGA-1024 ELGA-1024] Präzision der Datumsangabe bei Impfungen===
[[ILF:E-Impfpass#Immunization_Entry|11.4.4.7 Immunization Entry]], substanceAdministration/effectiveTime:

Impfungen können mit unterschiedlich genauen Datumsangaben gespeichert werden.

*Eine aktuell erfasste Impfung muss entweder als Impfdatum taggenau oder als Impfzeitpunkt sekundengenau erfasst werden. (YYYYMMDD oder YYYMMDDhhmmss)
*'''Nur beim Nachtragen''' von Impfungen (z.B. aus dem Papierimpfpass) sind auch ungenauere Angaben Jahr-Monat oder Jahr erlaubt (YYYYMM oder YYYY). Die bisherige Angabe erlaubt die Fehlinterpretation, dass ungenaue Datumsangaben auch für aktuelle Impfungen zulässig wären.

===[https://jira-neu.elga.gv.at/browse/ELGA-1089 ELGA-1089] Beschreibung von referenceRange korrigiert===
[[ILF:E-Impfpass#Antik.C3.B6rper-Bestimmung_Laboratory_Observation_Entry|11.4.4.17 Antikörper-Bestimmung Laboratory Observation Entry]], observation/referenceRange:

Die Beispiele in der Beschreibung dieses Elements waren an dieser Stelle falsch und wurden entfernt.

===[https://jira-neu.elga.gv.at/browse/ELGA-1082 ELGA-1082] Änderung der Bezeichnung von "Impfindikation"===
[[ILF:E-Impfpass#Dataset|10.1 Dataset]]:

Aufgrund der Verwechslungsgefahr der Impfindikation bei Abrechnung mit Indikationsgruppen wurde die Bezeichnung von "Impfindikation" zu "Impfgrund für Abrechnung" geändert.

===[https://jira-neu.elga.gv.at/browse/ELGA-1076 ELGA-1076] Beispiel-Snippet ergänzt===
[[ILF:E-Impfpass#Immunization_Entry_Impfung_nicht_angegeben|11.4.4.8 Immunization Entry Impfung nicht angegeben]]:

Im Beispiel-Snippet fehlte das verpflichtende Attribut substanceAdministration/code /@displayName und wurde ergänzt.

===[https://jira-neu.elga.gv.at/browse/ELGA-827 ELGA-827] Unterstützung der Angabe von Dosismengen bei Impfempfehlungen===
[[ILF:E-Impfpass#Immunization_Recommendation_Entry|11.4.4.9 Immunization Recommendation Entry]], substanceAdministration/doseQuantity:

Bei Impfempfehlungen KANN optional eine Dosismenge (z.B. 2 Ampullen) angegeben werden.

===[https://jira-neu.elga.gv.at/browse/ELGA-1101 ELGA-1101] Unterstützung der Angabe von Zusatzklassifikationen für Impfungen===
[[ILF:E-Impfpass#Zusatzklassifikation_.28f.C3.BCr_Impfungen.29|11.4.4.21 Zusatzklassifikation für Impfungen]] als optionales Element in [[ILF:E-Impfpass#Immunization_Entry|11.4.4.7 Immunization Entry]], substanceAdministration/entryRelationship[3]:

Ein optionales Element zur Aufnahme zusätzlicher strukturierter Information pro Impfung wurde ergänzt, zB eine Klassifizierung der Umgebung, in der die Impfung stattgefunden hat, etwa eine Impfstraße, ein Pflegeheim, Krankenhaus o.Ä. ("Impfsetting")

Die Art der Information wird über den Code angegeben, der Wert über den Value. Ein zusätzlicher erklärender Freitext kann im Text-Element angegeben werden.

===[https://jira-neu.elga.gv.at/browse/ELGA-1141 ELGA-1141] Unterstützung der Angabe von Referenzen auf ein Impf-/Test- bzw. Genesungszertifikat===
Im Dokumenttyp "Kompletter Immunisierungsstatus" können von der zentralen Applikation zusätzliche Dokument-Referenzen - etwa für Genesungs- oder Impfzertifikate - in Form einer URL angegeben werden.
[[ILF:E-Impfpass#Immunization_Entry|11.4.4.7 Immunization Entry]], substanceAdministration/reference[2]

[[ILF:E-Impfpass#Impfrelevante_Erkrankungen_Problem_Concern_Entry|11.4.4.13 Impfrelevante Erkrankungen Problem Concern Entry]], substanceAdministration/reference[2]

[[ILF:E-ImpfpassAntik.C3.B6rper-Bestimmung_Data_Processing_Entry|11.4.4.15 Antikörper-Bestimmung Data Processing Entry]], substanceAdministration/reference[2]

Das optionale Elemente substanceAdministration/reference[2] wurde ergänzt. Die Klassifikation des Zertifikats erfolgt mittels substanceAdministration/reference/externalDocument/code und substanceAdministration/reference/externalDocument/code/translation/code.

Die URL zum jeweiligen Zertifikat wird in substanceAdministration/reference/externalDocument/text/reference/@value geführt.

===Referenzierter Standard veraltet: ISO/IEC 9834-8===
In Kapitel [[ILF:E-Impfpass#id-Element_II|7.1.1 id-Element II]] wird die ISO/IEC 9834-8:2005 zitiert, dieses Dokument ist mit 2009 zurückgezogen worden. Das aktuelle Ersatzdokument wäre die ISO/IEC 9834-8:2014.

===practiceSettingCode ("Fachrichtung" in XDS)===
Für den practiceSettingCode (notwendig für XDS) bitte F023 "Interdisziplinärer Bereich" oder F001 "Allgemeinmedizin" eintragen.

===Wording===
Anpassung von Begrifflichkeiten:
* Dosiskennung: Neu für Impfdosis, Teilimpfung
* Nachtragen: Beschreibung verbessert und Abgrenzung gegen "Asynchrones / verspätetes Erfassen"

=Erratum=

ILF Diskussion:E-Impfpass

2021-05-18T12:11:38Z

Kuttin: /* Erratum */

=Bekannte Probleme=
==Wording: Impfdosis==
Das Wort Impfdosis oder Dosis-Nummer beschreibt die Reihenfolgenummer in der Sequenz der Impfdosen oder die "Teilimpfungen" innerhalb eines Impfschemas.
Ein einheitliches Wording ist noch zu finden. Favorisiert wird '''Dosisnummer''' oder kurz '''Dosis'''.
==[https://jira-neu.elga.gv.at/browse/ELGA-1024 ELGA-1024] Präzision der Datumsangabe bei Impfungen==
[[ILF:E-Impfpass#Immunization_Entry|11.4.4.7 Immunization Entry]]: Impfungen können mit unterschiedlich genauen Datumsangaben gespeichert werden.
* Eine aktuell erfasste Impfung muss entweder als Impfdatum taggenau oder als Impfzeitpunkt sekundengenau erfasst werden. (YYYYMMDD oder YYYMMDDhhmmss)
* '''Nur beim Nachtragen''' von Impfungen (z.B. aus dem Papierimpfpass) sind auch ungenauere Angaben Jahr-Monat oder Jahr erlaubt (YYYYMM oder YYYY). Die bisherige Angabe erlaubt die Fehlinterpretation, dass ungenaue Datumsangaben auch für aktuelle Impfungen zulässig wären.
==[https://jira-neu.elga.gv.at/browse/ELGA-1025 ELGA-1025] Referenzierter Standard veraltet: ISO/IEC 9834-8==
In Kapitel [[ILF:E-Impfpass#id-Element_II|7.1.1 id-Element II]] wird die ISO/IEC 9834-8:2005 zitiert, dieses Dokument ist mit 2009 zurückgezogen worden. Das aktuelle Ersatzdokument wäre die ISO/IEC 9834-8:2014.
==practiceSettingCode ("Fachrichtung" in XDS)==
Für den practiceSettingCode (notwendig für XDS) bitte "Allgemeinmedizin" oder den am besten zum Sonderfach des impfenden Arzt passenden Eintrag eintragen.

=Diskussion=
''Zu diesen Punkten besteht noch Diskussionsbedarf.''
Diskussionsbeiträge bitte an [mailto:office@hl7.at office@hl7.at] senden.

==Asynchrones Erfassen (Nacherfassen) vs Nachtragen==
Der Zeitpunkt der Erfassungen von Impfungen im e-Impfpass kann direkt während der Impfung erfolgen oder auch zeitlich verzögert, zum Beispiel wenn das IT-System gerade nicht verfügbar war. Dazu sollte das Impfdatum auch auf einen Zeitpunkt in der Vergangenheit gesetzt werden können, um eine korrekte Erfassung oder asynchrone Nacherfassung der tatsächlichen Impfung durchführen zu können.
Die Nachtragung ist ein eigener Anwendungsfall - hier geht es um das Nachtragen von Impfungen, die in der Vergangenheit an anderer Stelle dokumentiert wurden und z.B. im Papierimpfpass vorliegen. Hier gelten andere Anforderungen an die bereitzustellenden Daten, etwa muss die Person erfasst werden, die den Eintrag im e-Impfpass vornimmt, aber auch der für die damalige Impfung verantwortliche Arzt. Auch können hier "historische Impfstoffe" eingetragen werden, die heute nicht mehr im Handel gelistet sind.
==Kontraindikationen (Allergien etc.)==
Die AG hat im Oktober 2018 beschlossen, Kontraindikationen nicht in den e-Impfpass aufzunehmen.

==Impfreaktionen==
Die AG hat im Oktober 2018 beschlossen, Impfreaktionen nicht in den e-Impfpass aufzunehmen.

==Custodian / Verwahrer des originalen Dokuments bei Update Immunisierungsstatus==
Beim e-Impfpasses kann die Originaldokumentation ausschließlich in der zentralen e-Impfpass Applikation erfolgen, diese wäre dann auch als Verwahrer anzugeben. Zulässig?
==substanceAdministration/author und /performer bei Update Immunisierungsstatus==
Im Kontext des e-Impfass Update I. ist betreffend der für die Impfung verantwortlichen

Person (substanceAdministration/author [1..1] M, [https://art-decor.org/art-decor/decor-templates--elgaimpf-?section=templates&id=1.2.40.0.34.6.0.11.3.1&effectiveDate=2019-01-16T16:12:57&language=de-DE Immunization Entry] ) und der konditionalen

"impfenden" Person (substanceAdministration/performer [0..1] C, [https://art-decor.org/art-decor/decor-templates--elgaimpf-?section=templates&id=1.2.40.0.34.6.0.11.9.21&effectiveDate=2019-05-08T13:21:12&language=de-DE Performer Body - Impfende Person])

aufgefallen, dass sich die Constraints auf die "Berufs-Rolle" in author und performer unterscheiden.

Während beim Impfungen ohne Nachtragung für /author/assignedAuthor/code [0..1], O definiert ist, wird bei

performer/assignedEntity/code mit [1..1], M festgelegt.

Es sollte festgestellt werden, welche dieser beiden Entitäten maßgeblich ist. Die maßgebliche

Entität sollte den strengeren Constraint tragen.

 

=Erratum=
==[https://jira-neu.elga.gv.at/browse/ELGA-1024 ELGA-1024] Präzision der Datumsangabe bei Impfungen==
[[ILF:E-Impfpass#Immunization_Entry|11.4.4.7 Immunization Entry]], substanceAdministration/effectiveTime:

Impfungen können mit unterschiedlich genauen Datumsangaben gespeichert werden.

*Eine aktuell erfasste Impfung muss entweder als Impfdatum taggenau oder als Impfzeitpunkt sekundengenau erfasst werden. (YYYYMMDD oder YYYMMDDhhmmss)
*'''Nur beim Nachtragen''' von Impfungen (z.B. aus dem Papierimpfpass) sind auch ungenauere Angaben Jahr-Monat oder Jahr erlaubt (YYYYMM oder YYYY). Die bisherige Angabe erlaubt die Fehlinterpretation, dass ungenaue Datumsangaben auch für aktuelle Impfungen zulässig wären.

==[https://jira-neu.elga.gv.at/browse/ELGA-1089 ELGA-1089] Beschreibung von referenceRange korrigiert==
[[ILF:E-Impfpass#Antik.C3.B6rper-Bestimmung_Laboratory_Observation_Entry|11.4.4.17 Antikörper-Bestimmung Laboratory Observation Entry]], observation/referenceRange:

Die Beispiele in der Beschreibung dieses Elements waren an dieser Stelle falsch und wurden entfernt.

==[https://jira-neu.elga.gv.at/browse/ELGA-1082 ELGA-1082] Änderung der Bezeichnung von "Impfindikation"==
[[ILF:E-Impfpass#Dataset|10.1 Dataset]]:

Aufgrund der Verwechslungsgefahr der Impfindikation bei Abrechnung mit Indikationsgruppen wurde die Bezeichnung von "Impfindikation" zu "Impfgrund für Abrechnung" geändert.

==[https://jira-neu.elga.gv.at/browse/ELGA-1076 ELGA-1076] Beispiel-Snippet ergänzt==
[[ILF:E-Impfpass#Immunization_Entry_Impfung_nicht_angegeben|11.4.4.8 Immunization Entry Impfung nicht angegeben]]:

Im Beispiel-Snippet fehlte das verpflichtende Attribut substanceAdministration/code /@displayName und wurde ergänzt.

==[https://jira-neu.elga.gv.at/browse/ELGA-827 ELGA-827] Unterstützung der Angabe von Dosismengen bei Impfempfehlungen==
[[ILF:E-Impfpass#Immunization_Recommendation_Entry|11.4.4.9 Immunization Recommendation Entry]], substanceAdministration/doseQuantity:

Bei Impfempfehlungen KANN optional eine Dosismenge (z.B. 2 Ampullen) angegeben werden.

==[https://jira-neu.elga.gv.at/browse/ELGA-1101 ELGA-1101] Unterstützung der Angabe von Zusatzklassifikationen für Impfungen==
[[ILF:E-Impfpass#Zusatzklassifikation_.28f.C3.BCr_Impfungen.29|11.4.4.21 Zusatzklassifikation für Impfungen]] als optionales Element in [[ILF:E-Impfpass#Immunization_Entry|11.4.4.7 Immunization Entry]], substanceAdministration/entryRelationship[3]:

Ein optionales Element zur Aufnahme zusätzlicher strukturierter Information pro Impfung wurde ergänzt, zB eine Klassifizierung der Umgebung, in der die Impfung stattgefunden hat, etwa eine Impfstraße, ein Pflegeheim, Krankenhaus o.Ä. ("Impfsetting")

Die Art der Information wird über den Code angegeben, der Wert über den Value. Ein zusätzlicher erklärender Freitext kann im Text-Element angegeben werden.

==[https://jira-neu.elga.gv.at/browse/ELGA-1141 ELGA-1141] Unterstützung der Angabe von Referenzen auf ein Impf-/Test- bzw. Genesungszertifikat==
[[ILF:E-Impfpass#Immunization_Entry|11.4.4.7 Immunization Entry]], substanceAdministration/reference[2]

[[ILF:E-Impfpass#Impfrelevante_Erkrankungen_Problem_Concern_Entry|11.4.4.13 Impfrelevante Erkrankungen Problem Concern Entry]], substanceAdministration/reference[2]

[[ILF:E-ImpfpassAntik.C3.B6rper-Bestimmung_Data_Processing_Entry|11.4.4.15 Antikörper-Bestimmung Data Processing Entry]], substanceAdministration/reference[2]

Das optionale Elemente substanceAdministration/reference[2] wurde ergänzt. Die Klassifikation des Zertifikats erfolgt mittels substanceAdministration/reference/externalDocument/code und substanceAdministration/reference/externalDocument/code/translation/code.

Die URL zum jeweiligen Zertifikat wird in substanceAdministration/reference/externalDocument/text/reference/@value geführt.

ILF Diskussion:E-Impfpass

2021-05-18T06:29:56Z

Kuttin: /* Erratum */

ILF Diskussion:E-Impfpass

2021-05-18T06:17:24Z

Kuttin:

ILF:E-Impfpass

2021-05-12T07:07:14Z

Kuttin: /* Dataset */

{{#seo:
|title=e-Impfpass
|titlemode=append
|keywords= e-Impfpass
|description=Der e-Impfpass definiert einen technischen und semantischen Standard für den elektronischen und strukturierten Austausch von Impfungen und Daten zur Immunisierungsstatus einer Person.
}}
{{#customtitle:e-Impfpass}}



{{#css:
@media Screen{
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.toc{
width: 20%;
float: right !important;
margin: 10px 0px 10px 30px !important;
border: 1px solid #AAA;
background-color: #F9F9F9;
display: table;
padding: 7px !important;
}
}
}}



{{Infobox Dokument
|Group = CDA Implementierungsleitfaden
|Title = HL7 Implementation Guide for CDA® R2: e-Impfpass
|Subtitle = Zur Anwendung im österreichischen Gesundheitswesen [1.2.40.0.34.7.19.2]
|Short = e-Impfpass
|Namespace = ILF
|Type = Implementierungsleitfaden
|Version = 1.1.0+20210521
|Submitted = ELGA GmbH
|Date = 2021-05-12
|Copyright = © HL7 Austria 2018-2021
|Status = Final
|Verfahren = Normativ
|Period = Nach Begutachtung der Gesetzesnovelle
|OID = 1.2.40.0.34.7.19.2
|Realm = Österreich
}}



=Zusammenfassung=
{{BeginYellowBox}}
Dieser Leitfaden beschreibt die Datenaustauschformate für den [https://www.elga.gv.at/e-impfpass/e-impfpass/index.html e-Impfpass] in Österreich.

Die Grundlage der Datenaustauschformate ist der internationale [[CDA-Grundlagen|CDA-Standard]], der sich in ELGA bereits bewährt hat. Er erlaubt es Sender und Empfänger, sich ohne vorherige Absprache zu verstehen. Als Basisspezifikation wurde das "Immunization Content (IC)" Inhaltsprofil aus dem IHE Technical Framework "Patient Care Coordination (PCC)" ausgewählt, das auch im Schweizerischen [http://e-health-wiki.ch/index.php/CDA-CH-VACD_(project) eImpfdossier] <ref name=ImpfdossierCH>Elektronisches Impf- und Immunschutzdossier der Schweiz [Online 2019]. http://e-health-wiki.ch/index.php/Ehscda:CDA-CH-VACD_(specification)</ref> verwendet wird.

Als Datenaustauschformate dienen zwei unterschiedliche CDA-Dokument-Templates:

* '''[[ILF:E-Impfpass#.C3.9Cbersicht_CDA_Struktur_.22Kompletter_Immunisierungsstatus.22|Kompletter Immunisierungsstatus]]''': Das von der zentralen Anwendung abrufbare Datenaustauschformat. Es enthält alle verfügbaren Informationen zum Immunisierungsstatus einer Person (Impfungen, impfrelevante Erkrankungen, Antikörper-Bestimmungen) und Impfempfehlungen.
* '''[[ILF:E-Impfpass#.C3.9Cbersicht_CDA_Struktur_.22Update_Immunisierungsstatus.22|Update Immunisierungsstatus]]''': Das Datenaustauschformat, das an die zentrale Anwendung gesendet wird, um Änderungen am Immunisierungsstatus einer Person zu dokumentieren (Impfungen, impfrelevante Erkrankungen, Antikörper-Bestimmungen) sowie individuell angepasste Impfempfehlungen, die durch den impfenden Arzt festgelegt werden.

Die Notation der Spezifikation der Datenaustauschformate folgt der "Art-Decor"-Schreibweise, die auf einer eigenen Seite ([[Hilfe:Art-Decor-Tabellen_verstehen|Art-Decor-Tabellen verstehen]]) erläutert wird.

Der vorgesehene Ablauf des Datenaustausches wird im Kapitel [[ILF:E-Impfpass#Anwendungsf.C3.A4lle|Anwendungsfälle]] beschrieben.
{{EndYellowBox}}

{{BeginYellowBox}}
Der e-Impfpass ist ein Pilotprojekt - verschiedene Rahmenbedingungen und die gesetzliche Grundlage befinden sich noch in Ausarbeitung, der Leitfaden kann daher nur auf den aktuellen Stand des Wissens aufbauen. Eine Aktualisierung des Leitfadens im Rahmen der Pilotierung kann nicht ausgeschlossen werden. Dieser Leitfaden ist ein nationaler HL7©-Standard, der technisch und inhaltlich im Rahmen des Abstimmungsverfahrens 2019-1 ("Ballot") normiert wurde.
Kommentare zu diesem Leitfaden können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden.
{{EndYellowBox}}
<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">


==Impressum==
<div class="mw-collapsible-content">
''Medieneigentümer, Herausgeber, Hersteller, Verleger:'' 
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: 01. 2127050. 
Internet: [http://www.elga.gv.at www.elga.gv.at]
Email: [mailto:cda@elga.gv.at cda@elga.gv.at]. 
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch

''Redaktion, Projektleitung, Koordination: '' 
Mag. Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]

''Abbildungen:'' © ELGA GmbH

''Nutzung'': Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria, Franckstrasse 41/5/14, 8010 Graz; [http://www.hl7.at www.hl7.at]. 
Die Nutzung ist zum Zweck der Erstellung medizinischer Dokumente ohne Lizenz- und Nutzungsgebühren ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter [https://www.gesundheit.gv.at www.gesundheit.gv.at] und [https://www.elga.gv.at/cda www.elga.gv.at/cda]
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">
== Haftungsausschluss ==
<div class="mw-collapsible-content">
Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht. Die ELGA GmbH weist ausdrücklich darauf hin, dass es sich bei dem vorliegenden Leitfaden um unverbindliche Arbeitsergebnisse handelt, die zur Anwendung empfohlen werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls unerwünscht und von den Erstellern des Dokumentes nicht beabsichtigt.

Die Nutzung des vorliegenden Leitfadens erfolgt in ausschließlicher Verantwortung der Anwender. Aus der Verwendung des vorliegenden Leitfadens können keinerlei Rechtsansprüche gegen die ELGA GmbH erhoben und/oder abgeleitet werden.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">
== Sprachliche Gleichbehandlung ==
<div class="mw-collapsible-content">
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer und Frauen in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
</div></div>

{{ILF:Lizenzinformationen}}

<div class="toccolours mw-collapsible mw-collapsed" style="width:50%; overflow:auto;">
==PDF-Bedienungshinweise==
<div class="mw-collapsible-content">
Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

* Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
* Seitenweise blättern: "Bild" Tasten
* Scrollen: Pfeil nach oben bzw. unten
* Zoomen: Strg + Mouserad drehen
* Suchen im Dokument: Strg + F
</div></div>





=Einleitung=
==Ausgangslage und Motivation==
Im österreichischen Impfwesen wird der papierbasierte Impfpass als zentrales Instrument für die Dokumentation und den Nachweis von Impfungen verwendet. Obwohl sich der papierbasierte Impfpass über viele Jahre bewährt hat, so erfüllt er nicht mehr die Anforderungen an ein modernes Gesundheitsvorsorgeinstrument. Der Papierimpfass geht oft verloren, die teilweise handschriftlichen Aufzeichnungen sind schwierig zu entziffern und nicht vollständig bzw. über mehrere Impfpässe verteilt. Hier soll der e-Impfpass ansetzen und valide und übersichtliche Daten schaffen. Zudem sollen auf Basis des nationalen Impfplans persönliche Impfempfehlungen ausgegeben werden.
Auf Beschluss der Bundeszielsteuerungskommission wurde daher die Umsetzung der Pilotierung des elektronischen Impfpasses (e-Impfpass) durch die ELGA GmbH beschlossen.
Mit dem Ziel einer optimierten Impfversorgung der österreichischen Bevölkerung ist der Impfausweis der Zukunft ein elektronisches Dokument (e-Impfpass). Um den Austausch dieser Informationen zwischen allen beteiligten Institutionen und Personen zu unterstützen, muss ein einheitliches Austauschformat geschaffen und definiert werden, welches in diesem Dokument beschrieben wird.

==Zweck des Dokuments==
Das vorliegende Dokument beschreibt die einheitlichen Austauschformate und Inhalte für den Informationsaustausch für den "e-Impfpass" für das Österreichische Gesundheitswesen. Diese Spezifikation ist das Resultat einer Harmonisierungsarbeit mit dem Ziel, Impfeinträge innerhalb der österreichischen "Elektronischen Gesundheitsakte" (ELGA) als abgestimmte und einheitlich strukturierte Dokumente darzustellen. Der vorliegende Implementierungsleitfaden beinhaltet daher Spezifikationen für die semantische Interoperabilität von Systemen rund um den e-Impfpass inkl. der elektronische Anfragen von Impfempfehlungen.
Die Grundlage der Datenaustauschformate ist der internationale CDA-Standard, der sich in ELGA bereits bewährt hat. Als Basisspezifikation wurde das "Immunization Content (IC)" Inhaltsprofil aus dem IHE Technical Framework "Patient Care Coordination (PCC)" ausgewählt, das auch im Schweizerischen eImpfdossier verwendet wird. Das vorliegende Dokument wurde von einer Arbeitsgruppe von Vertretern des Gesundheitswesens, der Wissenschaft und der Wirtschaft sowie von der Health Level 7 (HL7) Anwendergruppe Österreich erstellt. Der Leitfaden basiert auf den vorangegangenen Erfahrungen in der Erstellung von Implementierungsleitfäden für ELGA CDA Dokumente. Die Header enthalten zum einen administrative Daten (allgemeine Angaben zum Dokument, Daten zum Patienten, usw.) und dienen zum anderen auch als Quelle für die Metadaten, die bei der Registrierung des Dokuments in ELGA verwendet werden. Der Header orientiert sich am bestehenden "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente", enthält aber Verallgemeinerungen, da es sich um ein e-Health-Dokument und nicht um ein ELGA-Dokument handelt. Die medizinisch relevanten Anteile zur Erfassung des Immunisierungsstatus sind im so genannten "Body" enthalten.

==Zielgruppe==
Anwender dieses Dokuments sind Softwareentwickler und Berater, die allgemein mit Implementierungen und Integrationen im e-Health-Umfeld, insbesondere des Projekts e-Impfpass, aber auch mit ELGA e-Befunden oder e-Medikation betraut sind. Weiters richtet sich
der Leitfaden an alle an der Erstellung von Gesundheitsdaten und Gesundheitsdokumenten beteiligten Personen, einschließlich der Endbenutzer der medizinischen Softwaresysteme und der Angehörigen von Gesundheitsberufen.

=Informationen über dieses Dokument=
==Verbindlichkeit==
Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten für den Elektronischen Impfpass gem. Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 (GTelG 2012) sowie den darauf fußenden Novellen und Verordnungen. Die im Implementierungsleitfaden getroffenen Festlegungen für Inhalt, Struktur, Format und Codierung sind somit verbindlich.

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

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

== Verwendete Grundlagen und Bezug zu anderen Standards ==

{|
|style="vertical-align:top" |
Grundlage dieses Implementierungsleitfadens ist der internationale Standard "HL7 Clinical Document Architecture, Release 2.0" (CDA ©), für die das Copyright © von Health Level Seven International gilt. 
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. Das Datenmodell von CDA und seine Abbildung in XML folgen dem Basisstandard HL7 Version 3 mit seinem Referenzinformationsmodell (RIM). 
 
Für die Modellierung der Inhalte des Impfpasses wurde das "Immunization Content (IC)" Inhaltsprofil aus dem IHE Technical Framework "Patient Care Coordination (PCC)" ausgewählt, das auch im Elektronischen Impf- und Immunschutzdossier der Schweiz [[http://e-health-wiki.ch/index.php/Ehscda:CDA-CH-VACD_(specification)]] verwendet wird und das als wesentliche Grundlage für diesen Leitfaden dient.
| [[Datei:Grafik VerwendeteStandards.png| 300px|Verwendete Standards]]
<ref group="Abbildung">Verwendete Standards</ref>

|}

*[https://www.ihe.net/resources/technical_frameworks/#pcc IHE Integrationsprofile Patient Care Coordination] <ref name=IHEPCC>IHE Patient Care Coordination (PCC) [Online Juli 2019]: https://www.ihe.net/resources/technical_frameworks/#pcc</ref>
*[http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 Clinical Document Architecture (CDA)] <ref name=HL7CDA>HL7 Clinical Document Architecture (CDA) [Online Juli 2019]: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7</ref>
*[http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186 Version 3 Product Suite (inkl. RIM)] <ref name=CDAV3RIM>Version 3 Product Suite (inkl. RIM) [Online Juli 2019]: RIM http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186</ref>
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria), die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden (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.

== Wichtige unterstützende Materialien ==
{{BeginYellowBox}}
Auf der Website [[ILF:E-Impfpass_Guide |e-Impfpass Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
* Beispieldokumente für den "Kompletten Immunisierungsstatus" und für "Update Immunisierungsstatus"
* Schematron-Prüfregeln
* Design-Beispiel
Die im Weiteren angeführten Templatespezifikationen wurden im '''Art-Decor Projektrepository''' [https://art-decor.org/art-decor/decor-templates--elgaimpf-?section=templates e-Impfpass] erstellt und können dort eingesehen werden. Eine Anleitung zum Verständnis der Art-Decor-Notation finden Sie im Artikel [[Hilfe:Art-Decor-Tabellen verstehen|Art-Decor-Tabellen verstehen]].
{{EndYellowBox}}
Weitere Informationen zu CDA-Leitfäden werden auf der Website der ELGA GmbH zur Unterstützung bereitgestellt:
* Beispieldokumente
* Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
* CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
* Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
* Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
* Hinweise für die zu verwendenden Terminologien
* Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}
Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA].
{{EndYellowBox}}



=Harmonisierung=
Dieser Implementierungsleitfaden entstand durch die Harmonisierungsarbeit der Arbeitsgruppe e-Impfpass, die im Zeitraum von September 2018 bis Februar 2019 tagte. Die Teilnehmer der Arbeitsgruppe wurden durch ihre Organisation delegiert.

Die Arbeitsgruppe harmonisierte primär die inhaltlichen Vorgaben und soweit möglich die zu verwendenden Terminologien (Value Sets).
Die Formulierung der technischen Spezifikation des CDA Implementierungsleitfadens e-Impfpass erfolgte durch die ELGA GmbH parallel bzw. nach der inhaltlichen Festlegung.

Der Leitfaden wird in einem technischen Abstimmungsverfahren durch die HL7 Austria ("Ballot") zu einem österreichischen Standard. Die Verbindlichkeit zur Anwendung soll durch eine Novellierung des Gesundheitstelematikgesetzes 2012, BGBl.I Nr.111/2012 begründet werden.

== Autoren und Mitwirkende ==
Der vorliegende Leitfaden wurde unter der Leitung der ELGA GmbH von den Autoren und unter Mitwirkung der genannten Personen (Mitglieder der Arbeitsgruppe) erstellt. Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht.
Die HL7 Austria und die ELGA GmbH genehmigen ausdrücklich die Anwendung des Leitfadens ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente und weisen darauf hin, dass dies mit dem Einverständnis aller Mitwirkenden erfolgt.

===Autoren===
'''Das Redaktionsteam''' bestand aus folgenden Personen:
{| class="wikitable"
! Name
! Organisation
! Rolle
|-
| Mag. Dr. Stefan Sabutsch
| ELGA GmbH, HL7 Austria
| Autor, Herausgeber
|-
| DI Andrea Klostermann
| ELGA GmbH
| Autor
|-
| DI Oliver Kuttin
| ELGA GmbH
| Autor

|}

Mit Beiträgen von:
Tony Schaller (medshare GmbH),
Stephan Rainer-Sablatnig (ELGA GmbH),
Nina Sjencic, B.A. (ELGA GmbH),
Helene Prenner (ELGA GmbH)

===Mitwirkende===
'''Teilnehmer der Arbeitsgruppe e-Impfpass''' (in alphabetischer Reihenfolge):
Anton Angerer (at.Software / WAVM),
Patrick Awart (Atos),
Elisabeth Bischof (Landessanitätsdirektion OÖ),
DI (FH) Reindert Buter (Buter GmbH),
Sabine Eder (Landessanitätsdirektion NÖ),
Mag. Alexander Ertl (BASG / AGES),
Dr. Katja Fischer (BMASGK),
Günter Franz (Landessanitätsdirektion Salzburg),
W HR Dr. Ernst Gschiel (Landessanitätsdirektion Burgenland),
Dr. Eva Heinzl (Landessanitätsdirektion OÖ),
Ingrid Huber (Landessanitätsdirektion NÖ),
OPhysR Dr.in Ursula Karnthaler (Landessanitätsdirektion Wien),
Herbert Karpf, BA (Landessanitätsdirektion Kärnten),
HR Dr. med. univ. Franz Katzgraber (Landessanitätsdirektion Tirol),
DI Andrea Klostermann (ELGA GmbH),
DI Oliver Kuttin (ELGA GmbH),
Dr. Irmgard Lechner (Landessanitätsdirektion NÖ),
Ruprecht Leitner (Apothekerverlag),
Dr. Anita Luckner-Hornischer (Landessanitätsdirektion Tirol),
Dr. Lukas Murajda, PhD, MSc (Landessanitätsdirektion Salzburg),
DI Michael Nöhammer (ÖÄK),
Christopher Ozvald (BMASGK),
Dr. Georg Palmisano (Landessanitätsdirektion OÖ),
Dr. Maria Paulke-Korinek (BMASGK),
Mag. Daniela Philadelphy (BASG / AGES),
Daniela Piererfellner (Landessanitätsdirektion OÖ),
Maria Pramhas (Land Salzburg - Impfadatenbank),
Dr. Daniel Prenninger (Landessanitätsdirektion Burgenland),
Mag. Margit Pufitsch-Weber (Wissenschaftliche Akademie für Vorsorgemedizin),
Stephan Rainer-Sablatnig (ELGA GmbH),
Dr. Stefan Sabutsch (ELGA GmbH),
Robert Scharinger (BMASGK),
Dr.Rudolf Schmitzberger (Impfreferat Österr Ärztekammer),
DI Mag. Birgit Scholz (ELGA GmbH),
Dr. Christoph Schweighofer (ÖÄK),
Carina Seerainer, MSc (ELGA GmbH),
Nina Sjencic (ELGA GmbH),
Landessanitätsdirektorin OSRin Dr.in Karin SPACEK (Landessanitätsdirektion Wien (Magistratsabteilung 15 - Gesundheitsdienst der Stadt Wien)),
Mag. Stefan Spitzbart (Hauptverband),
Stephanie Stürzenbecher, BA MA (Hauptverband),
Dr. Barbara Tucek, MD, MSc (BASG / AGES),
Mag. Ilana Ventura, MSc (BMASGK),
Dr.med. Heimo Wallenko, MAS (Landessanitätsdirektion Kärnten),
Gabriele Wasner (Landessanitätsdirektion OÖ)

{{ILF:Begriffsdefinitionen e-Impfpass}}

=Technischer Hintergrund=

{{ILF:eImpfpass_Allgemeine_Richtlinien | Allgemeine Richtlinien für die Implementierung des e-Impfpasses}}


{{ILF:eImpfpass_Datentypen | e-Impfpass Datentypen}}

==Weitere Informationen zu CDA==
Weitere Informationen zum technischen Hintergrund finden sich unter folgenden Links:

* [[elga-cdaalf-2.06.2:Konzept_und_Modellbeschreibung| Allgemeine Informationen zu CDA]] <ref name=CDAAllgemein>Allgemeine Informationen zu CDA [Online Juli 2019]: https://wiki.hl7.at/index.php?title=elga-cdaalf-2.06.2:Konzept_und_Modellbeschreibung</ref>
* [[CDA_Templates|CDA Templates]] <ref name=CDATemplates>CDA Templates [Online Juli 2019]: https://wiki.hl7.at/index.php?title=CDA_Templates</ref>
* [[ILF:Art-Decor-Tabellen_verstehen|Art-Decor-Tabellen verstehen]] <ref name=ArtDecorVerstehen>Art-Decor-Tabellen verstehen [Online Juli 2019]: https://wiki.hl7.at/index.php?title=Hilfe:Art-Decor-Tabellen_verstehen</ref>
* [[elga-cdaalf-2.06.2:Technische Konformitätsprüfung|Technische Konformitätsprüfung]] <ref name=TechnKonform>Technische Konformitätsprüfung [Online Juli 2019]: https://wiki.hl7.at/index.php?title=elga-cdaalf-2.06.2:Technische_Konformit%C3%A4tspr%C3%Bcfung</ref>
* [[Terminologien|Terminologien]] <ref name=Terminologien>Terminologien [Online Juli 2019]: https://wiki.hl7.at/index.php?title=Terminologien</ref>



= Funktionale Anforderungen=

== Darstellung==
Für die Darstellung des e-Impfpasses wird ein spezielles Stylesheet bereitgestellt, das im XML-Prolog referenziert wird ("ELGA_eimpf-stylesheet_v1.0.xsl").
Grundsätzlich werden die Daten aus den Entries dargestellt. Section.Text MUSS dennoch angegeben werden, da der CDA Rel. 2 Standard "Lesbarkeit für Menschen" ("human readability") vorschreibt.

<div class="landscape">

==Verwendung in der ELGA Infrastruktur==
===Vorgaben zu Dokument-Metadaten (XDS-Metadaten)===
{| class="wikitable"
! XDS-Mapping
! Optio-
nalität
! CDA-Element
clinicalDocument.
! Beispiel
! Erklärung
|-
| formatCode
| R
| .templateId/@extension
|
*<nowiki>@extension="XDSdocumentEntry.formatCode
^urn:hl7-at:eImpf:2019"</nowiki>
*@isplayName= "HL7 Austria e-Impfpass 2019"
| Version des Implementierungsleitfaden e-Impfpass - "Update Immunisierungsstatus" bzw. "Kompletter Immunisierungsstatus" mit XDSdocumentEntry.formatCode als Extension.
Das templateId-Element mit einer Extension beginnend mit "XDSdocumentEntry.formatCode^" wird ins XDS-Attribut formatCode gemappt (ohne Präfix XDSdocumentEntry.formatCode^).
|-
| classCode
| R
| .code
|
*@code="11369-6"
*@displayName="HISTORY OF IMMUNIZATIONS"
*@codeSystem="2.16.840.1.113883.6.1"
| Bezeichnet die "Dokumentklasse". Zulässige Werte gemäß Value-Set "ELGA_Dokumentklassen".
Aus Gründen der Kompatibilität zu IHE PCC und auch den Ableitungen im Schweizer CH-VACD haben alle Impfungsdokumente den Code '''11369-6 History of Immunization Narrative'''.
|-
| rowspan="2"| typeCode
| rowspan="2"| R
| rowspan="2"| .code.translation
|
*@code="82593-5"
*@displayName="Immunization summary report"
*@codeSystem="2.16.840.1.113883.6.1"
| Zur Unterscheidung des Dokumenttyps erhält das Element clinicalDocument.code des '''"Kompletter Immunisierungsstatus"''' ein zusätzliches translation-Element.
|-
|
*@code="87273-9"
*@displayName="Immunization note"
*@codeSystem="2.16.840.1.113883.6.1"
| Zur Unterscheidung des Dokumenttyps erhält das Element clinicalDocument.code des '''"Update Immunisierungsstatus"''' ein zusätzliches translation-Element.
|-
| rowspan="2"| title
| rowspan="2"| R
| rowspan="2"| .title
| "Kompletter Immunisierungsstatus"
| Für den lesenden Dokumentempfänger gedachter Titel des '''Kompletten Immunisierungsstatus'''.
|-
| "Update Immunisierungsstatus"
| Für den lesenden Dokumentempfänger gedachter Titel des '''Update Immunisierungsstatus'''.
|-
| eventCodeList
| R
| .documentationOf
.serviceEvent.code
|
*@code="41000179103"
*@displayName="Immunization record (record artifact)"
*@codeSystem="2.16.840.1.113883.6.96"
*@codeSystemName="SNOMED CT"
| Code der Gesundheitsdienstleistung.
|-
| rowspan="2"| serviceStartTime
| rowspan="2"| R
| rowspan="2"|.documentationOf.serviceEvent
.effectiveTime.low
|
Zeitpunkt des '''ältesten''' effectiveTime aus:
*"Immunization Entry":
**templateId 1.2.40.0.34.6.0.11.3.1
**substanceAdministration.effectiveTime und
*"Impfrelevante Erkrankungen Problem Entry":
**templateId 1.2.40.0.34.6.0.11.3.9
**act.effectiveTime.low
| Beginn der Gesundheitsdienstleistung beim '''Kompletter Immunisierungsstatus'''.
|-
| Zeitpunkt des Behandlungsbeginns (aktueller Besuch).
| Beginn der Gesundheitsdienstleistung bei '''Update Immunisierungsstatus'''.
|-
| rowspan="2"| serviceStopTime
| rowspan="2"| R
| rowspan="2"| .documentationOf.serviceEvent
.effectiveTime.high
|
Zeitpunkt des '''jüngsten''' effectiveTime aus:
*"Immunization Entry":
**templateId 1.2.40.0.34.6.0.11.3.1
**substanceAdministration.effectiveTime und
*"Impfrelevante Erkrankungen Problem Entry":
**templateId 1.2.40.0.34.6.0.11.3.9
**act.effectiveTime.high
| Ende der Gesundheitsdienstleistung bei '''Kompletter Immunisierungsstatus'''.
|-
| Zeitpunkt des Behandlungsendes (aktuelle Behandlung,
muss sich von Behandlungsbeginn unterscheiden)
| Ende der Gesundheitsdienstleistung bei '''Update Immunisierungsstatus'''.
|}
</div>

==Versionierung & Stornierung==
Versionierung und Stornierung betrifft ausschließlich Dokumente vom Typ "Update Immunisierungsstatus".

Das von der e-Impfpass Anwendung erzeugte On-Demand Dokument "Kompletter Immunisierungsstatus" ist immer eine neue Version desselben Dokuments, d.h. es ändert sich nur die Versionsnummer (die SetID bleibt für alle Versionen des kompletten Immunisierungsstatus eines Patienten gleich).

===Versionierung von Dokumenten===
Dokumente vom Typ "Update Immunisierungsstatus" können über die IHE Transaktion ITI-41 versioniert werden.
Die Inhalte werden von der zentralen e-Impfpass-Anwendung verarbeitet und alle Inhalte in den Datenbestand integriert. Das bedeutet, dass alle Daten, die bereits durch ein Dokument in den zentralen Datenbestand übernommen wurden, durch das Update ersetzt werden. Daten, die in der neu registrierten Version nicht enthalten sind, gelten als gelöscht.
Die Fachlogik der zentralen e-Impfpass-Anwendung kann die Änderung oder Löschung verweigern, sollten dadurch inkonsistente Datenbestände entstehen (z.B. wenn Informationen gelöscht werden sollen, auf denen spätere Impfeinträge beruhen).

===Stornierung von Dokumenten===
Dokumente vom Typ "Update Immunisierungsstatus" können über IHE Transaktion ITI-57 storniert werden. Alle Inhalte, die ursprünglich durch das stornierte Dokument eingetragen wurden, werden gelöscht.
Die Fachlogik der zentralen e-Impfpass-Anwendung kann die Stornierung verweigern, sollten dadurch inkonsistente Datenbestände entstehen (z.B. wenn Informationen gelöscht werden sollen, auf denen spätere Impfeinträge beruhen).

==Impfempfehlungen==
Ein Ziel des e-Impfpasses ist, interessierten Ärztinnen und Ärzten sowie impfwilligen Bürgerinnen und Bürgern einen einfachen Überblick über aktuelle zur Verfügung stehende Impfungen zu geben. Dazu werden vom e-Impfpass "Impfempfehlungen" ausgegeben. Eine Impfempfehlung enthält zu einer Impfung den jeweils nächsten fälligen Impftermin und dazu eine Handlungsanweisung. Impfempfehlungen werden für alle Impfungen erstellt, die bereits mindestens einmal erhalten wurden oder die für die Person laut Österreichischen Impfplan empfohlen sind.

Die Impfempfehlungen werden vom Expertensystem der zentralen Anwendung aktuell erstellt und gemeinsam mit dem On-Demand-Dokument "Kompletter Immunisierungsstatus" ausgegeben. Das Expertensystem ist ein Teil der Fachlogik der zentralen Anwendung und bildet den jeweils aktuellen Österreichischen Impfplan ab, der vom Nationalen Impfgremium herausgegeben wird. Der Impfplan wird in ein tabellarisches Regelwerk übersetzt und ins Expertensystem importiert. Zur Berechnung der Impfempfehlung werden folgende Parameter aus der persönlichen Impfdokumentation herangezogen:
* Alter der Person
* Geschlecht
* Bereits erhaltene Impfungen:
** Dosiskennung der letzten eingetragenen Impfung
** Impfstoff
** Impfschema (sofern abweichend vom Defaultschema)
* Durchgemachte impfrelevante Erkrankungen
* Indikation für Impfung ("Risikogruppe")

'''Dosiskennung''': Damit die nächste Impfung im Rahmen eines bestimmten Impfschemas korrekt berechnet werden kann, ist es nicht notwendig, dass alle bisher verabreichten Dosen einer Impfung dokumentiert werden. Es reicht, die jeweils letzte Dosis zu dokumentieren, dafür muss die Dosiskennung korrekt angegeben werden (z.B. "3. Grundimmunisierung").

'''Impftiter''': Ergebnisse von Antikörperbestimmungen werden NICHT von der Berechnungslogik berücksichtigt. Wenn der Impftiter ein Abweichen vom automatisch berechneten Impftermin notwendig macht, muss vom Arzt eine individuelle Impfempfehlung erstellt werden, als Kommentar soll der Impftiter angegeben werden.

== Mehrsprachigkeit und grenzüberschreitender Austausch ==
Mehrsprachigkeit wird in dieser Version nicht unterstützt, ist aber für die Zukunft angedacht. Die entsprechenden Strukturen im Leitfaden sind bereits angelegt.


=User Storys ("Anwendungsfälle")=
Die Einsatzszenarien für dieses Datenaustauschformat werden in Form von User Storys ("Anwendungsfälle") knapp beschrieben, um dem Leser den Hintergrund zu vermitteln. Diese Beschreibung der Anwendungsfälle ist nicht normativ und keine Vorentscheidung für die tatsächliche Umsetzung. Eine detaillierte technische Beschreibung der Anwendungsfälle und die Geschäftsprozesse findet sich im Architekturdokument e-Impfpass <ref name=ELGAeImpfpass>ELGA GmbH [Online Oktober 2019]: https://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/index.html</ref>.

Die derzeit bei den unterschiedlichen Akteuren des österreichischen Gesundheitswesens auftretenden Anwendungsfälle betreffend Impfungen werden im Folgenden skizziert.

==Übersicht vorhandener Akteure und Komponenten==
Folgende Abbildung zeigt einen Überblick über die Akteure und Komponenten der zentralen e-Impfpass Anwendung (Wissensstand vor der Pilotierung und vor dem Vorliegen der gesetzlichen Grundlage).

[[Datei:Übersicht e-Impfpass- Akteure Komponenten.png|1000px|Uebersicht e-Impfpass: Akteure und Komponenten]]

<ref group="Abbildung>Übersicht e-Impfpass: Akteure und Komponenten</ref>

# e-Impfpass-Teilnehmer / Bürger 
# Impfende GDA
#* Niedergelassene Ärzte
#** Fachärztinnen und Fachärzte für Kinder und Jugendheilkunde
#** Ärztinnen und Ärzte für Allgemeinmedizin
#* Landessanitätsdirektionen inkl. Amtsärzte (Amtsärzte, Schulärzte, Betriebsärzte)/öffentliche Gesundheitsdienste
# Interessensvertretung von Bürger- und Bürgerinnen-Rechten
#* Bürgerinnen und Bürger, die im Z-PI erfasst sind, und dessen Vertreter, insbesondere Eltern-für-Kinder
#* ELGA-Ombudsstelle
# ELGA-Serviceline 
# Datenkorrigierender GDA
#* Bezirksverwaltungsbehörde
# "Abrechnungsunterstützung" (im Rahmen des kostenlosen Kinderimpfprogramms)
#* Landeshauptmann / Landeshauptfrau
#* Bezirksverwaltungsbehörde
# Auswertungen für Durchimpfungsraten
#* Landeshauptmann / Landeshauptfrau
#* Zuständiges Bundesministerium für Gesundheit

Bei der Betrachtung der technischen Architektur haben folgende Ausgangspunkte einen besonderen Stellenwert und werden deshalb kurz zusammengefasst:
# Die e-Impfpass Anwendung ist eine eHealth-Anwendung mit zentraler Datenhaltung.
# Die e-Impfpass Anwendung nutzt betreffend Autorisierung, Protokollierung und Zugangskontrolle die bestehende ELGA Infrastruktur.
# Berechtigte e-Impfpass Anwender (GDA) sind im GDA-I mit entsprechender Rolle gelistet.
# Es muss zwischen folgend aufgelisteten rollenbasierenden Zugangangsarten unterschieden werden.
## Regulärer Zugang mittels Kontaktbestätigungen
## Behördlicher Zugang für tagaktuelles Ausbruchs-Management (und Durchimpfungsrate) welcher gesetzlich geregelt wird (auch ohne Kontaktbestätigung). Hier zählen Zugriffe auf die Impfdaten von eindeutig identifizierten Personen.
# Verabreichte Impfungen müssen lückenlos in der e-Impfpass Anwendung gespeichert werden. Da der Immunisierungsstatus im Ausbruchsfall jederzeit abrufbar sein muss, kommen individuelle Berechtigungen von e-Impfpass-Teilnehmern nicht zur Anwendung (Gesetzesgrundlage ist hier maßgebend).
# Die Geschäftslogik der Anwendung übernimmt die CDA-Verarbeitung und hat folgende Funktionen
## Speichert eingehende CDA Dokumente "Update Immunisierungsstatus", zerlegt diese (entsprechend gültigem Schema) und persistiert die Informationseinheiten.
## Das Zusammenstellen vom OnDemand-Dokument "Kompletter Immunisierungsstatus" (der eigentliche e-Impfpass der Teilnehmer) muss unterstützt werden. Hierfür werden die Inhalte der zentralen Datenbank zusammengestellt und im angeforderten Format (CDA) ausgehändigt.
## Die analytisch-statistische Weiterverarbeitung (Abzüge für BI) bzw. Auswertungen müssen ermöglicht werden.
## Auf Grundlage des gültigen Österreichischen Impfplanes muss bei der Abfrage des persönlichen e-Impfpasses eines Teilnehmers das Datum der nächste(n) fälligen Impfungen und etwaige Nachhol-Impftermine beigefügt werden. Vom GDA manuell eingefügte Impftermine müssen unterstützt werden und diese dürfen von der Fachlogik nicht überschrieben werden.

==Allgemeine Vorbedingungen==
Für den Zugriff auf den elektronischen Impfpass (lesend und schreibend) sind spezielle Rollen und Berechtigungen erforderlich. Diese sowie der Vorgang zur Authentifizierung und Autorisierung sind im Architekturdokument e-Impfpass <ref name=ELGAeImpfpass/>erläutert.
Die notwendigen Stammdaten (z.B. Impfungen, Impfstoffe, impfrelevante Erkrankungen ...) werden über den [https://termpub.gesundheit.gv.at/ Terminologieserver] bereitgestellt.

Sowohl der berechtigte GDA (über das GDA System, sobald E-Card gesteckt wurde), als auch die Bürgerin/der Bürger (über das ELGA Portal) können auf den persönlichen e-Impfpass zugreifen.

==U1 Kompletten Immunisierungsstatus abrufen==
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Max Muster (ELGA Teilnehmer) besucht seinen Hausarzt Dr. DeCarro (Impfender GDA) und möchte Informationen zu seinem Immunisierungsstatus erhalten.
# Dr. DeCarro fragt den e-Impfpass von Max Muster über seine Softwaresystem ab und erhält das On-Demand-Dokument "Kompletter Immunisierungsstatus", das Auskunft über die bisherigen Impfungen und entsprechende Impfempfehlungen enthält.
#Max Muster erfährt von Dr. DeCarro, dass laut Österreichischem Impfplan die nächste FSME-Auffrischungsimpfung in einem Monat ansteht und vereinbart hierfür einen Termin bei Dr. DeCarro.

Auch wenn noch keine Immunisierungseinträge in der e-Impfpass Anwendung gespeichert sind, können Impfempfehlungen abgerufen werden.

==U2 Aktualisierung Immunisierungsstatus==

Wird eine Änderung am dokumentierten Immunisierungsstatus vorgenommen (z.B. neuer Impfeintrag, Nachtragen einer Impfdokumentation oder Korrektur einer bestehenden Impfung, Eintrag einer impfrelevanten Erkrankung), so werden die Änderungen mit dem Datenaustauschformat "Update Immunisierungsstatus" an die zentrale e-Impfpass Anwendung übermittelt. Die zentrale Anwendung übernimmt die Änderungen als Update und berechnet die nächsten empfohlenen Impftermine.

Es kann zwischen folgenden Anwendungsfällen unterschieden werden:

===U2.1 Eintragen des Immunisierungsstatus===
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Max Muster besucht seinen Hausarzt Dr. DeCarro, weil er einen Termin für eine FSME-Auffrischungsimpfung vereinbart hat.
# Dr. DeCarro fragt den e-Impfpass von Max Muster über seine Softwaresystem ab und erhält das Dokument "Kompletter Immunisierungsstatus" (U1), das Auskunft über die bisherigen Impfungen und entsprechende Impfempfehlungen enthält und kontrolliert, ob sich seit dem letzten Abruf Änderungen ergeben haben.
# Dr. DeCarro führt die Impfung durch und dokumentiert diese in seinem Softwaresystem. Nach der Freigabe der Dokumentation erzeugt das Softwaresystem ein Datenaustauschformat "Update Immunisierungsstatus" und sendet dieses an die zentrale Anwendung e-Impfpass, die das Dokument übernimmt und ein Update der Datenbank durchführt.
# Dr. DeCarro kann nun das Dokument "Kompletter Immunisierungsstatus" erneut abrufen und erhält eine neue Version des Dokuments mit aktualisiertem Immunisierungsstatus und neuen Impfempfehlungen für Max Muster.

===U2.2 Korrektur eines Immunisierungseintrags===
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Dr. DeCarro stellt fest, dass der Eintrag, den er für Max Muster erstellt hat, korrigiert werden muss (z.B. wegen eines Dokumentationsfehlers oder weil die individuelle Impfempfehlung vergessen wurde)
# Dr. DeCarro korrigiert den Eintrag in seinem Softwaresystem, das eine neue Version des Dokuments "Update Immunisierungsstatus" an die zentrale Anwendung übergibt.
# Die zentrale Anwendung ersetzt alle Daten, die durch das originale Dokument "Update Immunisierungsstatus" übernommen worden waren durch die Daten, die in der korrigierten Version enthalten sind.

Die Berechtigung für eine Korrektur von bereits eingetragenen Immunisierungseinträgen hat nur jener GDA, der diese Impfdaten eingetragen hat oder eine gesetzlich festgelegte Rolle (siehe U5).

Die Vorversionen des CDA "Update Immunisierungsstatus" wurden als "DEPRECATED" gekennzeichnet. Die neue Version des CDA Dokuments wird mit dem Status "APPROVED" gespeichert.

===U2.3 Stornierung eines Immunisierungseintrags===
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Dr. DeCarro stellt fest, dass der Eintrag, den er erstellt hat, storniert werden muss (z.B., weil er für den falschen Patienten dokumentiert hat)
# Dr. DeCarro löscht den Eintrag in seinem Softwaresystem, das eine Stornierungsnachricht mit dem Verweis auf das zu stornierende "Update Immunisierungsstatus"-Dokument an die zentrale Anwendung übergibt.
# Die zentrale Anwendung löscht alle Daten, die durch die originale Nachricht "Update Immunisierungsstatus" übernommen worden waren.

Die Berechtigung für eine Stornierung von bereits eingetragenen Immunisierungseinträgen hat nur jener GDA, der diese Impfdaten eingetragen hat oder eine gesetzlich festgelegte Rolle (siehe U5).

Stornierte CDA Dokumente wurden als "DEPRECATED" gekennzeichnet.

===U2.4 Nachtragen der Impfdokumentation===
Akteure: e-Impfpass Teilnehmer ("Max Muster"), impfender GDA ("Dr. DeCarro")

Szenario:
# Max Muster besucht seinen Hausarzt Dr. DeCarro und möchte seinen Papier-Impfpass in den e-Impfpass überführen.
# Dr. DeCarro überträgt das Papierdokument in sein Softwaresystem, das ein Datenaustauschformat "Update Immunisierungsstatus" erzeugt und an die zentrale Anwendung übergibt.

==U3 Abrechnung==
''Anmerkung: Die Abrechnung selbst steht nicht im Fokus dieses Leitfadens. Er stellt lediglich sicher, das die für die Abrechnungsunterstützung notwendigen Informationen über das Datenaustauschformat übertragen werden können.''

Akteure: Impfender GDA ("Dr. DeCarro"), Abrechnungsunterstützung, Kind "Max Musterkind"

Szenario:
# Dr. DeCarro dokumentiert die Impfung des Kindes "Max Musterkind" (siehe U2.1)
# Das GDA-Softwaresystem erzeugt ein Datenaustauschformat "Update Immunisierungsstatus", das zusätzlich die Informationen zur Abrechenbarkeit enthält und sendet dieses an die zentrale Anwendung.
# Die Abrechnungsunterstützung erhält von der zentralen Anwendung einen Minimaldatensatz (d.h. nur die minimal notwendigen Daten für die Abrechnung), der ausschließlich die Impfungen enthält, die in der gewählten Zeit und Region entsprechen und die vom GDA als "abrechenbar" markiert wurden.
# Die Abrechnungsunterstützung kontrolliert den Anspruch an Abrechnung der einzelnen Einträge und leitet alle Schritte zur Überweisung des Abrechnungsbetrags in die Wege.

Im Rahmen des kostenlosen Kinderimpfkonzeptes rechnen sowohl Ärztinnen und Ärzte als auch Apotheken mit den Ländern Impfleistungen mit Hilfe der Informationen aus dem zentralen Impfregister ab. Die für die Abrechnung zuständigen Länderstellen können über die Informationen aus dem zentralen Impfregister nachvollziehen, welche Ärztin oder welcher Arzt, welche Impfung wann verabreicht hat und somit den Verrechnungs- und Ausbezahlungsprozess abwickeln. Nicht relevant für die Abrechnung sind z.B. nacherfasste oder stornierte Impfungen, Titereinträge oder Einträge zur Immunisierung durch Krankheit. Der aktuelle Stand der abrechnungsrelevanten Impfdaten aus dem zentralen Impfregister wird jeweils im Folgemonat für die Abrechnungsunterstützung zur Verfügung gestellt.

==U4 Datenkorrektur durch Behörde ==
Akteure: e-Impfpass Teilnehmer ("Max Muster"), Akteur in der Rolle "Korrekturberechtigte"

Szenario:
# Max Mustermann stellt fest, dass Dr. DeCarro, der mittlerweile in Pension ist, beim Übertragen einer Reiseimpfung aus dem Papierimpfpass eine falsche Impfung eingetragen hat und möchte diese in seinem e-Impfpass korrigieren lassen. Er stellt bei der Bezirksverwaltungsbehörde (Rolle "Korrekturberechtigte") einen entsprechenden Antrag.
# Die Bezirksverwaltungsbehörde ruft den "Kompletten Immunisierungsstatus" von Max Mustermann ab und führt eine entsprechende Änderungen (U5) durch.
# Das Softwaresystem der Bezirksverwaltungsbehörde, übergibt eine korrigierte Version des Dokuments "Update Immunisierungsstatus" (jenes, mit dem Dr. DeCarro damals den falschen Eintrag eingemeldet hat) an die zentrale Anwendung.
# Die zentrale Anwendung ersetzt alle Daten, die durch das originale Dokument "Update Immunisierungsstatus" übernommen worden waren durch die Daten, die in der korrigierten Version enthalten sind.

Grundlegend kann ein GDA nur jene Einträge in der ELGA-Infrastruktur aktualisieren, die von ihm selbst eingetragen wurden. Unter bestimmten Rahmenbedingungen sollen behördliche Stellen Daten im Impfpass korrigieren dürfen (z.B. wenn der impfende GDA, der eine Dokumentation ursprünglich erstellt hat, nicht mehr in der Lage ist, die Daten selbst zu korrigieren). Bei der zentralen e-Impfpass Anwendung gibt es daher ausgewählte GDA, die Bezirksverwaltungsbehörden, die Immunisierungseinträge von anderen GDA aktualisieren oder stornieren dürfen. Dies ist notwendig, da Immunisierungseinträge lebenslang gespeichert werden, und es somit eine vom eintragenden GDA unabhängige Korrekturmöglichkeit falscher Daten geben muss.

==U5 Krisenmanagement==
''Anmerkung: Das Krisenmanagements selbst steht nicht im Fokus dieses Leitfadens, es wird nur der Vollständigkeit halber die Vorgehensweise beschrieben.''
===U5.1 Krankheitsausbrüche===
Im Rahmen des Krisenmanagements bei Krankheitsausbrüchen muss von Kontaktpersonen (z.B. in Schule, Kindergarten, Ordination, Wartebereichen in Ambulanzen) der Impfstatus erhoben werden. Derzeit erfolgt die Erhebung des Impfstatus aufwändig manuell bzw. in den lokal begrenzten Datenbanken. Durch die zentrale e-Impfpass Anwendung werden Umgebungsuntersuchungen digital unterstützt, indem die Impfdokumentation von Kontaktpersonen für die österreichische Bevölkerung elektronisch bezogen wird. Dies wird das Ausbruchsmanagement beschleunigen und vereinfachen und somit Ansteckungen vermeiden sowie Kosten des Ausbruchs(-managements) senken.

===U5.1 Chargenrückruf===
Ein weiterer Anwendungsfall im Krisenmanagement betrifft den Chargenrückruf von Impfstoffen. Momentan veröffentlicht das Bundesamt für Sicherheit im Gesundheitswesen (BASG) im Anlassfall die Chargennummern von Arzneimitteln die Qualitätsmängel aufweisen. Apotheken, die Chargenrückrufe erhalten, sortieren die Ware aus und geben diese ihrem Lieferanten wieder mit. Sollte die Impfung die Apotheke schon verlassen haben, wird eruiert welcher GDA oder Bürger betroffen ist und im Anlassfall kontaktiert.

<div class="landscape">

=Datenarten=
==Dataset==

{| class="wikitable"
! style="width: 25%"| Name
! style="width: 40%"| Beschreibung
! style="width: 20%"| Mapping
! style="width: 15%"| Datenelement-Nr.
|- style="vertical-align:top;"
| '''Unterzeichnende Person (Dokument)''' (Rechtlicher Unterzeichner)
| Der "Rechtliche Unterzeichner" oder "Hauptunterzeichner" ist jene Person, welche für ein Update des Immunisierungsstatus bzw. den Nachtrag aus rechtlicher Sicht die Verantwortung übernimmt (gesamtes Dokument!). Der "Rechtliche Unterzeichner" entfällt beim Kompletten Immunisierungsstatus, da dieser automatisch von einem Gerät erstellt wird (hier entfällt die Angabe aller Unterzeichner).
| clinicalDoc.LegalAuthenticator
| elgaimpf-dataelement-368
|- style="vertical-align:top;"
| style="padding-left: 15px"|Zeitpunkt der Unterzeichnung
| Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.
|
| elgaimpf-dataelement-369
|- style="vertical-align:top;"
| style="padding-left: 15px"|Signatur
|
|
| elgaimpf-dataelement-370
|- style="vertical-align:top;"
| style="padding-left: 15px"|ID des Unterzeichners
|
|
| elgaimpf-dataelement-371
|- style="vertical-align:top;"
| style="padding-left: 15px"|Kontaktdaten
| Weitere Kontaktdaten (Telefon, Handy, Email...)
|
| elgaimpf-dataelement-372
|- style="vertical-align:top;"
| style="padding-left: 15px"|Name
| Name der Person
|
| elgaimpf-dataelement-373
|- style="vertical-align:top;"
| style="padding-left: 15px"|Organisation
|
|
| elgaimpf-dataelement-374
|- style="vertical-align:top;"
| '''Eintragende Person (Schreibkraft)'''
| Datenverarbeitende Person. Die Person, die Daten für den Impfpass dokumentiert.
| clinicalDoc.dataEnterer
| elgaimpf-dataelement-32
|- style="vertical-align:top;"
| '''Verantwortliche Person (Impfung)''' (Impfstelle)
| Die Person, die für die Impfung und ihre Dokumentation letztlich verantwortlich ist. "Dr. X (im Privat-KH Y) war für die Impfung verantwortlich/hat sie angeordnet". Bei neuem Immunisierungseintrag muss dieses Element angegeben sein. Bei einem Nachtrag kann dieses Element entfallen.
| substanceAdministration "Immunization Entry"/author
| elgaimpf-dataelement-307
|- style="vertical-align:top;"
| style="padding-left: 15px"|Name
|
|
| elgaimpf-dataelement-339
|- style="vertical-align:top;"
| style="padding-left: 30px"|Titel (Präfix)
| Titel der Person (voran- und nachgestellte Titel)
|
| elgaimpf-dataelement-340
|- style="vertical-align:top;"
| style="padding-left: 30px"|Vorname
| Vornamen der Person
|
| elgaimpf-dataelement-343
|- style="vertical-align:top;"
| style="padding-left: 30px"|Nachname
| Nachname der Person
|
| elgaimpf-dataelement-344
|- style="vertical-align:top;"
| style="padding-left: 15px"|ID des Unterzeichners
| ID der verantwortlichen Person (lokaler Identifikator)
|
| elgaimpf-dataelement-346
|- style="vertical-align:top;"
| style="padding-left: 15px"|Kontaktdaten
| Weitere Kontaktdaten (Telefon, Handy, Email...)
|
| elgaimpf-dataelement-347
|- style="vertical-align:top;"
| style="padding-left: 15px"|Organisation
|
|
| elgaimpf-dataelement-353
|- style="vertical-align:top;"
| style="padding-left: 30px"|ID der Organisation
|
|
| elgaimpf-dataelement-381
|- style="vertical-align:top;"
| style="padding-left: 30px"|Name der Organisation
|
|
| elgaimpf-dataelement-382
|- style="vertical-align:top;"
| style="padding-left: 30px"|Telekom
| Weitere Kontaktdaten (Telefon, Handy, Email...)
|
| elgaimpf-dataelement-383
|- style="vertical-align:top;"
| style="padding-left: 30px"|Adresse
| Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...)
|
| elgaimpf-dataelement-384
|- style="vertical-align:top;"
| style="padding-left: 15px"|Freigabezeitpunkt (Zeitpunkt der Unterzeichnung)
| Der Zeitpunkt, an dem die Dokumentation freigegeben wurde
| substanceAdministation.author.time
| elgaimpf-dataelement-366
|- style="vertical-align:top;"
| '''Impfende Person (Impfarzt)'''
| Die Person, die die Impfung durchführt, z.B. ein Arzt oder eine Hebamme oder DGKS im Auftrag des verantwortlichen Arztes. Die Impfende Person kann mit dem verantwortlichen Person ident sein und beide auch (redundant) angegeben werden.
| substanceAdministration "Immunization Entry"/performer
| elgaimpf-dataelement-140
|- style="vertical-align:top;"
| style="padding-left: 15px"|Name
| Name der Person
|
| elgaimpf-dataelement-236
|- style="vertical-align:top;"
| style="padding-left: 30px"|Titel (Präfix)
| Titel der Person (voran- und nachgestellte Titel)
|
| elgaimpf-dataelement-237
|- style="vertical-align:top;"
| style="padding-left: 30px"|Vorname
| Vornamen der Person
|
| elgaimpf-dataelement-240
|- style="vertical-align:top;"
| style="padding-left: 30px"|Nachname
| Nachname der Person
|
| elgaimpf-dataelement-241
|- style="vertical-align:top;"
| style="padding-left: 15px"|Organisation
|
|
| elgaimpf-dataelement-294
|- style="vertical-align:top;"
| style="padding-left: 30px"|ID der Organisation
|
|
| elgaimpf-dataelement-389
|- style="vertical-align:top;"
| style="padding-left: 30px"|Name der Organisation
|
|
| elgaimpf-dataelement-390
|- style="vertical-align:top;"
| style="padding-left: 30px"|Telekom
| Weitere Kontaktdaten (Telefon, Handy, Email...)
|
| elgaimpf-dataelement-391
|- style="vertical-align:top;"
| style="padding-left: 30px"|Adresse
| Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...)
|
| elgaimpf-dataelement-392
|- style="vertical-align:top;"
| style="padding-left: 15px"|Rolle
| Berufsrolle der impfenden Person (Auswahlliste)
|
| elgaimpf-dataelement-210
|- style="vertical-align:top;"
| '''Nachtragende Person'''
| Die Person / Gerät, welche/s Daten für den Impfpass dokumentiert. Nur für Nachtragung relevant "Dr. Z hat diese Impfung nachgetragen", "Daten stammen aus Wiener Impfregister"
| substanceAdministration "Immunization Entry"/participant mit @typeCode = "ENT"
| elgaimpf-dataelement-285
|- style="vertical-align:top;"
| style="padding-left: 15px"|Name
| Name der Person
|
| elgaimpf-dataelement-286
|- style="vertical-align:top;"
| style="padding-left: 30px"|Titel (Präfix)
| Titel der Person
|
| elgaimpf-dataelement-287
|- style="vertical-align:top;"
| style="padding-left: 30px"|Vorname
| Vornamen der Person
|
| elgaimpf-dataelement-290
|- style="vertical-align:top;"
| style="padding-left: 30px"|Nachname
| Nachname der Person
|
| elgaimpf-dataelement-291
|- style="vertical-align:top;"
| style="padding-left: 15px"|Datum der Eintragung (Eintragungsdatum, Datum der Dokumentation)
| Datum und Zeit, an dem die Impfung in den e-Impfpass eingetragen d.h. dokumentiert oder geändert wurde. Gilt auch bei einer nachträglichen Eintragung aus einer anderen Quelle (z.B. Papier-Impfpass, andere elektronische Quellen), d.h. NICHT das Impf-Datum
| substanceAdministration "Immunization Entry"/participant mit @typeCode = "TRANS" / time
| elgaimpf-dataelement-293
|- style="vertical-align:top;"
| '''Impfling''' (Patient, Klient, Kunde)
| Der Impfling ist die Person, über die der e-Impfpass Impfungen verwaltet und über deren Gesundheitsdaten berichtet wird.. Entspricht dem "Patienten".
| clinicalDocument.recordTarget
| elgaimpf-dataelement-1
|- style="vertical-align:top;"
| style="padding-left: 15px"|Name
| Name der Person
|
| elgaimpf-dataelement-172
|- style="vertical-align:top;"
| style="padding-left: 30px"|Titel (Präfix)
| Titel der Person (voran- und nachgestellte Titel)
|
| elgaimpf-dataelement-173
|- style="vertical-align:top;"
| style="padding-left: 30px"|Vorname
| Vornamen der Person
|
| elgaimpf-dataelement-176
|- style="vertical-align:top;"
| style="padding-left: 30px"|Nachname
| Nachname der Person
|
| elgaimpf-dataelement-177
|- style="vertical-align:top;"
| style="padding-left: 15px"|Geburtstdatum
| Geburtstdatum der Person
|
| elgaimpf-dataelement-95
|- style="vertical-align:top;"
| style="padding-left: 15px"|Geschlecht (Administatives Geschlecht)
| Administatives Geschlecht der Person im Sinne der Anrede oder Adressierung zB Brief: "Herr" oder "Frau"
| Werte: M, F. UNK (Unbekannt)
| elgaimpf-dataelement-94
|- style="vertical-align:top;"
| style="padding-left: 15px"|LokaleID
| Identifikator des Impflings im lokalen IT-System (Patientenbezogen, nicht fallbezogen) Verpflichtend mit Eintragung einer Impfung anzugeben.
|
| elgaimpf-dataelement-86
|- style="vertical-align:top;"
| style="padding-left: 15px"|SVNr (Sozialversicherungsnummer)
| Sozialversicherungsnummer
|
| elgaimpf-dataelement-87
|- style="vertical-align:top;"
| style="padding-left: 15px"|bPK-GH
| Gemäß eGovernment-Gesetz ist das bPk-GH der eindeutige Identifikator für den Gesundheitsbereich. Verpflichtende Angabe im CDA-Header für spezifische ELGA-Anwendungen (z.B. e-Medikation)
|
| elgaimpf-dataelement-88
|- style="vertical-align:top;"
| style="padding-left: 15px"|Adresse
| Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...)
|
| elgaimpf-dataelement-219
|- style="vertical-align:top;"
| style="padding-left: 30px"|Straße
|
|
| elgaimpf-dataelement-252
|- style="vertical-align:top;"
| style="padding-left: 30px"|Hausnummer
|
|
| elgaimpf-dataelement-253
|- style="vertical-align:top;"
| style="padding-left: 30px"|Postleitzahl
|
|
| elgaimpf-dataelement-254
|- style="vertical-align:top;"
| style="padding-left: 30px"|Stadt
|
|
| elgaimpf-dataelement-255
|- style="vertical-align:top;"
| style="padding-left: 30px"|Bundesland
|
|
| elgaimpf-dataelement-256
|- style="vertical-align:top;"
| style="padding-left: 30px"|Land
|
|
| elgaimpf-dataelement-257
|- style="vertical-align:top;"
| style="padding-left: 15px"|Gemeindekennziffer (GKZ, ÖSTAT-Nr.)
| Allen Gemeinden Österreichs ist eine 5-stellige Gemeindekennziffer (GKZ) zugeordnet. Das Gemeindeverzeichnis bildet die Verwaltungsgliederung in Verwaltungssprengel ab. Die Vergabe der Gemeindekennziffer obliegt Statistik Austria (Adressregisterverordnung – AdrRegV, BGBl. 218/2005, §1).
| Kein Mapping, ist nicht im CDA Dokumenten enthalten. Liegt in der zentralen Anwendung zur Adresse vor.
| elgaimpf-dataelement-49
|- style="vertical-align:top;"
| style="padding-left: 15px"|Bezirkskennziffer (BKZ)
| Wie Gemeindekennziffer, erste 3 Stellen
| Kein Mapping, ist nicht im CDA Dokumenten enthalten. Liegt in der zentralen Anwendung zur Adresse vor.
| elgaimpf-dataelement-85
|- style="vertical-align:top;"
| style="padding-left: 15px"|Kontaktdaten
| Weitere Kontaktdaten (Telefon, Handy, Email...)
|
| elgaimpf-dataelement-216
|- style="vertical-align:top;"
| style="padding-left: 30px"|Telefon Mobil
|
|
| elgaimpf-dataelement-227
|- style="vertical-align:top;"
| style="padding-left: 30px"|Telefon Festnetz
|
|
| elgaimpf-dataelement-228
|- style="vertical-align:top;"
| style="padding-left: 30px"|Mail
|
|
| elgaimpf-dataelement-229
|- style="vertical-align:top;"
| style="padding-left: 30px"|FAX
|
|
| elgaimpf-dataelement-230
|- style="vertical-align:top;"
| '''Personengruppe''' (Expositionsrisikogruppe)
| Merkmal für Zugehörigkeit des Impflings zu bestimmten Personen- oder Risikogruppen (z.B. Gesundheitsberufe). Bei bestimmten Personengruppen kann das Impfschema und damit die berechnete Impffrist abweichen. Optional, mehrfache Angabe möglich.
| Sektion "Expositionsrisiko Personengruppen" mit Act "Expositionsrisiko Problem Concern Entry"
| elgaimpf-dataelement-125
|- style="vertical-align:top;"
| style="padding-left: 15px"|Zeitbereich
| Zeitbereich, in dem die Zugehörigkeit zur Personengruppe aktiv ist oder war
|
| elgaimpf-dataelement-394
|- style="vertical-align:top;"
| '''Impfung''' (Vakzination, Schutzimpfung, Immunisierung )
| Dokumentierte Impfung: ein einzelne Gabe eines Impfstoffes
| Sektion "Impfungen - kodiert", substanceAdministration "Immunization Entry"
| elgaimpf-dataelement-2
|- style="vertical-align:top;"
| style="padding-left: 15px"|Impfung (Klassifikation) (Impfschutz, Impfstoffgruppe, Immunisierung)
| Impfschutz gegen eine bestimmte Krankheit oder einen Erreger. Mehrfach-Attribut - Bei einer Impfung mit einem Produkt können mehrere Wirkstoffe (gegen mehrere Krankheiten) verabreicht werden. Alle einzelnen "Impfungen" müssen zu dem Produkt zentral verfügbar sein.
| substanceAdministration "Immunization Entry" und entryRelationship/Observation "Immunization Target Entry"
| elgaimpf-dataelement-6
|- style="vertical-align:top;"
| style="padding-left: 15px"|Impfschema (Impfkonzept, vaccinationProtocol)
| Name für den "Plan der notwendigen Impf-Dosen" (Regelwerk für die Gabe von Impfdosen bzw Teilimpfungen zur Immunisierung; Grundimmunissierung und Auffrischung) Wenn bei Impfung nicht angegeben, wird das "Default-Schema" angenommen.
| Mapping: substanceAdministration "Immunization Entry" und precondition/criterion "Immunization Schedule Entry"
| elgaimpf-dataelement-25
|- style="vertical-align:top;"
| style="padding-left: 15px"|Dosis-Nummer (Reihenfolgenummer in der Sequenz der Impfdosen)
| Angabe, um welche Impfung oder Teilimpfung es sich handelt (entsprechend einem Impfschema)
| Mapping: criterion "Immunization Schedule Entry"/value
| elgaimpf-dataelement-30
|- style="vertical-align:top;"
| style="padding-left: 15px"|Impfdatum (Vaccination administration date)
|
| substanceAdministration "Immunization Entry"/effectiveTime
| elgaimpf-dataelement-8
|- style="vertical-align:top;"
| style="padding-left: 15px"|Impfort
| Ort, an dem die Impfung stattgefunden hat (wenn abweichend von Organisation Impfarzt). (z.B: Öffentliche Einrichtung, Schule (+ Klasse), Kaserne, Betrieb ...)
| Muss immer im "Performer" Element des Immunization Entry angegeben werden.
Wenn verantwortliche Arzt selbst Impft, muss der er zusätzlich als Impfarzt eingetragen werden. substanceAdministration "Immunization Entry"/performer/assignedEntity/representedOrganization/addr (mit @use="PHYS")
| elgaimpf-dataelement-137
|- style="vertical-align:top;"
| style="padding-left: 15px"|Abrechenbarkeit
| Kennzeichen, ob Impfung mit Land abgerechnet werden kann (Eintragung durch impfenden Arzt)
| Notwendig für Filterung der Daten, die an Länder zur Abrechnung der Impfungen weitergeleitet werden. Die Abrechenbarkeit selbst wird vom Land geprüft und festgestellt.Mapping: substanceAdministration "Immunization Entry" und entryRelationship/act "Immunization Billability Entry"
| elgaimpf-dataelement-29
|- style="vertical-align:top;"
| style="padding-left: 30px"|Klassifikator (Honorar-Klassifikation)
| Abrechnungsrelevante Klassifikation der Impfenden Person (zB "Arzt mit Hausapotheke"). Wird im Zentralsystem nicht mehr benötigt, daher gestrichen. --> Die Verrechnung etc. erfolgt über die internen GDA Systeme (benötigt wird nur die Kennzeichnungsmöglichkeit ob abrechenbar oder nicht
| act "Immunization Billability Entry"/code/qualifier
| elgaimpf-dataelement-367
|- style="vertical-align:top;"
| style="padding-left: 30px"|Impfindikation
| Grund für die Impfung (optional). Wird für Abrechnung benötigt: * IG1 Indikationsimpfung für Risikogruppe * IG2 Wiederholungsimpfung aufgrund medizinischer Indikation
| act "Immunization Billability Entry"/code/qualifier
| elgaimpf-dataelement-379
|- style="vertical-align:top;"
| style="padding-left: 30px"|Impfgutschein
| Identifikationskennzeichen eines Impf-Gutscheins (bei Vorliegen von Impf-Gutscheinheften)
| Notwendig für Abrechnung. Alphanumerisches Kennzeichen (gültig 1x für eine Impfung). Keine weitere Prüfung im e-Impfpass.Mapping: act "Immunization Billability Entry" mit act/id
| elgaimpf-dataelement-139
|- style="vertical-align:top;"
| '''Impfstoff (Produkt)''' (Arzneimittel)
| Daten zur verabreichten Arzneimittelspezialität
| substanceAdministration "Immunization Entry" und consumable/manufacturedProduct "Vaccine Product" bzw. "Vaccine Product nicht angegeben"
| elgaimpf-dataelement-3
|- style="vertical-align:top;"
| style="padding-left: 15px"|Arzneispezialität (Handelsname)
| Vom Hersteller registrierter Name des Impfstoffes, zB "Encepur 0.5ml"
| manufacturedProduct/manufacturedMaterial/name
| elgaimpf-dataelement-31
|- style="vertical-align:top;"
| style="padding-left: 15px"|Pharmazentralnummer (PZN)
| Pharmazentralnummer der Arzneispezialität
| manufacturedProduct/manufacturedMaterial/code
| elgaimpf-dataelement-5
|- style="vertical-align:top;"
| style="padding-left: 15px"|Chargennummer (Charge)
| Chargennummer der Arzneispezialität, die verabreicht wurde
| manufacturedProduct/manufacturedMaterial/lotNumberText
| elgaimpf-dataelement-4
|- style="vertical-align:top;"
| style="padding-left: 15px"|Ablaufdatum
| Muss dokumentiert werden. Kann aus 2D Barcode abgleitet werden Nicht für "Nacherfassung" erforderlich
| substanceAdministration "Immunization Entry" mit entryRelationship/act "Immunization Billability Entry"/effectiveTime
| elgaimpf-dataelement-134
|- style="vertical-align:top;"
| style="padding-left: 15px"|UniqueIdentifier (Serialisierungsnummer)
| Serialisierungsnummer oder "Packungs-Identifikator. Durch die Serialisierungsnummer ist jede einzelne Packung im europäischen Markt individualisierbar, entsprechend Fälschungsschutzrichtlinie 2011/62/EU und zugehörigerr delegierte Verordnung (EU) 2016/161
| manufacturedProduct/id
| elgaimpf-dataelement-135
|- style="vertical-align:top;"
| style="padding-left: 15px"|Hersteller
| Hersteller des Impfstoffes (der Arzneispezialität)
| manufacturedProduct/manufacturerOrganization
| elgaimpf-dataelement-12
|- style="vertical-align:top;"
| style="padding-left: 15px"|ATC
| ATC-Code des Wirkstoffs aus Fachinformation
| manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:code
| elgaimpf-dataelement-235
|- style="vertical-align:top;"
| style="padding-left: 15px"|Wirkstoff
| Wirkstoff(e) des Arzneimittels, zB "Masernviren, Stamm Schwarz (lebend, attenuiert)
| manufacturedMaterial/pharm:ingredient
| elgaimpf-dataelement-185
|- style="vertical-align:top;"
| style="padding-left: 15px"|Menge (Dosis)
| Menge des Wirkstoffs der verabreichten Arzneispezialität (Mengenangabe aus Fachinformation). Die tatsächlich verabreichte Menge kann dokumentiert werden, falls von Fachinformation abweichend. Falls zwei Packungen verabreicht werden, muss 2x eine PZN gescannt werden und zwei Datensätze eingelesen werden können, die gemeinsam als eine "Dosis" (=Teilimpfung) verspeichert werden.
| substanceAdministration "Immunization Entry"/doseQuantity
| elgaimpf-dataelement-15
|- style="vertical-align:top;"
| '''Impfempfehlung''' (Impfkalender)
| Daten der empfohlenen (zukünftigen) Impfungen: * Impfung, Arzneimittel, frühestmöglicher Folgetermin (Tag) * Anzugebende Folgetermine: immer nur der nächste Folgetermin Die Impflogik gilt grundsätzlich für lt. Impfpan empfohlene Impfungen und für darüberhinaus bereits einmal verabreichte Impfungen Automatisch / von Arzt eingetragen (zusätzlich)
| Sektion "Impfempfehlungen - kodiert" mit entry/substanceAdministration "Immunization Recommendation Entry"
| elgaimpf-dataelement-169
|- style="vertical-align:top;"
| style="padding-left: 15px"|Impf-Frist (Datum der nächsten Impfung)
| Datum (Frist oder Zeitraum), an dem die nächste Impftermin (für diese Impfung) notwendig ist. Wird definiert durch: Nationaler Impfplan Fachinformation (liegt derzeit nicht strukturier vor) Individuelle Konstellation des Impflings --> manueller Eintrag bei Impfung (Abhängig vom Produkt bzw "Impfung", wenn Kombinationspräparat)
| choice von /effectiveTime als TS und /effectiveTime als IVL_TS
| elgaimpf-dataelement-28
|- style="vertical-align:top;"
| style="padding-left: 15px"|Dosis-Nummer (Reihenfolgenummer in der Sequenz der Impfdosen)
| Angabe, um welche Impfung oder Teilimpfung es sich handelt (entsprechend einem Impfschema)
| /precondition/criterion "Immunization Schedule Entry"
| elgaimpf-dataelement-231
|- style="vertical-align:top;"
| style="padding-left: 15px"|Autor (Quelle)
| Person oder System, das die Empfehlung generiert
| /author
| elgaimpf-dataelement-232
|- style="vertical-align:top;"
| style="padding-left: 15px"|Impfung (Klassifikation) (Referenz)
| Verweist auf die Impfung, für die diese Empfehlung gilt. Eine Impfempfehlung pro Impfung (nicht pro Kombination)
| entryRelationship mit observation "Immunization Target Entry"
| elgaimpf-dataelement-380
|- style="vertical-align:top;"
| style="padding-left: 15px"|Impfstoff (Referenz)
| Verweist auf das Produkt, für das die Empfehlung gilt; aber mit eingeschränkten Attributen (PZN)
| consumable
| elgaimpf-dataelement-233
|- style="vertical-align:top;"
| style="padding-left: 15px"|Impfschema (Referenz)
| Referenz auf den der Empfehlung zugrundeliegenden Impfplan, Fachinformation, Dokumentation, … 1. Nationaler Impfplan 2. Fachinformation (liegt derzeit nicht strukturiert vor) 3. Individuelle Konstellation des Impflings --> manueller Eintrag bei Impfung (Abhängig vom Produkt bzw "Impfung", wenn Kombinationspräparat)
| reference/externalDocument
| elgaimpf-dataelement-234
|- style="vertical-align:top;"
| style="padding-left: 15px"|Begründung
| Freitext zur Begründung einer vom Impfarzt angepassten Impfempfehlung
| entryRelationship/@typeCode = "RSON" mit act "Comment Entry"
| elgaimpf-dataelement-171
|- style="vertical-align:top;"
| '''Impfrelevante Erkrankung'''
| Dokumentation von Infektionskrankheiten, die eine langfristige Immunisierung nach sich ziehen und daher eine weitere Impfung nicht notwendig machen. Die Eintragung erfolgt optional bei der Erhebung der Impfanamnese.
| Sektion "Impfrelevante Erkrankungen - kodiert" mit act "Impfrelevante Erkrankungen Problem Concern Entry"
| elgaimpf-dataelement-27
|- style="vertical-align:top;"
| style="padding-left: 15px"|Impfrelevante Erkrankung
| Impfrelevante Erkrankung (aus Auswahlkatalog, z.B. FSME, Varizellen, ...)
| Sektion "Impfrelevante Erkrankungen - kodiert" mit act "Impfrelevante Erkrankungen Problem Concern Entry"
| elgaimpf-dataelement-126
|- style="vertical-align:top;"
| style="padding-left: 15px"|Erkrankungsdatum
| Zeitintervall, in der die Erkrankung beobachtet wurde
|
| elgaimpf-dataelement-393
|- style="vertical-align:top;"
| style="padding-left: 15px"|Bemerkungen (Anmerkungen)
| Freitext für Eintragung des Nachweises der durchgemachten Erkrankung, z.B. durch Vorbefund oder Laborbefund mit Titer.
| observation "Impfrelevante Erkrankungen Problem Entry" mit entryRelationship act "Comment Entry"
| elgaimpf-dataelement-16
|- style="vertical-align:top;"
| style="padding-left: 15px"|Autor
| Erfasser der Information
|
| elgaimpf-dataelement-282
|- style="vertical-align:top;"
| style="padding-left: 15px"|Reaktion
| Aufgetretene Reaktion, Auswahlkatalog
|
| elgaimpf-dataelement-283
|- style="vertical-align:top;"
| style="padding-left: 15px"|Impfung (Referenz)
| Verknüpfung zu Impfung
|
| elgaimpf-dataelement-284
|- style="vertical-align:top;"
| '''Antikörper-Bestimmung (Impftiter)'''
| Ergebnisse von Antikörper-Untersuchungen, Antikörper Bestimmungen für für Virushepatitis A und B, Röteln und Varizellen etc.
| Sektion "Antikörper-Bestimmung" mit act "Lab Report Data Processing Entry" und entryRelationship "Laboratory Observation Entry"
| elgaimpf-dataelement-129
|- style="vertical-align:top;"
| style="padding-left: 15px"|Analyse
| Gemessener Laborparameter
| "Laboratory Observation Entry"
| elgaimpf-dataelement-271
|- style="vertical-align:top;"
| style="padding-left: 15px"|Wert
| Wert der Analyse
| "Laboratory Observation Entry" / value
| elgaimpf-dataelement-272
|- style="vertical-align:top;"
| style="padding-left: 15px"|Einheit
| Einheit des Messwerts. Muss in UCUM Notation angegeben werden
| "Laboratory Observation Entry" /value/@unit
| elgaimpf-dataelement-273
|- style="vertical-align:top;"
| style="padding-left: 15px"|Bewertung (Interpretation)
| Interpretations des Messwerts (Interpretationskennzeichen)
| "Laboratory Observation Entry" /interpretationCode
| elgaimpf-dataelement-274
|- style="vertical-align:top;"
| style="padding-left: 15px"|Datum
| Datum der Abnahme (wenn nicht vorhanden, Datum der Bestimmung)
| "Laboratory Observation Entry" /effectiveTime
| elgaimpf-dataelement-275
|- style="vertical-align:top;"
| style="padding-left: 15px"|Durchführendes Labor
| Durchführendes Labor
| "Laboratory Observation Entry" / performer
| elgaimpf-dataelement-276
|- style="vertical-align:top;"
| style="padding-left: 30px"|ID der Organisation
|
|
| elgaimpf-dataelement-277
|- style="vertical-align:top;"
| style="padding-left: 30px"|Name der Organisation
|
|
| elgaimpf-dataelement-278
|- style="vertical-align:top;"
| style="padding-left: 30px"|Telekom
| Weitere Kontaktdaten (Telefon, Handy, Email...)
|
| elgaimpf-dataelement-279
|- style="vertical-align:top;"
| style="padding-left: 30px"|Adresse
| Adresse der Person (Subelemente: Straße, Hausnummer, PLZ, Ort) Qualifier zur Bezeichnung der Art der Adresse: Wohnadresse, Arbeitsadresse, Pflege, Temporär...)
|
| elgaimpf-dataelement-280
|- style="vertical-align:top;"
| '''Informationsquelle'''
| Herkunft der Information
|
| elgaimpf-dataelement-11
|}

[https://art-decor.org/decor/services/RetrieveDataSet?id=1.2.40.0.34.777.4.1.1&language=de-DE&effectiveDate=2018-08-12T16:37:15&format=html&hidecolumns=3456bcdefghijklmno Link zur Live-Version]

==Dataset - Szenario Kompletter Immunisierungsstatus==
[https://art-decor.org/decor/services/RetrieveTransaction?id=1.2.40.0.34.777.4.4.16&language=de-DE&effectiveDate=2019-01-15T16:37:00&format=html&hidecolumns=56bcdefghijklmnop Link zur Live-Version]

==Dataset - Szenario Update Immunisierungsstatus==
[https://art-decor.org/decor/services/RetrieveTransaction?id=1.2.40.0.34.777.4.4.17&language=de-DE&effectiveDate=2019-01-15T16:58:01&format=html&hidecolumns=56bcdefghijklmnop Link zur Live-Version]

</div class="landscape">




=Technische Spezifikation=
==Übersicht CDA Struktur "Kompletter Immunisierungsstatus"==
Die Struktur des CDA Austauschformats ist in den nachfolgenden Kapiteln im Detail beschrieben. Zum schnellen Einstieg findet sich hier eine stark vereinfachte Zusammenfassung der Elemente.
Dieses Dokument kann von der zentralen Anwendung "e-Impfpass" angefragt werden. Es enthält alle gespeicherten Informationen zum Immunisierungsstatus der Person und wird jeweils aktuell erzeugt ("On-Demand-Dokument").

ELGA Interoperabilitätsstufen (EIS): Dieses Dokument existiert ausschließlich in einer voll strukturierten Form, eine Unterscheidung der Interoperabilitätsstufen ist daher nicht notwendig.

[[Datei:KompletterImmunisierungsstatus.png|400px|CDA-Dokument in Ausprägung "Kompletter Immunisierungsstatus"]]

<ref group="Abbildung">CDA-Dokument in Ausprägung "Kompletter Immunisierungsstatus"</ref>
<div class="landscape">
===CDA Header===
Der Header enthält die (administrativen) Dokument-Metadaten
* '''Allgemeine Dokumentinformationen:''' Dokumenten-Id, Code, Titel, Erstellungszeitpunkt, Sprache, Version
* '''"Impfling"''' Angaben zur Person (Patient), deren Immunisierungsstatus beschrieben wird: Name, Geburtsdatum, Geschlecht, Identifikatoren, Adresse und Kontaktdaten, ...
* '''Mitwirkende am Dokument''': Autoren, Schreibkraft, Verwalter, Unterzeichner
* '''Related Document:''' Verweis auf ein allfällig ersetztes Dokument (Vorversion)

Der Header entspricht im Wesentlichen den bisherigen ELGA-CDA-Leitfäden ("Allgemeiner Leitfaden"). Für den e-Impfpass wurden punktuell Neuerungen eingeführt:
* TemplateIds für die Versionskennung
* Zusätzliches Translation-Element für den clinicalDocument.code

'''Hinweis''': Einige Header-Elemente des Allgemeinen Leitfadens werden hier nicht benötigt [NP], sind aber der Vollständigkeit halber angegeben. [NP]-Elemente dürfen nicht angegeben werden, bzw. sind zu ignorieren.
Beispiele: Data Enterer, Authorization, LegalAuthenticator, ...

===CDA Body===
Der "Structured Body" enthält die tatsächlichen (medizinischen) Inhalte des Dokuments
* Kapitel '''Impfungen''': Sammlung der dokumentierten Impfungen
** Impfung, Impfdatum, Impfstoff, Impfschema und Dosisnummer, Impfstelle, Krankheit gegen welche die Impfung schützt, PZN, Chargennummer (LOT-Nr), Dosierung und weitere Angaben zur Verabreichung (Teilnehmende Personen)
* Kapitel '''Personengruppe''': Dokumentiert die Zugehörigkeit zu speziellen Personengruppen.
** Personengruppe, Datumsbereich der Zugehörigkeit zur Gruppe
* Kapitel '''Impfrelevante Erkrankungen''': Sammlung der dokumentierten impfrelevanten Erkrankungen
** Erkrankung, Datumsbereich
* Kapitel '''Antikörper-Untersuchungen''': Sammlung der dokumentierten Antikörper-Bestimmungen
** Untersuchung, Wert, Bewertung, Datum
* Kapitel '''Impfempfehlungen''': Sammlung der dokumentierten Impfempfehlungen (automatisch erstellte sowie vom Impfarzt individuell empfohlene)
** Strukturell wie Impfungen, mit anderen Pflichtfeldern und anderem Status

Anmerkung: Impfreaktionen werden in der derzeit geplanten Pilot-Umsetzung nicht unterstützt.

==Übersicht CDA Struktur "Update Immunisierungsstatus"==
Die Struktur des CDA Austauschformats ist in den nachfolgenden Kapiteln im Detail beschrieben. Zum schnellen Einstieg findet sich hier eine stark vereinfachte Zusammenfassung der Elemente.

Dieses Dokument wird vom impfenden GDA erstellt und an die zentrale Applikation gesendet. Es enthält die Informationen, die der GDA bei einem Besuch dokumentiert. Es kann Impfungen, Impfempfehlungen, impfrelevante Erkrankungen, Antikörperbestimmungen, etc enthalten.

ELGA Interoperabilitätsstufen (EIS): Dieses Dokument existiert ausschließlich in einer voll strukturierten Form, eine Unterscheidung der Interoperabilitätsstufen ist daher nicht notwendig.

[[Datei:UpdateImmunisierungsstatus.png|400px|CDA-Dokument in Ausprägung "Update Immunisierungsstatus"]]

<ref group="Abbildung">CDA-Dokument in Ausprägung "Update Immunisierungsstatus"</ref>

===CDA Header===
Der Header enthält die (administrativen) Dokument-Metadaten
* '''Allgemeine Dokumentinformationen:''' Dokumenten-Id, Code, Titel, Erstellungszeitpunkt, Sprache, Version
* '''"Impfling"''' Angaben zur Person (Patient), deren Immunisierungsstatus beschrieben wird: Name, Geburtsdatum, Geschlecht, Identifikatoren, Adresse und Kontaktdaten, ...
* '''Mitwirkende am Dokument''': Autoren, Erfasser, Verwalter, Unterzeichner
* '''Related Document:''' Verweis auf ein allfällig ersetztes Dokument (Vorversion)

Der Header entspricht im Wesentlichen den bisherigen ELGA-CDA-Leitfäden ("Allgemeiner Leitfaden"). Für den e-Impfpass wurden punktuell Neuerungen eingeführt:
* TemplateIds für die Versionskennung
* Zusätzliches Translation-Element für den clinicalDocument.code

===CDA Body===
Der "Structured Body" enthält die tatsächlichen (medizinischen) Inhalte des Dokuments
* Kapitel '''Impfungen''': Sammlung der dokumentierten Impfungen
** Impfung, Impfdatum, Impfstoff, Impfschema und Dosisnummer, Impfstelle, Krankheit gegen welche die Impfung schützt, PZN, Chargennummer (LOT-Nr), Dosierung und weitere Angaben zur Verabreichung (Teilnehmende Personen)
* Kapitel '''Personengruppe''': Dokumentiert die Zugehörigkeit zu speziellen Personengruppen.
** Personengruppe, Datumsbereich der Zugehörigkeit zur Gruppe
* Kapitel '''Impfrelevante Erkrankungen''': Sammlung der dokumentierten impfrelevanten Erkrankungen
** Erkrankung, Datumsbereich
* Kapitel '''Antikörper-Bestimmungen''': Sammlung der dokumentierten Laboruntersuchungen der impfrelevanten Antikörper ("Impftiter")
** Untersuchung, Wert, Bewertung, Datum
* Kapitel '''Impfempfehlungen''': Vom Impfarzt individuell empfohlene Impfungstermine, wenn abweichend von den automatisch erstellten Impfempfehlungen
** Strukturell wie Impfungen, mit anderen Pflichtfeldern und anderem Status

Anmerkung: Impfreaktionen werden in der derzeit geplanten Pilot-Umsetzung nicht unterstützt.



==Übersicht der Strukturen mit Konformität und Kardinalität==
Folgende Tabellen sollen einen groben Überblick über die Inhalte der einzelnen Sektionen geben. Details sind den entsprechenden Templates zu entnehmen.

===Sektion Impfungen - kodiert===
'''1. Dokumentation einer Impfung''':

*Kompletter Immunisierungsstatus: Impfung wird angezeigt.
*Update Immunisierungsstatus: Neue Impfung wird durchgeführt.
*Update Nachtrag Immunisierungsstatus: Nachtrag einer bereits durchgeführten Impfung.

''Anmerkung'': Entweder-Oder-Auswahlmöglichkeiten sind mit "#)" gekennzeichnet.

{| class="wikitable"
! colspan="3" style="width: 70%" |Sektion Impfungen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="3" |SECTION Impfungen - kodiert (1.2.40.0.34.6.0.11.2.1)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="2" |Immunization Entry (1.2.40.0.34.6.0.11.3.1)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
|#) Vaccine Product (1.2.40.0.34.6.0.11.9.32)
|C [1..1]
|M [1..1]
|C [1..1]
|-
|
|
|#) Vaccine Product nicht angegeben (1.2.40.0.34.6.0.11.9.31)
|C [1..1]
|NP [0..0]
|C [1..1]
|-
|
|
|Performer Body - Impfende Person (1.2.40.0.34.6.0.11.9.21)
|O [0..1]
|C [1..1]
|O [0..1]
|-
|
|
|Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|O [0..1]
|M [1..1]
|O [0..1]
|-
|
|
|Participant Body - Transcriber (1.2.40.0.34.6.0.11.9.14)
|O [0..1]
|NP [0..0]
|M [1..1]
|-
|
|
|Immunization Target Entry (1.2.40.0.34.6.0.11.3.2)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
|Immunization Billability Entry (1.2.40.0.34.6.0.11.3.5)
|NP [0..0]
|O [0..1]
|NP [0..0]
|-
|
|
|External Document Entry (1.2.40.0.34.6.0.11.3.14)
|M [1..1]
|O [0..1]
|O [0..1]
|-
|
|
|Immunization Schedule Entry (1.2.40.0.34.6.0.11.3.10)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="2" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|Author Body (1.2.40.0.34.6.0.11.9.36)
|O [0..*]
|O [0..*]
|O [0..*]
|}

'''2.''' Es wird '''keine Impfung''' durchgeführt, sondern z.B. eine Krankheit eingetragen.

{| class="wikitable"
! colspan="3" style="width: 70%" |Sektion Impfungen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="3" |SECTION Impfungen - kodiert (1.2.40.0.34.6.0.11.2.1)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="2" |Immunization Entry Impfung nicht angegeben (1.2.40.0.34.6.0.11.3.28)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
|Vaccine Product nicht angegeben (1.2.40.0.34.6.0.11.9.31)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="2" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|Author Body (1.2.40.0.34.6.0.11.9.36)
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Expositionsrisiko Personengruppen - kodiert===
{| class="wikitable"
! colspan="3" style="width: 70%" |Sektion Expositionsrisiko Personengruppen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="3" |SECTION Expositionsrisiko Personengruppen - kodiert (1.2.40.0.34.6.0.11.2.4)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="2" |Expositionsrisiko Problem Concern Entry (1.2.40.0.34.6.0.11.3.20)
|R [1..*]
|R [1..*]
|R [1..*]
|-
|
|
|Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|M [1..1]
|O [0..1]
|O [0..1]
|-
|
|
|Expositionsrisiko Problem Entry (1.2.40.0.34.6.0.11.3.21)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
|External Document Entry (1.2.40.0.34.6.0.11.3.14)
|M [1..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="2" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|Author Body (1.2.40.0.34.6.0.11.9.36)
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Impfrelevante Erkrankungen - kodiert===
{| class="wikitable"
! colspan="5" style="width: 70%" |Sektion Impfrelevante Erkrankungen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="5" |SECTION Impfrelevante Erkrankungen - kodiert (1.2.40.0.34.6.0.11.2.5)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="4" |Impfrelevante Erkrankungen Problem Concern Entry (1.2.40.0.34.6.0.11.3.8)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
| colspan="3" |Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|M [1..1]
|O [0..1]
|O [0..1]
|-
|
|
| colspan="3" |Impfrelevante Erkrankungen Problem Entry (1.2.40.0.34.6.0.11.3.9)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
|
| colspan="2" |Comment Entry (1.2.40.0.34.6.0.11.3.11)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|
|
|Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|
|
|Informant Body (1.2.40.0.34.6.0.11.9.3)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
| colspan="3" |External Document Entry (1.2.40.0.34.6.0.11.3.14)
|M [1..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="4" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
| colspan="3" |Author Body (1.2.40.0.34.6.0.11.9.36)
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Antikörper-Bestimmung - kodiert===
{| class="wikitable"
! colspan="6" style="width: 70%" |Sektion Antikörper-Bestimmung
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="6" |SECTION Antikörper-Bestimmung - kodiert (1.2.40.0.34.6.0.11.2.7)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="5" |Antikörper-Bestimmung Data Processing Entry (1.2.40.0.34.6.0.11.3.15)
|R [1..*]
|R [1..*]
|R [1..*]
|-
|
|
| colspan="4" |Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|M [1..1]
|O [O..1]
|O [0..1]
|-
|
|
| colspan="4" |Antikörper-Bestimmung Battery Organizer (1.2.40.0.34.6.0.11.3.18)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
|
| colspan="3" |Antikörper-Bestimmung Laboratory Observation Entry (1.2.40.0.34.6.0.11.3.16)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|
|
| colspan="2" |Comment Entry (1.2.40.0.34.6.0.11.3.11)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|
|
|
|Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|
|
|
|Informant Body (1.2.40.0.34.6.0.11.9.3)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|
|
| colspan="2" |Participant (Validierende Person)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
|
|
| colspan="2" |Performer Body - Laboratory (1.2.40.0.34.6.0.11.9.28)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
| colspan="4" |External Document Entry (1.2.40.0.34.6.0.11.3.14)
|M [1..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="5" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
| colspan="4" |Author Body (1.2.40.0.34.6.0.11.9.36)
|O [0..*]
|O [0..*]
|O [0..*]
|}

===Sektion Impfempfehlungen - kodiert===
{| class="wikitable"
! colspan="4" style="width: 70%" |Sektion Impfempfehlungen
! style="width: 10%" |Kompletter I.
! style="width: 10%" |Update I.
! style="width: 10%" |Update I.
Nachtrag
|-
| colspan="4" |SECTION Impfempfehlungen - kodiert (1.2.40.0.34.6.0.11.2.2)
|R [1..1]
|O [0..1]
|O [0..1]
|-
|
| colspan="3" |Immunization Recommendation Entry (1.2.40.0.34.6.0.11.3.3)
|R [1..*]
|R [1..*]
|R [1..*]
|-
|
|
| colspan="2" |#) Vaccine Product (1.2.40.0.34.6.0.11.9.32)
|C [1..1]
|C [1..1]
|C [1..1]
|-
|
|
| colspan="2" |#) Vaccine Product nicht angegeben (1.2.40.0.34.6.0.11.9.31)
|C [1..1]
|C [1..1]
|C [1..1]
|-
|
|
| colspan="2" |Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
|
| colspan="2" |Immunization Target Entry (1.2.40.0.34.6.0.11.3.2)
|M [1..*]
|M [1..*]
|M [1..*]
|-
|
|
| colspan="2" |Comment Entry (1.2.40.0.34.6.0.11.3.11)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|
|Author Body - eImpfpass (1.2.40.0.34.6.0.11.9.8)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
|
|Informant Body (1.2.40.0.34.6.0.11.9.3)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
| colspan="2" |Impfplan Entry (1.2.40.0.34.6.0.11.3.22)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
| colspan="2" |External Document Entry (1.2.40.0.34.6.0.11.3.14)
|O [0..1]
|O [0..1]
|O [0..1]
|-
|
|
| colspan="2" |Immunization Schedule Entry (1.2.40.0.34.6.0.11.3.10)
|M [1..1]
|M [1..1]
|M [1..1]
|-
|
| colspan="3" |SECTION Übersetzung (1.2.40.0.34.6.0.11.2.8)
|O [0..*]
|O [0..*]
|O [0..*]
|-
|
|
| colspan="2" |Author Body (1.2.40.0.34.6.0.11.9.36)
|O [0..*]
|O [0..*]
|O [0..*]
|}

==CDA Templates==

===Document Level Templates===
====Kompletter Immunisierungsstatus====
{{:1.2.40.0.34.6.0.11.0.4/dynamic}}
====Update Immunisierungsstatus====
{{:1.2.40.0.34.6.0.11.0.2/dynamic}}

===Header Level Templates===
==== Document Realm ====
{{:1.2.40.0.34.6.0.11.1.10/dynamic}}
====Document TypeId====
{{:1.2.40.0.34.6.0.11.1.30/dynamic}}
==== Document Id ====
{{:1.2.40.0.34.6.0.11.1.1/dynamic}}
==== Document Effective Time ====
{{:1.2.40.0.34.6.0.11.1.11/dynamic}}
==== Document Confidentiality Code ====
{{:1.2.40.0.34.6.0.11.1.12/dynamic}}
==== Document Language ====
{{:1.2.40.0.34.6.0.11.1.13/dynamic}}
==== Document Set Id and Version Number ====
{{:1.2.40.0.34.6.0.11.1.15/dynamic}}
====Record Target - e-Impfpass====
{{:1.2.40.0.34.6.0.11.1.31/dynamic}}
====Author====
{{:1.2.40.0.34.6.0.11.1.2/dynamic}}
==== Data Enterer====
{{:1.2.40.0.34.6.0.11.1.22/dynamic}}
====Custodian====
{{:1.2.40.0.34.6.0.11.1.4/dynamic}}
====Legal Authenticator====
{{:1.2.40.0.34.6.0.11.1.5/dynamic}}
==== Information Recipient ====
Wird nicht verwendet.
====Participant ====
Folgende Participants werden nicht verwendet:
*Ein-, Ueber-, Zuweisender Arzt
*Hausarzt
*Auskunftsberechtigte Person (Notfallkontakt)
*Angehörige
*Versicherung
*Wird nicht verwendet.
*Betreuungsorganisation
*Weitere Behandler
====In Fulfillment Of ====
Wird nicht verwendet.
====Documentation Of Service Event - e-Impfpass ====
{{:1.2.40.0.34.6.0.11.1.32/dynamic}}

====Document Replacement - Related Document ====
{{:1.2.40.0.34.6.0.11.1.14/dynamic}}
====Authorization ====
Wird nicht verwendet.
====Component Of - Encompassing Encounter ====
{{:1.2.40.0.34.6.0.11.1.7/static-2019-03-07T104449}}

====Encounter Location====
{{:1.2.40.0.34.6.0.11.1.8/static-2019-03-07T111321}}

===Section Level Templates===
====Impfungen - kodiert====
{{:1.2.40.0.34.6.0.11.2.1/dynamic}}
====Expositionsrisiko Personengruppen - kodiert ====
{{:1.2.40.0.34.6.0.11.2.4/dynamic}}

====Impfrelevante Erkrankungen - kodiert====
{{:1.2.40.0.34.6.0.11.2.5/dynamic}}
====Antikörper-Bestimmung====
{{:1.2.40.0.34.6.0.11.2.7/dynamic}}
====Impfempfehlungen - kodiert====
{{:1.2.40.0.34.6.0.11.2.2/dynamic}}
====Übersetzung (informativ)====
{{:1.2.40.0.34.6.0.11.2.8/dynamic}}

===Entry Level Template===
====Comment Entry====
{{:1.2.40.0.34.6.0.11.3.11/dynamic}}
====Eingebettetes Objekt Entry====
{{:1.2.40.0.34.6.0.11.3.19/dynamic}}
==== Expositionsrisiko Problem Concern Entry====
{{:1.2.40.0.34.6.0.11.3.20/dynamic}}
==== Expositionsrisiko Problem Entry====
{{:1.2.40.0.34.6.0.11.3.21/dynamic}}
====External Document Entry ====
{{:1.2.40.0.34.6.0.11.3.14/dynamic}}
====Immunization Billability Entry ====
{{:1.2.40.0.34.6.0.11.3.5/dynamic}}
====Immunization Entry====
{{:1.2.40.0.34.6.0.11.3.1/dynamic}}
====Immunization Entry Impfung nicht angegeben====
{{:1.2.40.0.34.6.0.11.3.28/dynamic}}
====Immunization Recommendation Entry ====
{{:1.2.40.0.34.6.0.11.3.3/dynamic}}
====Immunization Schedule Entry ====
{{:1.2.40.0.34.6.0.11.3.10/dynamic}}
====Immunization Target Entry====
{{:1.2.40.0.34.6.0.11.3.2/dynamic}}

====Impfplan Entry====
{{:1.2.40.0.34.6.0.11.3.22/dynamic}}
====Impfrelevante Erkrankungen Problem Concern Entry ====
{{:1.2.40.0.34.6.0.11.3.8/dynamic}}
====Impfrelevante Erkrankungen Problem Entry====
{{:1.2.40.0.34.6.0.11.3.9/dynamic}}
====Antikörper-Bestimmung Data Processing Entry ====
{{:1.2.40.0.34.6.0.11.3.15/dynamic}}
====Antikörper-Bestimmung Battery Organizer====
{{:1.2.40.0.34.6.0.11.3.18/dynamic}}
====Antikörper-Bestimmung Laboratory Observation Entry ====
{{:1.2.40.0.34.6.0.11.3.16/dynamic}}
====Vaccine Product ====
{{:1.2.40.0.34.6.0.11.9.32/dynamic}}
====Vaccine Product nicht angegeben ====
{{:1.2.40.0.34.6.0.11.9.31/dynamic}}
====Problem Bedenken Entry====
{{:1.2.40.0.34.6.0.11.3.9/dynamic}}
===Weitere CDA Fragmente ===
====Address Compilation====
{{:1.2.40.0.34.6.0.11.9.25/dynamic}}
====Address Compilation Minimal====
{{:1.2.40.0.34.6.0.11.9.10/dynamic}}
====Assigned Entity====
{{:1.2.40.0.34.6.0.11.9.22/dynamic}}
====Assigned Entity Body====
{{:1.2.40.0.34.6.0.11.9.16/dynamic}}
====Assigned Entity Body with name, addr and telecom====
{{:1.2.40.0.34.6.0.11.9.29/dynamic}}

====Author Body - eImpfpass====
{{:1.2.40.0.34.6.0.11.9.8/dynamic}}

====Author Body ====
{{:1.2.40.0.34.6.0.11.9.36/dynamic}}

====Original Text Reference====
{{:1.2.40.0.34.6.0.11.9.2/dynamic}}
====Performer Body - Laboratory====
{{:1.2.40.0.34.6.0.11.9.28/dynamic}}
====Device Compilation====
{{:1.2.40.0.34.6.0.11.9.18/dynamic}}
====Informant Body====
{{:1.2.40.0.34.6.0.11.9.3/dynamic}}
====Participant Body - Transcriber ====
{{:1.2.40.0.34.6.0.11.9.14/dynamic}}
====Narrative Text Reference====
{{:1.2.40.0.34.6.0.11.9.1/dynamic}}
====Organization Compilation with name====
{{:1.2.40.0.34.6.0.11.9.9/dynamic}}
====Organization Compilation with id, name====
{{:1.2.40.0.34.6.0.11.9.5/dynamic}}
====Organization Compilation with id, name, tel, addr====
{{:1.2.40.0.34.6.0.11.9.7/dynamic}}
====Organization Name Compilation ====
{{:1.2.40.0.34.6.0.11.9.27/dynamic}}
====Organization Compilation with name, addr minimal ====
{{:1.2.40.0.34.6.0.11.9.20/dynamic}}
====Original Text Reference====
{{:1.2.40.0.34.6.0.11.9.2/dynamic}}

====Performer Body - Impfende Person====
{{:1.2.40.0.34.6.0.11.9.21/dynamic}}
====Person Name Compilation G1====
{{:1.2.40.0.34.6.0.11.9.26/dynamic}}
====Person Name Compilation G1 M====
{{:1.2.40.0.34.6.0.11.9.12/dynamic}}
====Person Name Compilation G2====
{{:1.2.40.0.34.6.0.11.9.6/dynamic}}
====Person Name Compilation G2 M====
{{:1.2.40.0.34.6.0.11.9.11/dynamic}}
====Time Interval Information minimal====
{{:1.2.40.0.34.6.0.11.9.15/dynamic}}
====Date Interval Information minimal====
{{:1.2.40.0.34.6.0.11.9.35/dynamic}}
</div class="landscape">
==Terminologien==
Die für den kompletten Immunisierungsstatus und für das Update erforderlichen Terminologien sind im Folgenden aufgelistet.

====eImpf_Antikoerperbestimmung_VS==== {{:1.2.40.0.34.6.0.10.13/dynamic}}
====eImpf_HistorischeImpfstoffe_VS==== {{:1.2.40.0.34.6.0.10.10/dynamic}}
====eImpf_ImmunizationTarget_VS==== {{:1.2.40.0.34.6.0.10.4/dynamic}}
====eImpf_Impfdosis_VS==== {{:1.2.40.0.34.6.0.10.6/dynamic}}
====eImpf_Impfgrund_VS==== {{:1.2.40.0.34.6.0.10.7/dynamic}}
====eImpf_ImpfrelevanteErkankungen_VS==== {{:1.2.40.0.34.6.0.10.2/dynamic}}
====eImpf_Impfrollen_VS==== {{:1.2.40.0.34.6.0.10.11/dynamic}}
====eImpf_Impfschema_VS==== {{:1.2.40.0.34.6.0.10.5/dynamic}}
====eImpf_Impfstoffe_VS==== {{:1.2.40.0.34.6.0.10.14/dynamic}}
====eImpf_SpecialCaseVaccination_VS==== {{:1.2.40.0.34.6.0.10.3/dynamic}}
====eImpf_SpecialSituationIndication_VS==== {{:1.2.40.0.34.6.0.10.15/dynamic}}
====ELGA_AdministrativeGender==== {{:1.2.40.0.34.10.4/dynamic}}
====ELGA_AuthorSpeciality==== {{:1.2.40.0.34.10.6/dynamic}}
====ELGA_EntityNameUse==== {{:1.2.40.0.34.10.27/dynamic}}
====ELGA_MedikationMengenart_VS====
Gültige UCUM-Einheit, siehe Terminologieserver.
Beispiele:
* <nowiki>{Stueck}</nowiki> oder <nowiki>{Packung}</nowiki> - vollständige Verabreichung einer Fertigspritze
* <nowiki>ml</nowiki> - für eine abweichende Dosis angegeben in Volumseinheiten
====ELGA_ObservationInterpretation====
Für die Antikörperbestimmung (Impftiter) im e-Impfpass kommen die Werte aus dem Knoten ''_ObservationInterpretationDetection'' zum Einsatz.
{{:1.2.40.0.34.10.13/dynamic}}
====ELGA_PersonalRelationship==== {{:1.2.40.0.34.10.17/dynamic}}
====ELGA_ServiceEventPerformer==== {{:1.2.40.0.34.10.43/dynamic}}
====ELGA_TelecomAddressUse==== {{:1.2.40.0.34.10.36/dynamic}}
====ELGA_URLScheme==== {{:1.2.40.0.34.10.25/dynamic}}
====ELGA_whoATC==== {{:1.2.40.0.34.10.27/dynamic}}
</div>



<div class="portrait">
=Anhang=
==Abbildungen==
<references group="Abbildung"/>
==Tabellen==
<references group="Tabelle" />
==Abkürzungsverzeichnis==
{{ILF:Abkuerzungsverzeichnis}}

==Literaturverzeichnis==
<references />
</div>

==Revisionsliste==
{| class="wikitable"
|Schlüssel
|Zusammenfassung
|<nowiki>Typ</nowiki>
|-
|ELGA-734
|"External Document Entry" (1.2.40.0.34.6.0.11.3.14) / Dokumentenklassifikation: Einschränkung auf LOINC entfernt
|Verbesserung
|-
|ELGA-728
|"Informant Body" (1.2.40.0.34.6.0.11.9.3): addr: Ergänzung Compilation, telecom: Attribute, Ergänzung Value Sets und Constraint
|Verbesserung
|-
|ELGA-724
|"Immunization Recommendation Entry" ([[#Immunization_Recommendation_Entry|1.2.40.0.34.6.0.11.3.3]]): Kardinalität von Comment Entry (1.2.40.0.34.6.0.11.3.11) von 0..1 auf 0..* korrigiert, da mehrfach benötigt
|Fehler
|-
|ELGA-719
|In der Impfempfehlungslogik werden nicht einzelne Handelsprodukte mit PZN vorgeschlagen, sondern die Zulassungsnummer.

Es ist daher notwendig, dass es eine Möglichkeit gibt, die Zulassungsnummer alleine im Template "Vaccine Product" (1.2.40.0.34.6.0.11.9.32) anzugeben:

/code mit der PZN von [M] zu [R] geändert, dabei MUSS NullFlavor="OTH" angeführt sein.

/code/translation darf mehrfach vorkommen und trägt die Zulassungsnummer.

|Fehler
|-
|ELGA-717
|"Immunization Recommendation Entry" (1.2.40.0.34.6.0.11.3.3): Optionalität von code/@displayName und code/@codeSystemName
entspricht den Datentyp-Vorgaben für CD und wird daher nicht redundant modelliert. Daher entfernt.
|Verbesserung
|-
|ELGA-716
|Beschreibung wie mit passiver Immunisierung umgegangen wird hinzugefügt
|Verbesserung
|-
|ELGA-715
|"Antikörper-Bestimmung Laboratory Observation Entry" (1.2.40.0.34.6.0.11.3.16): ReferenceRange Datentyp geändert
|Fehler
|-
|
|Kapitel "Wichtige unterstützende Materialien" wurde umbenannt in "Wichtige unterstützende Materialien" und ergänzt mit Link zu Beispielbefunden, Schematron-Prüfregeln, PDF-Version des Leitfadens
|Verbesserung
|-
|
|Dataset-Elemente des Headers wurden in den Templates referenziert/gemappt (rein informativ).
|Verbesserung
|-
|
|"Expositionsrisiko Personengruppen - kodiert" (1.2.40.0.34.6.0.11.2.4):
- ID der Sektion: Kardinalität von 0..* auf 0..1 geändert

- Titel der Sektion wurde von "Expositionsrisiko - Personengruppen" auf "Spezielle Impfindikation" geändert
|Fehler
|-
|
|"Impfrelevante Erkrankungen - kodiert" (1.2.40.0.34.6.0.11.2.5) / id: Kardinalität von 0..* auf 0..1 geändert
|Fehler
|-
|
|"Übersetzung (informativ)" (1.2.40.0.34.6.0.11.2.8): Containment "Author Body - eImpfpass" (1.2.40.0.34.6.0.11.9.8) geändert auf "Author Body" (1.2.40.0.34.6.0.11.9.36), "Author Body" im Leitfaden ergänzt
|Fehler
|-
|
|"Address Compilation" (1.2.40.0.34.6.0.11.9.25) und Address Compilation Minimal (1.2.40.0.34.6.0.11.9.10): Änderung streetAddressLine, streetName, houseNumber von 0..1 R auf 0..1 C, Constraint ergänzt
|Verbesserung
|-
|
|Schamatron Prüfregeln wurden in einigen Templates ergänzt. Diese waren aber bereits in entsprechenden Constraints beschrieben
|Verbesserung
|-
|
|Kapitel "Revisionsliste" ergänzt
|Verbesserung
|-
|
|"Immunization Schedule Entry" (1.2.40.0.34.6.0.11.3.10): Constraint angepasst
|Verbesserung
|-
|
|"Immunization Target Entry" (1.2.40.0.34.6.0.11.3.2): @codeSystem von 1..1 F 2.16.840.1.113883.6.96 auf 1..1 R geändert, @codeSystemName fixer Wert entfernt
|Verbesserung
|-
|
|"6.1.2 Legende der Konformitätskriterien (Optionalität)" Verbesserte Beschreibung.
|Verbesserung
|-
|
|"9.6 U4 Datenkorrektur durch Behörde" - Wording angepasst um keinen physischen Amtsweg zu implizieren, "Bezirksverwaltungsbehörde" statt "Bezirkshauptmannschaft".
|Verbesserung
|}

ILF:XDS Metadaten (Version 3)

2021-03-26T07:56:17Z

Kuttin: /* Spezifikation */

{{#seo:
|title=XDS Metadaten 3.0.0
|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 (Version 3.0.0)}}



{{#css:
@media screen{
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.toc{
width: 20%;
float: right !important;
margin: 10px 0px 10px 30px !important;
border: 1px solid #AAA;
background-color: #F9F9F9;
display: table;
padding: 7px !important;
}
}
}}

{{Infobox Dokument
|Group = ELGA CDA Implementierungsleitfäden
|Title = ELGA XDS Metadaten (XDSDocumentEntry)
|Subtitle = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA [1.2.40.0.34.7.6.9.3]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0+20210324
|Submitted = ELGA GmbH
|Date = März 2021
|Copyright = 2011-
|Status = Reconciliation
|Period = n.a.
|OID = 1.2.40.0.34.7.6.9.3
|Realm = Austria
}}

{{TOC limit|4}}



{{#css:
.orange{
border: thin black solid;
background-color:#F4C789;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
}
}}

=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;">
==Impressum==
<div class="mw-collapsible-content">
''Medieneigentümer, Herausgeber, Hersteller, Verleger:'' 
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050 
Internet: [http://www.elga.gv.at www.elga.gv.at]
Email: [mailto:cda@elga.gv.at cda@elga.gv.at] 
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch

''Redaktion, Projektleitung, Koordination: '' 
Mag.Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]

''Abbildungen:'' Sofern nicht anders angegeben: © ELGA GmbH

''Nutzung'': Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria [http://www.hl7.at www.hl7.at]. 
Die Nutzung ist ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter [https://www.gesundheit.gv.at www.gesundheit.gv.at] und [https://www.elga.gv.at/cda www.elga.gv.at/cda]
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

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

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

==Sprachliche Gleichbehandlung==
<div class="mw-collapsible-content">
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer, Frauen und andere Geschlechtsidentitäten in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
</div></div>

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

Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> .

===Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")===
<div style="border: thin #77c123 solid;width:100%; margin-left: 10px">
<div style="line-height: 1.25; font-size:16px; border-bottom: 1px solid #81ab1f; box-shadow: 0 4px 0 0 #a2d727;margin-bottom:4px; color:#77c123; width:100%">
Third Party Intellectual Property
</div>
<div style="width:100%;">


Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass der Herausgeber nicht alle Rechte und Ansprüche in und an den Materialien besitzt und dass die Materialien geistiges Eigentum von Dritten enthalten und / oder darauf verweisen können ("Third Party Intellectual Property (IP)"). 

Die Anerkennung dieser Lizenzbestimmungen gewährt dem Lizenznehmer keine Rechte in Bezug auf Third Party IP. Der Lizenznehmer allein ist für die Identifizierung und den Erhalt von notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig verantwortlich. 

Jegliche Handlungen, Ansprüche oder Klagen eines Dritten, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, bleiben die Haftung des Lizenznehmers.

</div>
</div>

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

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

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

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

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

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

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website: [[ILF: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 ([http://www.elga.gv.at/CDA Website der ELGA GmbH]) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:

*ELGA-Gesamtarchitektur<ref name="ELGA-Gesamtarchitektur">ELGA-Gesamtarchitektur 2.30a [http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>
*Beispieldokumente
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
*CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
*Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
*Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
*Hinweise für die zu verwendenden Terminologien
*Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}

==Bedienungshinweise==
===Farbliche Hervorhebungen===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''<Hinweis>''' authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
{{EndYellowBox}}
''Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>
''Verweis auf ELGA Value Set:''
{{BeginILFBox}}
'''<Verweis>''' Zulässige Werte gemäß Value Set '''"ELGA_FormatCode".'''
{{EndILFBox}}

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

===PDF-Navigation===
<div class="mw-collapsible-content">
Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

*Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
*Seitenweise blättern: "Bild" Tasten
*Scrollen: Pfeil nach oben bzw. unten
*Zoomen: Strg + Mouserad drehen
*Suchen im Dokument: Strg + F
</div></div>



=Harmonisierung=
'''Erarbeitung des Implementierungsleitfadens''' 
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%" |Person1
|- 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
|}

1 Namen ohne Titel


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

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.

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

==Hinweise zur Verwendung des Dokuments==
===Codesysteme und Value Sets===
Die in diesem Dokument erwähnten Codesysteme bzw. Value Sets werden am Terminologieserver (https://www.gesundheit.gv.at/gesundheitssystem/professional/it-services/terminologieserver-doku) und auf der Website der ELGA GmbH (http://www.elga.gv.at) veröffentlicht.

Wenn codierte Werte angegeben werden, ist es immer die Aufgabe des Document Consumers, die korrekten lesbaren Werte anzuzeigen. Es wird nicht empfohlen, die in den XDS-Metadaten verfügbaren DisplayNames direkt zur Anzeige zur verwenden, da Schreibweisen der DisplayNames variieren oder in unterschiedlichen Sprachen angegeben sein können.

===OID ===
In diesem Dokument wird an vielen Stellen die Verwendung von OID vorgeschrieben. OID sind Objekt-Identifikatoren oder Objektkennungen, die als weltweit eindeutige Namen für Informationsobjekte dienen (ISO/IEC 9834-1). Weitere Informationen zur Verwendung und Registrierung von OID sind im "OID-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.

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

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

====Bereitstellen [ITI-41] und Veröffentlichen [ITI-42]====
Ein neues Dokument wird entsprechend IHE XDS im Repository gespeichert und durch Registrieren der XDS-Metadaten in der Registry für ELGA bereitgestellt. Neu veröffentlichte Dokument-Metadaten werden immer mit dem Status "approved" versehen.

====Ersetzen eines Dokuments durch eine neue Version ("Updaten") [ITI-41]====
Änderungen eines für ELGA bereitgestellten Dokumentes sind NICHT ERLAUBT.

Es ist allerdings möglich, ein Dokument durch ein anderes zu ersetzen, indem ein neues Dokument (bzw. eine neue Version des Dokumentes) gespeichert und registriert wird. Hierbei MUSS die SetId der referenceIdList in den XDS-Metadaten zum neuen Dokument der der Vorgängerversion entsprechen. Die XDS-Metadaten der Vorgängerversion des Dokumentes bekommen den Status "deprecated". In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp "replace" (RPLC)).

Beim Ersetzen von ELGA Dokumenten wird das ELGA Berechtigungssystem eventuell zugeordnete individuelle Zugriffsberechtigungen unabhängig von ihrer Anzahl auch auf die Nachfolgeversionen anwenden.

====Stornieren [ITI-57, XDS Metadata Update]====
Dokumente werden "storniert", indem der Dokumentstatus auf "deprecated" gesetzt wird und keine neue Dokumentenversion registriert wird.

===Größenbeschränkung ===
ELGA schreibt für die Größe der eingebrachten CDA eine Maximalgröße von 20 MB vor. Größere Dokumente sind abzulehnen. Es liegt generell in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten |Allgemeiner Implementierungsleitfaden
für ELGA CDA Dokumente, Kapitel 6.10]].

==Allgemeines zu XDS-Metadaten==
Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumente entsprechend klassifiziert und beschrieben werden. Diese beschreibenden "Metadaten" werden in Form einer Nachricht gemeinsam mit dem Dokument an das Repository mitgegeben. Da IHE XDS Systeme grundsätzlich für beliebige Dokumentformate offen sind, gilt dies für alle Arten von Dokumenten (CDA, PDF, Bilder, etc.) gleichermaßen.

Die Metadaten eines Dokuments (XDSDocumentEntry) in einem IHE XDS System beinhalten Informationen
* über das Dokument selbst – um eine Klassifizierung und eine korrekte Darstellung des Dokumenteninhalts zu ermöglichen
* über eventuelle Beziehungen zu anderen Dokumenten (z.B. zu älteren Versionen eines Dokuments)
* über den Speicherort des Dokuments
* über den GDA, welcher das Dokument erstellt hat
* über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).
Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE "IT-Infrastructure" (ITI) Technical Framework, Volume 3 festgelegt (IHE ITI TF-3)<ref name="ITITF3"/>.

Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.
{{BeginYellowBox}}
Die Metadaten sind die ausschließliche Grundlage für das Suchen und Filtern von Dokumenten in einem XDS Dokumentenregister und somit im ELGA Verweisregister, daher ist die korrekte Verschlagwortung der Dokumente mit den Metadaten eine notwendige Voraussetzung.
{{EndYellowBox}}

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

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

===Metadaten aus strukturierten Dokumenten (CDA)===
Strukturierte Dokumente bieten die Möglichkeit, die Informationen für die Metadaten beim Einbringen in ein Repository in gewissem Maße aus den Dokumenten selbst automatisiert zu entnehmen. Das vermindert daher die Menge der Informationen, die separat erhoben oder ermittelt werden muss.

Die IHE hat im Rahmen des "Patient Care Coordination" (PCC) Technical Frameworks eine genaue Vorschrift spezifiziert, aus welchen Bereichen des CDA Dokuments die Metadaten entnommen werden sollen.

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

===Metadaten aus "On-Demand Documents" (ODD) ===
Ü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"/>.

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

===XDS Metadaten im Vergleich IHE vs. ELGA===
Die vollständige Liste der XDS Metadaten Elemente kann man in folgende Arten von Elementen unterteilen:
# Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
# Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)
# '''Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können (XDS Document Source)'''
# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
## '''ELGA relevante'''
## Nicht ELGA relevante
Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).

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

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

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

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

{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|K||Aus KOS-Inhalt abgeleitet
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- style="background:#white"
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
|}

''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" |'''Metadaten Element'''
|'''Optionalität'''
|'''Quelle'''
|'''Beschreibung'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''M [1..1]'''
|<nowiki>-</nowiki>
|Die Person oder das Gerät, welche(s) das Dokument verfasst hat
|-
| rowspan="4" |
|authorInstitution
|'''M [1..1]'''
|E1/K
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|-
|authorPerson
|'''R [0..1]'''
|K
|Daten der Person

(Name, ID, etc.)
|-
|authorRole
|'''R [0..1]'''
|K
|Rolle der Person
|-
|authorSpeciality
|'''R [0..1]'''
|E1/K
|Fachrichtung der Person
|-
| colspan="2" |'''classCode'''
|'''M [1..1]'''
|A
|Dokumenten/Objektklasse (Oberklasse)

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

codierter Wert
|-
| colspan="2" |'''uniqueId'''
|'''M [1..1]'''
|K
|Global eindeutige ID des Objektes

z.B. SOP Instance UID
|-
| colspan="2" |'''referenceIdList'''
|'''M [1..*]'''
|K/E1
|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|-
| colspan="5" |'''''Explizit zu setzende Metadaten'''''
|-
| colspan="2" |'''availabilityStatus'''
|'''M [1..1]'''
|E1
|Gültigkeit des Objektes
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|E1
|Format des Objektes
|-
| colspan="2" |'''healthcareFacilityTypeCode'''
|'''M [1..1]'''
|E1
|Klassifizierung des GDA
|-
| colspan="2" |'''mimeType'''
|'''M [1..1]'''
|E1
|Mime Type des Dokuments

Fester Wert für KOS: "application/dicom"
|-
| colspan="2" |'''parentDocumentId'''
|'''O [0..1]'''
|E1
|Verweis auf ein referenziertes Objekt
|-
| colspan="2" |'''parentDocumentRelationship'''
|'''O [0..1]'''
|E1
|Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC, XFRM
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|E1
|Fachliche Zuordnung des Dokuments
|-
| colspan="2" |'''entryUUID'''
|'''M [1..1]'''
|E1
|UUID des Metadaten-Records des Dokuments(XDS DocumentEntry)
|-
| colspan="2" |'''objectType'''
|'''M [1..1]'''
|E1
|Typ des DocumentEntries

Fester Wert "SD"
|-
| colspan="2" |'''comments'''
|'''O [0..1]'''
|K
|Kommentar zum Dokument/Objekt
|-
| colspan="2" |'''patientId'''
|'''M [1..1]'''
|E1
|Patienten-ID in der XDS Affinity Domain
|-
| colspan="5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|-
| colspan="2" |'''hash'''
|'''M [1..1]'''
|A
|Hash Wert des Dokuments. Wird vom Repository befüllt
|-
| colspan="2" |'''homeCommunityId'''
|'''M [1..1]'''
|A
|Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.
|-
| colspan="2" |'''repositoryUniqueId'''
|'''M [1..1]'''
|A
|Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
|-
| colspan="2" |'''size'''
|'''M [1..1]'''
|A
|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository befüllt.
 
|-
| colspan="2" |'''URI'''
|'''NP [0..0]'''[[#%20ftn1|<nowiki/>]][[#%20ftn1|<nowiki/>]]
|A
|Wird in XDS-I nicht verwendet
|-
|-
| colspan="5" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|-
| colspan="2" |'''elgaFlag'''
|'''M [1..1]'''
|B
|Kennzeichnet ein Dokument als "ELGA-Dokument"
|-
| colspan="2" |'''elgaHash'''
|'''M [1..1]'''
|B
|Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes
|}
 [[#%20ftn1|<nowiki/>]]

 


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

In der Tabelle 6 werden die XDS-Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität), jeweils für Stable Documents (SD) und On-Demand-Documents (ODD) angegeben.

''Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|C||Aus CDA-Inhalt abgeleitet (direkt oder indirekt, gilt nicht für On-Demand-Documents)
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- 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="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 6: Überblick XDS Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''
| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''
| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
| rowspan="2" style="text-align:left" |'''Beschreibung '''
|- style="background:#CBD7F1"
|'''SD'''9||'''ODD'''10
|- style="background:#CBD7F1"
| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''
|- style="background:white"
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''M [1..1]'''||'''M [1..1]'''
|C||Die Person, welche das Dokument verfasst hat
|- style="background:white"
| ||authorInstitution||'''M [1..1]'''||'''M [1..1]'''
|C||ID und Name der Organisation (Kurzbezeichnung), der die Person angehört, wie im GDA-Index angegeben.
|- style="background:white"
| ||authorPerson||'''M [1..1]'''||'''M [1..1]'''
|C||Daten der Person (Name, ID, etc.)
|- style="background:white"
| ||authorRole||'''R [0..1]'''||'''NP [0..0]'''
|C||Rolle der Person
|- style="background:white"
| ||authorSpeciality||'''R [0..1]'''||'''NP [0..0]'''
|C||Fachrichtung der Person
|- style="background:white"
| colspan="2" |'''classCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Vertraulichkeitscode des Dokuments
|- style="background:white"
| colspan="2" |'''creationTime'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R [0..*]'''||'''R [0..*]'''
|C||Liste von Gesundheitsdienstleistungen
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Format des Dokumenteninhalts
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O [0..1]'''||'''NP [0..0]'''
|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.
|- style="background:white"
| colspan="2" |'''languageCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Sprachcode des Dokuments z.B.: "de-AT"
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R [0..1]'''||'''NP [0..0]'''
|C||Rechtlicher Unterzeichner des Dokuments
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Fachliche Zuordnung des Dokuments
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''NP [0..0]'''||'''NP [0..0]'''
|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)
|- style="background:white"
| colspan="2" |'''Title'''||'''M [1..1]'''||'''M [1..1]'''
|C||Titel des Dokuments
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Global eindeutige ID des Dokuments
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''M [1..1]'''||'''O [0..1]'''
|C||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''M [1..1]'''||'''M [1..1]'''
|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 z.B.: "text/xml" für CDA
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O [0..1]'''||'''O [0..1]'''
|E1||Verweis auf ein referenziertes Dokument
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O [0..1]'''||'''O [0..1]'''
|E1||Typ der Relation zu dem referenzierten Dokument. 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
|}

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

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

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

''Tabelle 7: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" |'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

'''der Studie'''
|'''Attribut'''

'''im KOS'''
|'''Beschreibung'''
|- style="background:white"
| colspan="2" |author
|M [1..1]
| colspan="3" |
|- style="background:white"
| rowspan="6" |
|author.authorInstitution
|M [1..1]
|(0008,0080)
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

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

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

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

'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
|- style="background:white"
| colspan="5" |Die Person, welche die Studie durchführt, ist als author anzugeben:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,1052)
|
|Performing Physicians Identification Sequence

Code und weitere Daten aus dem ersten Item in der Sequence

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

(0008,1050)
|
|Performing Physicians Name

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

'''Achtung:''' Die Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
|- style="background:white"
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,0060) + (0008,0070) + (0008,1090)
|
|Modality Code + Manufacturer + Manufacturer's Model Name

'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
|- style="background:white"
| colspan="2" |creationTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date + Study Time

Für den Fall, dass Study Date und Study Time nicht zur Verfügung stehen, ist es zulässig, den Erstellungszeitpunkt des KOS ((0008,0023) contentDate + (0008,0033) contentTime) als creationTime zu verwenden.
|- style="background:white"
| colspan="2" |eventCodeList
|M [1..*]
|
|
|Enthält eine Liste von Codes von Gesundheitsdienstleistungen nach APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten<nowiki/>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</ref>
|- style="background:white"
|
|eventCodeList DisplayNameList
|M [1..1]
|
|
|Enthält den Display Name des APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom" />
|- style="background:white"
| colspan="2" |serviceStartTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|- style="background:white"
| colspan="2" |sourcePatientId
|M [1..1]
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|- style="background:white"
| colspan="2" |sourcePatientInfo
|M [1..1]
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|Die ELGA Vorgabe empfiehlt, Name, Geburtstag und Geschlecht NICHT anzugeben.
|- style="background:white"
| colspan="2" |title
|M [1..1]
|(0008,0060) + (0008,1030)
|
|Der relevante Modality Code der Studie oder alle Modality Codes der Studie und die Study Description.

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

'''Anmerkung:'''

Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
 
|- style="background:white"
| colspan="2" |uniqueId
|M [1..1]
|
|(0008,0018)
|Die SOP Instance UID des KOS
|- style="background:white"
| colspan="2" |referenceIdList
|M [1..1]
|
|
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|- style="background:white"
| rowspan="2" |
|value mit CXi.5 = "<nowiki>urn:elga:iti:xds:2014: OwnDocument_setId</nowiki>"
|M [1..1]
|(0020,000D) oder ein vergleichbares Attribut
|(0020,000D) oder ein vergleichbares Attribut
|Die setId zur Klammerung aller Versionen eines KOS

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

Eine mögliche Wahl der setId ist die Study Instance UID. Die geeignete Wahl der setId hängt auch vom implementierten Stornoworkflow ab, siehe KOS Leitfaden (Kapitel 8.2.2.)<ref name="KOS-Leitfaden" />
|- style="background:white"
|value mit CXi.5 = "<nowiki>urn:ihe:iti:xds:2013: accession</nowiki>"
|R [0..1]
|(0008,0050) oder ein vergleichbares Attribut wie z.B.

(0040,1001) Requested Procedure ID
 
|(0008,0050)
 
|Die ID, die zur Verlinkung mit dem Befund heranzuziehen ist.

Diese ist mit dem Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' anzugeben.

'''Achtung:'''

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

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

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

Unabhängig von der Wahl des DICOM Attributs ist aber in jedem Fall der Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' zu verwenden.
|- style="background:white"
| colspan="2" |comments
|O [0..1]
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

===author===
Die Person oder Maschine, die das Dokument erstellt hat. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.

Die ''authorInstitution'' benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden können. Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.

*''oid'': OID der Organisation aus dem GDA-Index (muss ermittelt werden)
*''name'': (0008,0080), Institution Name, Name der Organisation als String,
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden. 

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

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

=====Spezifikation=====

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

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

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

concat( 
$name,"^^^^^^^^^", 
$oid,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

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

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

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

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

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

=====Spezifikation für Personen=====

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

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

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

$person = (0008,1050) Performing Physicians Name

$root = OID-Knoten für den Personenidentifikator

concat( 
 $id,"^", 
 $person,"^", 
 $root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>11375^Musterdoc^Josef^Maria^Msc^DIDr^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>

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

concat( 
 $id,"^", 
 $person 
) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf die XCN Komponenten wie in IHE RAD TF-2 Rev.19 2020<ref name="IHERADTF2">IHE Radiology (RAD) Technical Framework Volume 2x Rev.19, 2020 [https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf]</ref>, "Table 4.68.4.1.2.3-3: XCN Data type mapping" vorgegeben.

=====Spezifikation für Software und Geräte=====

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

$Modality = Modality (0008,0060)

$Manufacturer = Manufacturer (0008,0070)

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

concat(

"^",

$Modality,"^",

$Manufacturer,"^",

$ManufacturersModelName

) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^CT^Geräthersteller^Gerätename</Value>
</ValueList>
</Slot>
</Classification></pre>

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

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

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

Beispiel:

*"Radiologie"
*"Modalität"

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

Beispiel:

*"Facharzt für Radiologie"
*"Facharzt für Nuklearmedizin"

=====Spezifikation=====

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

Bsp: Fachärztin/Facharzt für Radiologie 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Fachärztin/Facharzt für Radiologie</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Wenn eine Person als Autor vorhanden ist, '''MUSS''' der Wert einem DisplayName aus dem Value Set "ELGA_AuthorSpeciality" entsprechen.

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

{{EndYellowBox}}

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

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Objektklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Objektklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#typeCode_.28und_typeCodeDisplayName.29|typeCode]]
|}

====Spezifikation====

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

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

$code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
classifiedObject="theDocument" nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===confidentialityCode===
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.

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

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

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

====Spezifikation====

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

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

<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="theDocument" nodeRepresentation="N">
<Name>
<LocalizedString value="normal"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:2.16.840.1.113883.5.25</Value>
</ValueList>
</Slot>
</Classification></pre>

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

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

Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From ''UTC''<ref>Timezone Offset From UTC http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</ref> berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

====Spezifikation====

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

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

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

concat(

$date,

$time

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="creationTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.{{EndYellowBox}}

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

====Spezifikation====

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

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

$code = APPC code (alle Achsen) z.B. "2.4.0.5-3-3" 
$displayName = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule" 
$codeSystem = OID des Codesystems APPC: 1.2.40.0.34.5.38 
<pre class="ilfbox_code">
<Classification
classificationScheme=
"urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
classifiedObject="theDocument"
nodeRepresentation="$code">
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
<Name>
<LocalizedString value="$displayName"/>
</Name>
</Classification>
</pre>

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

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

Fester Wert "de-AT"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/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===
Dieses Element darf für XDS-I nicht verwendet werden [NP].

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

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

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

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

concat(

Study Date,

Study Time + Timezone Offset from UTC

)
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="serviceStartTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

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

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

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

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

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

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

$patientID = (0010,0020) Patient ID

$oid = OID des lokalen Patientenidentifikators

concat(

$patientID,

"^^^&amp;",

$oid,

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.
{{BeginYellowBox}}
In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
{{EndYellowBox}}

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

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

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modality Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. ("CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule")
{{BeginYellowBox}}
'''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
{{EndYellowBox}}
====Spezifikation====

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

concat(

Modality,

" ",

Study Description

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Name>
<LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" />
</Name>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
{{EndYellowBox}}

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

Unterscheidung typeCode/classCode:
{| class="wikitable"
|- style="background:white"
|'''typeCode'''
|'''Objektklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
|classCode
|Objektklasse in grober Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29|classCode]]
|}

====Spezifikation====

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

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

 $code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="KeyImageObject"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

$code = "55113-5"

$displayName = "Key images Document Radiology"

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

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

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

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

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

$value = (0008,0018) SOP Instance UID

<pre class="ilfbox_code">
<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. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:

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

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

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

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

{| 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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}
{{BeginYellowBox}}

'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.
{{EndYellowBox}}

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

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

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

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

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

concat

(

$id, "^^^^",

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

"&amp;",

$homeCommunityId, "&amp;ISO"

)

Wie oben angeführt wird folgender CXi Wert für <Value> erstellt:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.

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

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

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

$id = Accession Number z.B. 20201111

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

concat

(

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

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

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

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

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

$id = Aufenthaltszahl z.B. Az123456

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

concat

(

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

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

"<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>Az123456^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.4613.3.4<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>
</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

*'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki>. In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.
*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki>

Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId
</nowiki>^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
<Value>20201111^^^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
<Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value>
<Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===intendedRecipient===
Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der ''intendedRecipient'' notwendig. Derzeit wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.

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

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

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

====Spezifikation====
Comments wird gemäß folgender Vorschrift zusammengesetzt:
$comment = (0008,1030) Study Description<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Description">
<LocalizedString value = "$comment"/>
</Description>
</ExtrinsicObject>
</pre> 

==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
===availabilityStatus===
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Objektes.

Mögliche Werte laut IHE sind:

*Approved
*Deprecated

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

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

<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

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

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

===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA, z.B.

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

Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]".
{{EndYellowBox}}

====Spezifikation====

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

$code = Klassifizierung des GDA (Code)

$displayName = Klartext des angegebenen Codes

$codeSystem = OID der ausgebenden Stelle

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

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

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

====Spezifikation====

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

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

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

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

*F044 "Radiologie"
*F052 "Unfallchirurgie"

Im KOS-Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_PracticeSetting_VS ELGA_PracticeSetting_VS]".
{{EndYellowBox}}

====Spezifikation====

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

$code = Code aus Value Set ELGA_PracticeSetting $displayName = Klartext des angegebenen Codes (displayName) $codeSystem = OID des Codesystems (1.2.40.0.34.5.12) 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

Für KOS Objekte wird der fixe Wert "<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="application/dicom"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

==ELGA-spezifische Erweiterungen der XDS-Metadaten==
Die folgenden Daten entsprechen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information.

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

*"true" oder
*"false"

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

====Spezifikation====

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

===elgaHash===
Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot "ELGA-Hash" gespeichert.

Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.

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

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

==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).

CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen.

====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurde.

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

#Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört, grundsätzlich in folgendem Element abgelegt:
##ClinicalDocument/author/assignedAuthor/representedOrganization
#Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:
##'''id'''[1] … ID der Organisation mit den folgenden Attributen:
###@root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)
###@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)
##'''name''' … Name der Organisation als String Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.
#GDA, in deren Gültigkeitsbereich Dokumente erstellt werden können, sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da es vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden.
{{EndYellowBox}}

=====Spezifikation=====

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

$inst … ClinicalDocument/author/assignedAuthor/representedOrganization

*Fall 1: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist nicht vorhanden 

concat( 
$inst/name,"^^^^^^^^^", 
$inst/id[1]/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO</Value>
</ValueList>
</Slot>
</Classification>
</pre>

*Fall 2: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist vorhanden 

concat( 
$inst/name,"^^^^^&", 
$inst/id[1]/@root,"&ISO^^^^" 
$inst/id[1]/@extension 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&amp;ISO^^^^45</Value>
</ValueList>
</Slot>
</Classification>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

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

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

#Laut Festlegung wird der Autor im Header-Element "author" abgelegt:
##ClinicalDocument/author/assignedAuthor
#Der Autor (Person)
##Ein Personenelement enthält unter anderem die folgenden Unterelemente:
###id … ID der Person mit den folgenden Attributen:
####@root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
####@extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
###assignedPerson
####Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
#####name
#Gerät oder Software als Autor
##Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:
###assignedAuthoringDevice
####Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software
#####manufacturerModelName
####Enthält ein Element mit dem Namen des Geräts oder der Software
#####softwareName

=====Spezifikation für Personen=====

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

 $person = ClinicalDocument/author/assignedAuthor

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
{{BeginYellowBox}}
Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.
{{EndYellowBox}}
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

=====Spezifikation für Software und Geräte=====

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

 $person = ClinicalDocument/author/assignedAuthor

concat( 
"^", 
 $person/assignedAuthoringDevice/manufacturerModelName,"^", 
 $person/assignedAuthoringDevice/softwareName 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^Good Health System^Best Health Software Application</Value>
</ValueList>
</Slot>
</Classification></pre>

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

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.

Beispiel:

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

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

#Laut Festlegung wird die "Rolle" der Person, welche das Dokument inhaltlich erstellt hat, im Element functionCode des Autors abgelegt:
##''ClinicalDocument/author/functionCode''
#Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.

=====Spezifikation=====

'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/functionCode/@displayName 
<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorRole">
<ValueList>
<Value>Diensthabender Oberarzt</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.

Beispiel:

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

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

#Laut Festlegung wird die "Fachrichtung" der Person, welche das Dokument inhaltlich erstellt hat, im Element code des Autors abgelegt:
##''ClinicalDocument/author/assignedAuthor/code''
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.

=====Spezifikation=====

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

ClinicalDocument/author/assignedAuthor/code/@displayName 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Anästhesiologie und Intensivmedizin</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

===classCode (und classCodeDisplayName)===
Das ''classCode'' Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Dokumentenklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Dokumentenklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2|typeCode]]
|}

====Spezifikation====

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

$code = ClinicalDocument/code/translation/@code 
$displayName = ClinicalDocument/code/translation/@displayName 
$codeSystem = ClinicalDocument/code/translation/@codeSystem 
<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: 

<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.
Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

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

#Im CDA wird dieser Zeitpunkt wie folgt abgelegt:
##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:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
CreationTime entfällt bei On-Demand Documents.
{{EndYellowBox}}

====Spezifikation====

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 
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: 

Für jedes documentationOf Element 1..n: 

$code = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code 
$displayName = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName 
$codeSystem = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem 
<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: 

 $person = ClinicalDocument/legalAuthenticator/assignedEntity

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<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) Achtung: Diese ID gelangt nicht in die Metadaten!

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

 $code = ClinicalDocument/code/@code 
 $displayName = ClinicalDocument/code/@displayName 
 $codeSystem = ClinicalDocument/code/@codeSystem 
<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: 

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

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

Fall 2 
Attribut ClinicalDocument/id/@extension ist vorhanden

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

<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..1])
#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).

{{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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}

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

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

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

 

===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: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = ClinicalDocument/hl7at:formatCode/@displayName 
$codeSystem = 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:

$code = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code

$displayName = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName

$codeSystem = 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: 
CDA R2: '''text/xml''' 

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

$code = ClinicalDocument/hl7at:practiceSettingCode/@code 
$displayName = ClinicalDocument/hl7at:practiceSettingCode/@displayName 
$codeSystem = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem 
<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"18. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:

*"true" oder
*"false"
18 Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.
====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=

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

ILF:XDS Metadaten (Version 3)

2021-03-26T07:52:37Z

Kuttin: /* Spezifikation */

{{#seo:
|title=XDS Metadaten 3.0.0
|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 (Version 3.0.0)}}



{{#css:
@media screen{
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.toc{
width: 20%;
float: right !important;
margin: 10px 0px 10px 30px !important;
border: 1px solid #AAA;
background-color: #F9F9F9;
display: table;
padding: 7px !important;
}
}
}}

{{Infobox Dokument
|Group = ELGA CDA Implementierungsleitfäden
|Title = ELGA XDS Metadaten (XDSDocumentEntry)
|Subtitle = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA [1.2.40.0.34.7.6.9.3]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0+20210324
|Submitted = ELGA GmbH
|Date = März 2021
|Copyright = 2011-
|Status = Reconciliation
|Period = n.a.
|OID = 1.2.40.0.34.7.6.9.3
|Realm = Austria
}}

{{TOC limit|4}}



{{#css:
.orange{
border: thin black solid;
background-color:#F4C789;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
}
}}

=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;">
==Impressum==
<div class="mw-collapsible-content">
''Medieneigentümer, Herausgeber, Hersteller, Verleger:'' 
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050 
Internet: [http://www.elga.gv.at www.elga.gv.at]
Email: [mailto:cda@elga.gv.at cda@elga.gv.at] 
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch

''Redaktion, Projektleitung, Koordination: '' 
Mag.Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]

''Abbildungen:'' Sofern nicht anders angegeben: © ELGA GmbH

''Nutzung'': Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria [http://www.hl7.at www.hl7.at]. 
Die Nutzung ist ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter [https://www.gesundheit.gv.at www.gesundheit.gv.at] und [https://www.elga.gv.at/cda www.elga.gv.at/cda]
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

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

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

==Sprachliche Gleichbehandlung==
<div class="mw-collapsible-content">
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer, Frauen und andere Geschlechtsidentitäten in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
</div></div>

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

Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> .

===Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")===
<div style="border: thin #77c123 solid;width:100%; margin-left: 10px">
<div style="line-height: 1.25; font-size:16px; border-bottom: 1px solid #81ab1f; box-shadow: 0 4px 0 0 #a2d727;margin-bottom:4px; color:#77c123; width:100%">
Third Party Intellectual Property
</div>
<div style="width:100%;">


Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass der Herausgeber nicht alle Rechte und Ansprüche in und an den Materialien besitzt und dass die Materialien geistiges Eigentum von Dritten enthalten und / oder darauf verweisen können ("Third Party Intellectual Property (IP)"). 

Die Anerkennung dieser Lizenzbestimmungen gewährt dem Lizenznehmer keine Rechte in Bezug auf Third Party IP. Der Lizenznehmer allein ist für die Identifizierung und den Erhalt von notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig verantwortlich. 

Jegliche Handlungen, Ansprüche oder Klagen eines Dritten, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, bleiben die Haftung des Lizenznehmers.

</div>
</div>

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

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

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

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

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

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

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website: [[ILF: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 ([http://www.elga.gv.at/CDA Website der ELGA GmbH]) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:

*ELGA-Gesamtarchitektur<ref name="ELGA-Gesamtarchitektur">ELGA-Gesamtarchitektur 2.30a [http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>
*Beispieldokumente
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
*CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
*Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
*Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
*Hinweise für die zu verwendenden Terminologien
*Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}

==Bedienungshinweise==
===Farbliche Hervorhebungen===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''<Hinweis>''' authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
{{EndYellowBox}}
''Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>
''Verweis auf ELGA Value Set:''
{{BeginILFBox}}
'''<Verweis>''' Zulässige Werte gemäß Value Set '''"ELGA_FormatCode".'''
{{EndILFBox}}

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

===PDF-Navigation===
<div class="mw-collapsible-content">
Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

*Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
*Seitenweise blättern: "Bild" Tasten
*Scrollen: Pfeil nach oben bzw. unten
*Zoomen: Strg + Mouserad drehen
*Suchen im Dokument: Strg + F
</div></div>



=Harmonisierung=
'''Erarbeitung des Implementierungsleitfadens''' 
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%" |Person1
|- 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
|}

1 Namen ohne Titel


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

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.

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

==Hinweise zur Verwendung des Dokuments==
===Codesysteme und Value Sets===
Die in diesem Dokument erwähnten Codesysteme bzw. Value Sets werden am Terminologieserver (https://www.gesundheit.gv.at/gesundheitssystem/professional/it-services/terminologieserver-doku) und auf der Website der ELGA GmbH (http://www.elga.gv.at) veröffentlicht.

Wenn codierte Werte angegeben werden, ist es immer die Aufgabe des Document Consumers, die korrekten lesbaren Werte anzuzeigen. Es wird nicht empfohlen, die in den XDS-Metadaten verfügbaren DisplayNames direkt zur Anzeige zur verwenden, da Schreibweisen der DisplayNames variieren oder in unterschiedlichen Sprachen angegeben sein können.

===OID ===
In diesem Dokument wird an vielen Stellen die Verwendung von OID vorgeschrieben. OID sind Objekt-Identifikatoren oder Objektkennungen, die als weltweit eindeutige Namen für Informationsobjekte dienen (ISO/IEC 9834-1). Weitere Informationen zur Verwendung und Registrierung von OID sind im "OID-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.

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

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

====Bereitstellen [ITI-41] und Veröffentlichen [ITI-42]====
Ein neues Dokument wird entsprechend IHE XDS im Repository gespeichert und durch Registrieren der XDS-Metadaten in der Registry für ELGA bereitgestellt. Neu veröffentlichte Dokument-Metadaten werden immer mit dem Status "approved" versehen.

====Ersetzen eines Dokuments durch eine neue Version ("Updaten") [ITI-41]====
Änderungen eines für ELGA bereitgestellten Dokumentes sind NICHT ERLAUBT.

Es ist allerdings möglich, ein Dokument durch ein anderes zu ersetzen, indem ein neues Dokument (bzw. eine neue Version des Dokumentes) gespeichert und registriert wird. Hierbei MUSS die SetId der referenceIdList in den XDS-Metadaten zum neuen Dokument der der Vorgängerversion entsprechen. Die XDS-Metadaten der Vorgängerversion des Dokumentes bekommen den Status "deprecated". In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp "replace" (RPLC)).

Beim Ersetzen von ELGA Dokumenten wird das ELGA Berechtigungssystem eventuell zugeordnete individuelle Zugriffsberechtigungen unabhängig von ihrer Anzahl auch auf die Nachfolgeversionen anwenden.

====Stornieren [ITI-57, XDS Metadata Update]====
Dokumente werden "storniert", indem der Dokumentstatus auf "deprecated" gesetzt wird und keine neue Dokumentenversion registriert wird.

===Größenbeschränkung ===
ELGA schreibt für die Größe der eingebrachten CDA eine Maximalgröße von 20 MB vor. Größere Dokumente sind abzulehnen. Es liegt generell in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten |Allgemeiner Implementierungsleitfaden
für ELGA CDA Dokumente, Kapitel 6.10]].

==Allgemeines zu XDS-Metadaten==
Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumente entsprechend klassifiziert und beschrieben werden. Diese beschreibenden "Metadaten" werden in Form einer Nachricht gemeinsam mit dem Dokument an das Repository mitgegeben. Da IHE XDS Systeme grundsätzlich für beliebige Dokumentformate offen sind, gilt dies für alle Arten von Dokumenten (CDA, PDF, Bilder, etc.) gleichermaßen.

Die Metadaten eines Dokuments (XDSDocumentEntry) in einem IHE XDS System beinhalten Informationen
* über das Dokument selbst – um eine Klassifizierung und eine korrekte Darstellung des Dokumenteninhalts zu ermöglichen
* über eventuelle Beziehungen zu anderen Dokumenten (z.B. zu älteren Versionen eines Dokuments)
* über den Speicherort des Dokuments
* über den GDA, welcher das Dokument erstellt hat
* über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).
Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE "IT-Infrastructure" (ITI) Technical Framework, Volume 3 festgelegt (IHE ITI TF-3)<ref name="ITITF3"/>.

Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.
{{BeginYellowBox}}
Die Metadaten sind die ausschließliche Grundlage für das Suchen und Filtern von Dokumenten in einem XDS Dokumentenregister und somit im ELGA Verweisregister, daher ist die korrekte Verschlagwortung der Dokumente mit den Metadaten eine notwendige Voraussetzung.
{{EndYellowBox}}

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

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

===Metadaten aus strukturierten Dokumenten (CDA)===
Strukturierte Dokumente bieten die Möglichkeit, die Informationen für die Metadaten beim Einbringen in ein Repository in gewissem Maße aus den Dokumenten selbst automatisiert zu entnehmen. Das vermindert daher die Menge der Informationen, die separat erhoben oder ermittelt werden muss.

Die IHE hat im Rahmen des "Patient Care Coordination" (PCC) Technical Frameworks eine genaue Vorschrift spezifiziert, aus welchen Bereichen des CDA Dokuments die Metadaten entnommen werden sollen.

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

===Metadaten aus "On-Demand Documents" (ODD) ===
Ü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"/>.

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

===XDS Metadaten im Vergleich IHE vs. ELGA===
Die vollständige Liste der XDS Metadaten Elemente kann man in folgende Arten von Elementen unterteilen:
# Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
# Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)
# '''Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können (XDS Document Source)'''
# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
## '''ELGA relevante'''
## Nicht ELGA relevante
Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).

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

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

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

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

{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|K||Aus KOS-Inhalt abgeleitet
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- style="background:#white"
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
|}

''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" |'''Metadaten Element'''
|'''Optionalität'''
|'''Quelle'''
|'''Beschreibung'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''M [1..1]'''
|<nowiki>-</nowiki>
|Die Person oder das Gerät, welche(s) das Dokument verfasst hat
|-
| rowspan="4" |
|authorInstitution
|'''M [1..1]'''
|E1/K
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|-
|authorPerson
|'''R [0..1]'''
|K
|Daten der Person

(Name, ID, etc.)
|-
|authorRole
|'''R [0..1]'''
|K
|Rolle der Person
|-
|authorSpeciality
|'''R [0..1]'''
|E1/K
|Fachrichtung der Person
|-
| colspan="2" |'''classCode'''
|'''M [1..1]'''
|A
|Dokumenten/Objektklasse (Oberklasse)

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

codierter Wert
|-
| colspan="2" |'''uniqueId'''
|'''M [1..1]'''
|K
|Global eindeutige ID des Objektes

z.B. SOP Instance UID
|-
| colspan="2" |'''referenceIdList'''
|'''M [1..*]'''
|K/E1
|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|-
| colspan="5" |'''''Explizit zu setzende Metadaten'''''
|-
| colspan="2" |'''availabilityStatus'''
|'''M [1..1]'''
|E1
|Gültigkeit des Objektes
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|E1
|Format des Objektes
|-
| colspan="2" |'''healthcareFacilityTypeCode'''
|'''M [1..1]'''
|E1
|Klassifizierung des GDA
|-
| colspan="2" |'''mimeType'''
|'''M [1..1]'''
|E1
|Mime Type des Dokuments

Fester Wert für KOS: "application/dicom"
|-
| colspan="2" |'''parentDocumentId'''
|'''O [0..1]'''
|E1
|Verweis auf ein referenziertes Objekt
|-
| colspan="2" |'''parentDocumentRelationship'''
|'''O [0..1]'''
|E1
|Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC, XFRM
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|E1
|Fachliche Zuordnung des Dokuments
|-
| colspan="2" |'''entryUUID'''
|'''M [1..1]'''
|E1
|UUID des Metadaten-Records des Dokuments(XDS DocumentEntry)
|-
| colspan="2" |'''objectType'''
|'''M [1..1]'''
|E1
|Typ des DocumentEntries

Fester Wert "SD"
|-
| colspan="2" |'''comments'''
|'''O [0..1]'''
|K
|Kommentar zum Dokument/Objekt
|-
| colspan="2" |'''patientId'''
|'''M [1..1]'''
|E1
|Patienten-ID in der XDS Affinity Domain
|-
| colspan="5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|-
| colspan="2" |'''hash'''
|'''M [1..1]'''
|A
|Hash Wert des Dokuments. Wird vom Repository befüllt
|-
| colspan="2" |'''homeCommunityId'''
|'''M [1..1]'''
|A
|Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.
|-
| colspan="2" |'''repositoryUniqueId'''
|'''M [1..1]'''
|A
|Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
|-
| colspan="2" |'''size'''
|'''M [1..1]'''
|A
|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository befüllt.
 
|-
| colspan="2" |'''URI'''
|'''NP [0..0]'''[[#%20ftn1|<nowiki/>]][[#%20ftn1|<nowiki/>]]
|A
|Wird in XDS-I nicht verwendet
|-
|-
| colspan="5" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|-
| colspan="2" |'''elgaFlag'''
|'''M [1..1]'''
|B
|Kennzeichnet ein Dokument als "ELGA-Dokument"
|-
| colspan="2" |'''elgaHash'''
|'''M [1..1]'''
|B
|Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes
|}
 [[#%20ftn1|<nowiki/>]]

 


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

In der Tabelle 6 werden die XDS-Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität), jeweils für Stable Documents (SD) und On-Demand-Documents (ODD) angegeben.

''Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|C||Aus CDA-Inhalt abgeleitet (direkt oder indirekt, gilt nicht für On-Demand-Documents)
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- 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="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 6: Überblick XDS Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''
| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''
| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
| rowspan="2" style="text-align:left" |'''Beschreibung '''
|- style="background:#CBD7F1"
|'''SD'''9||'''ODD'''10
|- style="background:#CBD7F1"
| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''
|- style="background:white"
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''M [1..1]'''||'''M [1..1]'''
|C||Die Person, welche das Dokument verfasst hat
|- style="background:white"
| ||authorInstitution||'''M [1..1]'''||'''M [1..1]'''
|C||ID und Name der Organisation (Kurzbezeichnung), der die Person angehört, wie im GDA-Index angegeben.
|- style="background:white"
| ||authorPerson||'''M [1..1]'''||'''M [1..1]'''
|C||Daten der Person (Name, ID, etc.)
|- style="background:white"
| ||authorRole||'''R [0..1]'''||'''NP [0..0]'''
|C||Rolle der Person
|- style="background:white"
| ||authorSpeciality||'''R [0..1]'''||'''NP [0..0]'''
|C||Fachrichtung der Person
|- style="background:white"
| colspan="2" |'''classCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Vertraulichkeitscode des Dokuments
|- style="background:white"
| colspan="2" |'''creationTime'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R [0..*]'''||'''R [0..*]'''
|C||Liste von Gesundheitsdienstleistungen
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Format des Dokumenteninhalts
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O [0..1]'''||'''NP [0..0]'''
|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.
|- style="background:white"
| colspan="2" |'''languageCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Sprachcode des Dokuments z.B.: "de-AT"
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R [0..1]'''||'''NP [0..0]'''
|C||Rechtlicher Unterzeichner des Dokuments
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Fachliche Zuordnung des Dokuments
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''NP [0..0]'''||'''NP [0..0]'''
|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)
|- style="background:white"
| colspan="2" |'''Title'''||'''M [1..1]'''||'''M [1..1]'''
|C||Titel des Dokuments
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Global eindeutige ID des Dokuments
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''M [1..1]'''||'''O [0..1]'''
|C||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''M [1..1]'''||'''M [1..1]'''
|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 z.B.: "text/xml" für CDA
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O [0..1]'''||'''O [0..1]'''
|E1||Verweis auf ein referenziertes Dokument
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O [0..1]'''||'''O [0..1]'''
|E1||Typ der Relation zu dem referenzierten Dokument. 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
|}

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

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

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

''Tabelle 7: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" |'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

'''der Studie'''
|'''Attribut'''

'''im KOS'''
|'''Beschreibung'''
|- style="background:white"
| colspan="2" |author
|M [1..1]
| colspan="3" |
|- style="background:white"
| rowspan="6" |
|author.authorInstitution
|M [1..1]
|(0008,0080)
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

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

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

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

'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
|- style="background:white"
| colspan="5" |Die Person, welche die Studie durchführt, ist als author anzugeben:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,1052)
|
|Performing Physicians Identification Sequence

Code und weitere Daten aus dem ersten Item in der Sequence

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

(0008,1050)
|
|Performing Physicians Name

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

'''Achtung:''' Die Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
|- style="background:white"
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,0060) + (0008,0070) + (0008,1090)
|
|Modality Code + Manufacturer + Manufacturer's Model Name

'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
|- style="background:white"
| colspan="2" |creationTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date + Study Time

Für den Fall, dass Study Date und Study Time nicht zur Verfügung stehen, ist es zulässig, den Erstellungszeitpunkt des KOS ((0008,0023) contentDate + (0008,0033) contentTime) als creationTime zu verwenden.
|- style="background:white"
| colspan="2" |eventCodeList
|M [1..*]
|
|
|Enthält eine Liste von Codes von Gesundheitsdienstleistungen nach APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten<nowiki/>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</ref>
|- style="background:white"
|
|eventCodeList DisplayNameList
|M [1..1]
|
|
|Enthält den Display Name des APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom" />
|- style="background:white"
| colspan="2" |serviceStartTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|- style="background:white"
| colspan="2" |sourcePatientId
|M [1..1]
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|- style="background:white"
| colspan="2" |sourcePatientInfo
|M [1..1]
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|Die ELGA Vorgabe empfiehlt, Name, Geburtstag und Geschlecht NICHT anzugeben.
|- style="background:white"
| colspan="2" |title
|M [1..1]
|(0008,0060) + (0008,1030)
|
|Der relevante Modality Code der Studie oder alle Modality Codes der Studie und die Study Description.

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

'''Anmerkung:'''

Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
 
|- style="background:white"
| colspan="2" |uniqueId
|M [1..1]
|
|(0008,0018)
|Die SOP Instance UID des KOS
|- style="background:white"
| colspan="2" |referenceIdList
|M [1..1]
|
|
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|- style="background:white"
| rowspan="2" |
|value mit CXi.5 = "<nowiki>urn:elga:iti:xds:2014: OwnDocument_setId</nowiki>"
|M [1..1]
|(0020,000D) oder ein vergleichbares Attribut
|(0020,000D) oder ein vergleichbares Attribut
|Die setId zur Klammerung aller Versionen eines KOS

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

Eine mögliche Wahl der setId ist die Study Instance UID. Die geeignete Wahl der setId hängt auch vom implementierten Stornoworkflow ab, siehe KOS Leitfaden (Kapitel 8.2.2.)<ref name="KOS-Leitfaden" />
|- style="background:white"
|value mit CXi.5 = "<nowiki>urn:ihe:iti:xds:2013: accession</nowiki>"
|R [0..1]
|(0008,0050) oder ein vergleichbares Attribut wie z.B.

(0040,1001) Requested Procedure ID
 
|(0008,0050)
 
|Die ID, die zur Verlinkung mit dem Befund heranzuziehen ist.

Diese ist mit dem Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' anzugeben.

'''Achtung:'''

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

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

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

Unabhängig von der Wahl des DICOM Attributs ist aber in jedem Fall der Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' zu verwenden.
|- style="background:white"
| colspan="2" |comments
|O [0..1]
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

===author===
Die Person oder Maschine, die das Dokument erstellt hat. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.

Die ''authorInstitution'' benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden können. Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.

*''oid'': OID der Organisation aus dem GDA-Index (muss ermittelt werden)
*''name'': (0008,0080), Institution Name, Name der Organisation als String,
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden. 

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

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

=====Spezifikation=====

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

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

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

concat( 
$name,"^^^^^^^^^", 
$oid,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

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

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

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

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

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

=====Spezifikation für Personen=====

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

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

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

$person = (0008,1050) Performing Physicians Name

$root = OID-Knoten für den Personenidentifikator

concat( 
 $id,"^", 
 $person,"^", 
 $root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>11375^Musterdoc^Josef^Maria^Msc^DIDr^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>

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

concat( 
 $id,"^", 
 $person 
) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf die XCN Komponenten wie in IHE RAD TF-2 Rev.19 2020<ref name="IHERADTF2">IHE Radiology (RAD) Technical Framework Volume 2x Rev.19, 2020 [https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf]</ref>, "Table 4.68.4.1.2.3-3: XCN Data type mapping" vorgegeben.

=====Spezifikation für Software und Geräte=====

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

$Modality = Modality (0008,0060)

$Manufacturer = Manufacturer (0008,0070)

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

concat(

"^",

$Modality,"^",

$Manufacturer,"^",

$ManufacturersModelName

) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^CT^Geräthersteller^Gerätename</Value>
</ValueList>
</Slot>
</Classification></pre>

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

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

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

Beispiel:

*"Radiologie"
*"Modalität"

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

Beispiel:

*"Facharzt für Radiologie"
*"Facharzt für Nuklearmedizin"

=====Spezifikation=====

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

Bsp: Fachärztin/Facharzt für Radiologie 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Fachärztin/Facharzt für Radiologie</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Wenn eine Person als Autor vorhanden ist, '''MUSS''' der Wert einem DisplayName aus dem Value Set "ELGA_AuthorSpeciality" entsprechen.

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

{{EndYellowBox}}

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

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Objektklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Objektklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#typeCode_.28und_typeCodeDisplayName.29|typeCode]]
|}

====Spezifikation====

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

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

$code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
classifiedObject="theDocument" nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===confidentialityCode===
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.

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

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

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

====Spezifikation====

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

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

<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="theDocument" nodeRepresentation="N">
<Name>
<LocalizedString value="normal"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:2.16.840.1.113883.5.25</Value>
</ValueList>
</Slot>
</Classification></pre>

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

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

Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From ''UTC''<ref>Timezone Offset From UTC http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</ref> berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

====Spezifikation====

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

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

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

concat(

$date,

$time

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="creationTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.{{EndYellowBox}}

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

====Spezifikation====

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

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

$code = APPC code (alle Achsen) z.B. "2.4.0.5-3-3" 
$displayName = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule" 
$codeSystem = OID des Codesystems APPC: 1.2.40.0.34.5.38 
<pre class="ilfbox_code">
<Classification
classificationScheme=
"urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
classifiedObject="theDocument"
nodeRepresentation="$code">
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
<Name>
<LocalizedString value="$displayName"/>
</Name>
</Classification>
</pre>

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

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

Fester Wert "de-AT"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/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===
Dieses Element darf für XDS-I nicht verwendet werden [NP].

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

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

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

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

concat(

Study Date,

Study Time + Timezone Offset from UTC

)
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="serviceStartTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

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

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

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

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

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

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

$patientID = (0010,0020) Patient ID

$oid = OID des lokalen Patientenidentifikators

concat(

$patientID,

"^^^&amp;",

$oid,

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.
{{BeginYellowBox}}
In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
{{EndYellowBox}}

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

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

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modality Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. ("CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule")
{{BeginYellowBox}}
'''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
{{EndYellowBox}}
====Spezifikation====

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

concat(

Modality,

" ",

Study Description

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Name>
<LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" />
</Name>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
{{EndYellowBox}}

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

Unterscheidung typeCode/classCode:
{| class="wikitable"
|- style="background:white"
|'''typeCode'''
|'''Objektklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
|classCode
|Objektklasse in grober Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29|classCode]]
|}

====Spezifikation====

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

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

 $code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="KeyImageObject"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

$code = "55113-5"

$displayName = "Key images Document Radiology"

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

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

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

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

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

$value = (0008,0018) SOP Instance UID

<pre class="ilfbox_code">
<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. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:

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

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

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

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

{| 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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}
{{BeginYellowBox}}

'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.
{{EndYellowBox}}

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

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

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

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

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

concat

(

$id, "^^^^",

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

"&amp;",

$homeCommunityId, "&amp;ISO"

)

Wie oben angeführt wird folgender CXi Wert für <Value> erstellt:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.

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

=====Spezifikation=====
Bei der Registrierung von KOS Objekten SOLL eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden. Diese dient als Basis für die Verlinkung mit einem Befund der bildgebenden Diagnostik (diagnostic image report). Wird in der ReferenceIdList der XDS-I Metadaten keine Accession Number angeführt, ist eine Verlinkung nicht möglich.

Für Befunde der Bildgebenden Diagnostik (diagnostic image report) kann die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Accession Number z.B. 20201111

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

concat

(

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

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

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"

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

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

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

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

$id = Aufenthaltszahl z.B. Az123456

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

concat

(

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

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

"<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>Az123456^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.4613.3.4<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>
</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

*'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki>. In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.
*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki>

Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId
</nowiki>^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
<Value>20201111^^^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
<Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value>
<Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===intendedRecipient===
Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der ''intendedRecipient'' notwendig. Derzeit wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.

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

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

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

====Spezifikation====
Comments wird gemäß folgender Vorschrift zusammengesetzt:
$comment = (0008,1030) Study Description<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Description">
<LocalizedString value = "$comment"/>
</Description>
</ExtrinsicObject>
</pre> 

==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
===availabilityStatus===
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Objektes.

Mögliche Werte laut IHE sind:

*Approved
*Deprecated

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

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

<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

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

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

===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA, z.B.

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

Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]".
{{EndYellowBox}}

====Spezifikation====

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

$code = Klassifizierung des GDA (Code)

$displayName = Klartext des angegebenen Codes

$codeSystem = OID der ausgebenden Stelle

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

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

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

====Spezifikation====

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

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

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

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

*F044 "Radiologie"
*F052 "Unfallchirurgie"

Im KOS-Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_PracticeSetting_VS ELGA_PracticeSetting_VS]".
{{EndYellowBox}}

====Spezifikation====

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

$code = Code aus Value Set ELGA_PracticeSetting $displayName = Klartext des angegebenen Codes (displayName) $codeSystem = OID des Codesystems (1.2.40.0.34.5.12) 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

Für KOS Objekte wird der fixe Wert "<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="application/dicom"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

==ELGA-spezifische Erweiterungen der XDS-Metadaten==
Die folgenden Daten entsprechen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information.

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

*"true" oder
*"false"

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

====Spezifikation====

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

===elgaHash===
Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot "ELGA-Hash" gespeichert.

Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.

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

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

==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).

CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen.

====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurde.

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

#Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört, grundsätzlich in folgendem Element abgelegt:
##ClinicalDocument/author/assignedAuthor/representedOrganization
#Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:
##'''id'''[1] … ID der Organisation mit den folgenden Attributen:
###@root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)
###@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)
##'''name''' … Name der Organisation als String Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.
#GDA, in deren Gültigkeitsbereich Dokumente erstellt werden können, sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da es vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden.
{{EndYellowBox}}

=====Spezifikation=====

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

$inst … ClinicalDocument/author/assignedAuthor/representedOrganization

*Fall 1: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist nicht vorhanden 

concat( 
$inst/name,"^^^^^^^^^", 
$inst/id[1]/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO</Value>
</ValueList>
</Slot>
</Classification>
</pre>

*Fall 2: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist vorhanden 

concat( 
$inst/name,"^^^^^&", 
$inst/id[1]/@root,"&ISO^^^^" 
$inst/id[1]/@extension 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&amp;ISO^^^^45</Value>
</ValueList>
</Slot>
</Classification>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

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

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

#Laut Festlegung wird der Autor im Header-Element "author" abgelegt:
##ClinicalDocument/author/assignedAuthor
#Der Autor (Person)
##Ein Personenelement enthält unter anderem die folgenden Unterelemente:
###id … ID der Person mit den folgenden Attributen:
####@root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
####@extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
###assignedPerson
####Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
#####name
#Gerät oder Software als Autor
##Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:
###assignedAuthoringDevice
####Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software
#####manufacturerModelName
####Enthält ein Element mit dem Namen des Geräts oder der Software
#####softwareName

=====Spezifikation für Personen=====

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

 $person = ClinicalDocument/author/assignedAuthor

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
{{BeginYellowBox}}
Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.
{{EndYellowBox}}
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

=====Spezifikation für Software und Geräte=====

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

 $person = ClinicalDocument/author/assignedAuthor

concat( 
"^", 
 $person/assignedAuthoringDevice/manufacturerModelName,"^", 
 $person/assignedAuthoringDevice/softwareName 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^Good Health System^Best Health Software Application</Value>
</ValueList>
</Slot>
</Classification></pre>

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

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.

Beispiel:

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

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

#Laut Festlegung wird die "Rolle" der Person, welche das Dokument inhaltlich erstellt hat, im Element functionCode des Autors abgelegt:
##''ClinicalDocument/author/functionCode''
#Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.

=====Spezifikation=====

'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/functionCode/@displayName 
<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorRole">
<ValueList>
<Value>Diensthabender Oberarzt</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.

Beispiel:

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

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

#Laut Festlegung wird die "Fachrichtung" der Person, welche das Dokument inhaltlich erstellt hat, im Element code des Autors abgelegt:
##''ClinicalDocument/author/assignedAuthor/code''
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.

=====Spezifikation=====

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

ClinicalDocument/author/assignedAuthor/code/@displayName 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Anästhesiologie und Intensivmedizin</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

===classCode (und classCodeDisplayName)===
Das ''classCode'' Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Dokumentenklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Dokumentenklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2|typeCode]]
|}

====Spezifikation====

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

$code = ClinicalDocument/code/translation/@code 
$displayName = ClinicalDocument/code/translation/@displayName 
$codeSystem = ClinicalDocument/code/translation/@codeSystem 
<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: 

<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.
Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

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

#Im CDA wird dieser Zeitpunkt wie folgt abgelegt:
##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:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
CreationTime entfällt bei On-Demand Documents.
{{EndYellowBox}}

====Spezifikation====

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 
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: 

Für jedes documentationOf Element 1..n: 

$code = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code 
$displayName = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName 
$codeSystem = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem 
<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: 

 $person = ClinicalDocument/legalAuthenticator/assignedEntity

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<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) Achtung: Diese ID gelangt nicht in die Metadaten!

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

 $code = ClinicalDocument/code/@code 
 $displayName = ClinicalDocument/code/@displayName 
 $codeSystem = ClinicalDocument/code/@codeSystem 
<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: 

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

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

Fall 2 
Attribut ClinicalDocument/id/@extension ist vorhanden

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

<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..1])
#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).

{{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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}

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

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

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

 

===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: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = ClinicalDocument/hl7at:formatCode/@displayName 
$codeSystem = 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:

$code = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code

$displayName = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName

$codeSystem = 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: 
CDA R2: '''text/xml''' 

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

$code = ClinicalDocument/hl7at:practiceSettingCode/@code 
$displayName = ClinicalDocument/hl7at:practiceSettingCode/@displayName 
$codeSystem = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem 
<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"18. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:

*"true" oder
*"false"
18 Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.
====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=

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

ILF:XDS Metadaten (Version 3)

2021-03-26T07:52:02Z

Kuttin: /* Spezifikation */

{{#seo:
|title=XDS Metadaten 3.0.0
|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 (Version 3.0.0)}}



{{#css:
@media screen{
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.toc{
width: 20%;
float: right !important;
margin: 10px 0px 10px 30px !important;
border: 1px solid #AAA;
background-color: #F9F9F9;
display: table;
padding: 7px !important;
}
}
}}

{{Infobox Dokument
|Group = ELGA CDA Implementierungsleitfäden
|Title = ELGA XDS Metadaten (XDSDocumentEntry)
|Subtitle = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA [1.2.40.0.34.7.6.9.3]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0+20210324
|Submitted = ELGA GmbH
|Date = März 2021
|Copyright = 2011-
|Status = Reconciliation
|Period = n.a.
|OID = 1.2.40.0.34.7.6.9.3
|Realm = Austria
}}

{{TOC limit|4}}



{{#css:
.orange{
border: thin black solid;
background-color:#F4C789;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
}
}}

=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;">
==Impressum==
<div class="mw-collapsible-content">
''Medieneigentümer, Herausgeber, Hersteller, Verleger:'' 
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050 
Internet: [http://www.elga.gv.at www.elga.gv.at]
Email: [mailto:cda@elga.gv.at cda@elga.gv.at] 
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch

''Redaktion, Projektleitung, Koordination: '' 
Mag.Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]

''Abbildungen:'' Sofern nicht anders angegeben: © ELGA GmbH

''Nutzung'': Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria [http://www.hl7.at www.hl7.at]. 
Die Nutzung ist ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter [https://www.gesundheit.gv.at www.gesundheit.gv.at] und [https://www.elga.gv.at/cda www.elga.gv.at/cda]
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

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

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

==Sprachliche Gleichbehandlung==
<div class="mw-collapsible-content">
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer, Frauen und andere Geschlechtsidentitäten in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
</div></div>

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

Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> .

===Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")===
<div style="border: thin #77c123 solid;width:100%; margin-left: 10px">
<div style="line-height: 1.25; font-size:16px; border-bottom: 1px solid #81ab1f; box-shadow: 0 4px 0 0 #a2d727;margin-bottom:4px; color:#77c123; width:100%">
Third Party Intellectual Property
</div>
<div style="width:100%;">


Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass der Herausgeber nicht alle Rechte und Ansprüche in und an den Materialien besitzt und dass die Materialien geistiges Eigentum von Dritten enthalten und / oder darauf verweisen können ("Third Party Intellectual Property (IP)"). 

Die Anerkennung dieser Lizenzbestimmungen gewährt dem Lizenznehmer keine Rechte in Bezug auf Third Party IP. Der Lizenznehmer allein ist für die Identifizierung und den Erhalt von notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig verantwortlich. 

Jegliche Handlungen, Ansprüche oder Klagen eines Dritten, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, bleiben die Haftung des Lizenznehmers.

</div>
</div>

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

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

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

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

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

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

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website: [[ILF: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 ([http://www.elga.gv.at/CDA Website der ELGA GmbH]) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:

*ELGA-Gesamtarchitektur<ref name="ELGA-Gesamtarchitektur">ELGA-Gesamtarchitektur 2.30a [http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>
*Beispieldokumente
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
*CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
*Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
*Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
*Hinweise für die zu verwendenden Terminologien
*Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}

==Bedienungshinweise==
===Farbliche Hervorhebungen===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''<Hinweis>''' authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
{{EndYellowBox}}
''Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>
''Verweis auf ELGA Value Set:''
{{BeginILFBox}}
'''<Verweis>''' Zulässige Werte gemäß Value Set '''"ELGA_FormatCode".'''
{{EndILFBox}}

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

===PDF-Navigation===
<div class="mw-collapsible-content">
Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

*Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
*Seitenweise blättern: "Bild" Tasten
*Scrollen: Pfeil nach oben bzw. unten
*Zoomen: Strg + Mouserad drehen
*Suchen im Dokument: Strg + F
</div></div>



=Harmonisierung=
'''Erarbeitung des Implementierungsleitfadens''' 
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%" |Person1
|- 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
|}

1 Namen ohne Titel


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

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.

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

==Hinweise zur Verwendung des Dokuments==
===Codesysteme und Value Sets===
Die in diesem Dokument erwähnten Codesysteme bzw. Value Sets werden am Terminologieserver (https://www.gesundheit.gv.at/gesundheitssystem/professional/it-services/terminologieserver-doku) und auf der Website der ELGA GmbH (http://www.elga.gv.at) veröffentlicht.

Wenn codierte Werte angegeben werden, ist es immer die Aufgabe des Document Consumers, die korrekten lesbaren Werte anzuzeigen. Es wird nicht empfohlen, die in den XDS-Metadaten verfügbaren DisplayNames direkt zur Anzeige zur verwenden, da Schreibweisen der DisplayNames variieren oder in unterschiedlichen Sprachen angegeben sein können.

===OID ===
In diesem Dokument wird an vielen Stellen die Verwendung von OID vorgeschrieben. OID sind Objekt-Identifikatoren oder Objektkennungen, die als weltweit eindeutige Namen für Informationsobjekte dienen (ISO/IEC 9834-1). Weitere Informationen zur Verwendung und Registrierung von OID sind im "OID-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.

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

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

====Bereitstellen [ITI-41] und Veröffentlichen [ITI-42]====
Ein neues Dokument wird entsprechend IHE XDS im Repository gespeichert und durch Registrieren der XDS-Metadaten in der Registry für ELGA bereitgestellt. Neu veröffentlichte Dokument-Metadaten werden immer mit dem Status "approved" versehen.

====Ersetzen eines Dokuments durch eine neue Version ("Updaten") [ITI-41]====
Änderungen eines für ELGA bereitgestellten Dokumentes sind NICHT ERLAUBT.

Es ist allerdings möglich, ein Dokument durch ein anderes zu ersetzen, indem ein neues Dokument (bzw. eine neue Version des Dokumentes) gespeichert und registriert wird. Hierbei MUSS die SetId der referenceIdList in den XDS-Metadaten zum neuen Dokument der der Vorgängerversion entsprechen. Die XDS-Metadaten der Vorgängerversion des Dokumentes bekommen den Status "deprecated". In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp "replace" (RPLC)).

Beim Ersetzen von ELGA Dokumenten wird das ELGA Berechtigungssystem eventuell zugeordnete individuelle Zugriffsberechtigungen unabhängig von ihrer Anzahl auch auf die Nachfolgeversionen anwenden.

====Stornieren [ITI-57, XDS Metadata Update]====
Dokumente werden "storniert", indem der Dokumentstatus auf "deprecated" gesetzt wird und keine neue Dokumentenversion registriert wird.

===Größenbeschränkung ===
ELGA schreibt für die Größe der eingebrachten CDA eine Maximalgröße von 20 MB vor. Größere Dokumente sind abzulehnen. Es liegt generell in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten |Allgemeiner Implementierungsleitfaden
für ELGA CDA Dokumente, Kapitel 6.10]].

==Allgemeines zu XDS-Metadaten==
Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumente entsprechend klassifiziert und beschrieben werden. Diese beschreibenden "Metadaten" werden in Form einer Nachricht gemeinsam mit dem Dokument an das Repository mitgegeben. Da IHE XDS Systeme grundsätzlich für beliebige Dokumentformate offen sind, gilt dies für alle Arten von Dokumenten (CDA, PDF, Bilder, etc.) gleichermaßen.

Die Metadaten eines Dokuments (XDSDocumentEntry) in einem IHE XDS System beinhalten Informationen
* über das Dokument selbst – um eine Klassifizierung und eine korrekte Darstellung des Dokumenteninhalts zu ermöglichen
* über eventuelle Beziehungen zu anderen Dokumenten (z.B. zu älteren Versionen eines Dokuments)
* über den Speicherort des Dokuments
* über den GDA, welcher das Dokument erstellt hat
* über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).
Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE "IT-Infrastructure" (ITI) Technical Framework, Volume 3 festgelegt (IHE ITI TF-3)<ref name="ITITF3"/>.

Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.
{{BeginYellowBox}}
Die Metadaten sind die ausschließliche Grundlage für das Suchen und Filtern von Dokumenten in einem XDS Dokumentenregister und somit im ELGA Verweisregister, daher ist die korrekte Verschlagwortung der Dokumente mit den Metadaten eine notwendige Voraussetzung.
{{EndYellowBox}}

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

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

===Metadaten aus strukturierten Dokumenten (CDA)===
Strukturierte Dokumente bieten die Möglichkeit, die Informationen für die Metadaten beim Einbringen in ein Repository in gewissem Maße aus den Dokumenten selbst automatisiert zu entnehmen. Das vermindert daher die Menge der Informationen, die separat erhoben oder ermittelt werden muss.

Die IHE hat im Rahmen des "Patient Care Coordination" (PCC) Technical Frameworks eine genaue Vorschrift spezifiziert, aus welchen Bereichen des CDA Dokuments die Metadaten entnommen werden sollen.

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

===Metadaten aus "On-Demand Documents" (ODD) ===
Ü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"/>.

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

===XDS Metadaten im Vergleich IHE vs. ELGA===
Die vollständige Liste der XDS Metadaten Elemente kann man in folgende Arten von Elementen unterteilen:
# Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
# Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)
# '''Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können (XDS Document Source)'''
# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
## '''ELGA relevante'''
## Nicht ELGA relevante
Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).

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

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

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

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

{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|K||Aus KOS-Inhalt abgeleitet
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- style="background:#white"
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
|}

''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" |'''Metadaten Element'''
|'''Optionalität'''
|'''Quelle'''
|'''Beschreibung'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''M [1..1]'''
|<nowiki>-</nowiki>
|Die Person oder das Gerät, welche(s) das Dokument verfasst hat
|-
| rowspan="4" |
|authorInstitution
|'''M [1..1]'''
|E1/K
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|-
|authorPerson
|'''R [0..1]'''
|K
|Daten der Person

(Name, ID, etc.)
|-
|authorRole
|'''R [0..1]'''
|K
|Rolle der Person
|-
|authorSpeciality
|'''R [0..1]'''
|E1/K
|Fachrichtung der Person
|-
| colspan="2" |'''classCode'''
|'''M [1..1]'''
|A
|Dokumenten/Objektklasse (Oberklasse)

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

codierter Wert
|-
| colspan="2" |'''uniqueId'''
|'''M [1..1]'''
|K
|Global eindeutige ID des Objektes

z.B. SOP Instance UID
|-
| colspan="2" |'''referenceIdList'''
|'''M [1..*]'''
|K/E1
|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|-
| colspan="5" |'''''Explizit zu setzende Metadaten'''''
|-
| colspan="2" |'''availabilityStatus'''
|'''M [1..1]'''
|E1
|Gültigkeit des Objektes
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|E1
|Format des Objektes
|-
| colspan="2" |'''healthcareFacilityTypeCode'''
|'''M [1..1]'''
|E1
|Klassifizierung des GDA
|-
| colspan="2" |'''mimeType'''
|'''M [1..1]'''
|E1
|Mime Type des Dokuments

Fester Wert für KOS: "application/dicom"
|-
| colspan="2" |'''parentDocumentId'''
|'''O [0..1]'''
|E1
|Verweis auf ein referenziertes Objekt
|-
| colspan="2" |'''parentDocumentRelationship'''
|'''O [0..1]'''
|E1
|Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC, XFRM
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|E1
|Fachliche Zuordnung des Dokuments
|-
| colspan="2" |'''entryUUID'''
|'''M [1..1]'''
|E1
|UUID des Metadaten-Records des Dokuments(XDS DocumentEntry)
|-
| colspan="2" |'''objectType'''
|'''M [1..1]'''
|E1
|Typ des DocumentEntries

Fester Wert "SD"
|-
| colspan="2" |'''comments'''
|'''O [0..1]'''
|K
|Kommentar zum Dokument/Objekt
|-
| colspan="2" |'''patientId'''
|'''M [1..1]'''
|E1
|Patienten-ID in der XDS Affinity Domain
|-
| colspan="5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|-
| colspan="2" |'''hash'''
|'''M [1..1]'''
|A
|Hash Wert des Dokuments. Wird vom Repository befüllt
|-
| colspan="2" |'''homeCommunityId'''
|'''M [1..1]'''
|A
|Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.
|-
| colspan="2" |'''repositoryUniqueId'''
|'''M [1..1]'''
|A
|Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
|-
| colspan="2" |'''size'''
|'''M [1..1]'''
|A
|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository befüllt.
 
|-
| colspan="2" |'''URI'''
|'''NP [0..0]'''[[#%20ftn1|<nowiki/>]][[#%20ftn1|<nowiki/>]]
|A
|Wird in XDS-I nicht verwendet
|-
|-
| colspan="5" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|-
| colspan="2" |'''elgaFlag'''
|'''M [1..1]'''
|B
|Kennzeichnet ein Dokument als "ELGA-Dokument"
|-
| colspan="2" |'''elgaHash'''
|'''M [1..1]'''
|B
|Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes
|}
 [[#%20ftn1|<nowiki/>]]

 


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

In der Tabelle 6 werden die XDS-Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität), jeweils für Stable Documents (SD) und On-Demand-Documents (ODD) angegeben.

''Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|C||Aus CDA-Inhalt abgeleitet (direkt oder indirekt, gilt nicht für On-Demand-Documents)
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- 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="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 6: Überblick XDS Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''
| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''
| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
| rowspan="2" style="text-align:left" |'''Beschreibung '''
|- style="background:#CBD7F1"
|'''SD'''9||'''ODD'''10
|- style="background:#CBD7F1"
| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''
|- style="background:white"
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''M [1..1]'''||'''M [1..1]'''
|C||Die Person, welche das Dokument verfasst hat
|- style="background:white"
| ||authorInstitution||'''M [1..1]'''||'''M [1..1]'''
|C||ID und Name der Organisation (Kurzbezeichnung), der die Person angehört, wie im GDA-Index angegeben.
|- style="background:white"
| ||authorPerson||'''M [1..1]'''||'''M [1..1]'''
|C||Daten der Person (Name, ID, etc.)
|- style="background:white"
| ||authorRole||'''R [0..1]'''||'''NP [0..0]'''
|C||Rolle der Person
|- style="background:white"
| ||authorSpeciality||'''R [0..1]'''||'''NP [0..0]'''
|C||Fachrichtung der Person
|- style="background:white"
| colspan="2" |'''classCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Vertraulichkeitscode des Dokuments
|- style="background:white"
| colspan="2" |'''creationTime'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R [0..*]'''||'''R [0..*]'''
|C||Liste von Gesundheitsdienstleistungen
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Format des Dokumenteninhalts
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O [0..1]'''||'''NP [0..0]'''
|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.
|- style="background:white"
| colspan="2" |'''languageCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Sprachcode des Dokuments z.B.: "de-AT"
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R [0..1]'''||'''NP [0..0]'''
|C||Rechtlicher Unterzeichner des Dokuments
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Fachliche Zuordnung des Dokuments
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''NP [0..0]'''||'''NP [0..0]'''
|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)
|- style="background:white"
| colspan="2" |'''Title'''||'''M [1..1]'''||'''M [1..1]'''
|C||Titel des Dokuments
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Global eindeutige ID des Dokuments
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''M [1..1]'''||'''O [0..1]'''
|C||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''M [1..1]'''||'''M [1..1]'''
|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 z.B.: "text/xml" für CDA
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O [0..1]'''||'''O [0..1]'''
|E1||Verweis auf ein referenziertes Dokument
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O [0..1]'''||'''O [0..1]'''
|E1||Typ der Relation zu dem referenzierten Dokument. 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
|}

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

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

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

''Tabelle 7: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" |'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

'''der Studie'''
|'''Attribut'''

'''im KOS'''
|'''Beschreibung'''
|- style="background:white"
| colspan="2" |author
|M [1..1]
| colspan="3" |
|- style="background:white"
| rowspan="6" |
|author.authorInstitution
|M [1..1]
|(0008,0080)
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

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

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

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

'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
|- style="background:white"
| colspan="5" |Die Person, welche die Studie durchführt, ist als author anzugeben:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,1052)
|
|Performing Physicians Identification Sequence

Code und weitere Daten aus dem ersten Item in der Sequence

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

(0008,1050)
|
|Performing Physicians Name

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

'''Achtung:''' Die Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
|- style="background:white"
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,0060) + (0008,0070) + (0008,1090)
|
|Modality Code + Manufacturer + Manufacturer's Model Name

'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
|- style="background:white"
| colspan="2" |creationTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date + Study Time

Für den Fall, dass Study Date und Study Time nicht zur Verfügung stehen, ist es zulässig, den Erstellungszeitpunkt des KOS ((0008,0023) contentDate + (0008,0033) contentTime) als creationTime zu verwenden.
|- style="background:white"
| colspan="2" |eventCodeList
|M [1..*]
|
|
|Enthält eine Liste von Codes von Gesundheitsdienstleistungen nach APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten<nowiki/>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</ref>
|- style="background:white"
|
|eventCodeList DisplayNameList
|M [1..1]
|
|
|Enthält den Display Name des APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom" />
|- style="background:white"
| colspan="2" |serviceStartTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|- style="background:white"
| colspan="2" |sourcePatientId
|M [1..1]
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|- style="background:white"
| colspan="2" |sourcePatientInfo
|M [1..1]
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|Die ELGA Vorgabe empfiehlt, Name, Geburtstag und Geschlecht NICHT anzugeben.
|- style="background:white"
| colspan="2" |title
|M [1..1]
|(0008,0060) + (0008,1030)
|
|Der relevante Modality Code der Studie oder alle Modality Codes der Studie und die Study Description.

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

'''Anmerkung:'''

Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
 
|- style="background:white"
| colspan="2" |uniqueId
|M [1..1]
|
|(0008,0018)
|Die SOP Instance UID des KOS
|- style="background:white"
| colspan="2" |referenceIdList
|M [1..1]
|
|
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|- style="background:white"
| rowspan="2" |
|value mit CXi.5 = "<nowiki>urn:elga:iti:xds:2014: OwnDocument_setId</nowiki>"
|M [1..1]
|(0020,000D) oder ein vergleichbares Attribut
|(0020,000D) oder ein vergleichbares Attribut
|Die setId zur Klammerung aller Versionen eines KOS

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

Eine mögliche Wahl der setId ist die Study Instance UID. Die geeignete Wahl der setId hängt auch vom implementierten Stornoworkflow ab, siehe KOS Leitfaden (Kapitel 8.2.2.)<ref name="KOS-Leitfaden" />
|- style="background:white"
|value mit CXi.5 = "<nowiki>urn:ihe:iti:xds:2013: accession</nowiki>"
|R [0..1]
|(0008,0050) oder ein vergleichbares Attribut wie z.B.

(0040,1001) Requested Procedure ID
 
|(0008,0050)
 
|Die ID, die zur Verlinkung mit dem Befund heranzuziehen ist.

Diese ist mit dem Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' anzugeben.

'''Achtung:'''

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

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

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

Unabhängig von der Wahl des DICOM Attributs ist aber in jedem Fall der Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' zu verwenden.
|- style="background:white"
| colspan="2" |comments
|O [0..1]
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

===author===
Die Person oder Maschine, die das Dokument erstellt hat. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.

Die ''authorInstitution'' benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden können. Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.

*''oid'': OID der Organisation aus dem GDA-Index (muss ermittelt werden)
*''name'': (0008,0080), Institution Name, Name der Organisation als String,
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden. 

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

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

=====Spezifikation=====

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

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

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

concat( 
$name,"^^^^^^^^^", 
$oid,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

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

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

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

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

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

=====Spezifikation für Personen=====

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

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

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

$person = (0008,1050) Performing Physicians Name

$root = OID-Knoten für den Personenidentifikator

concat( 
 $id,"^", 
 $person,"^", 
 $root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>11375^Musterdoc^Josef^Maria^Msc^DIDr^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>

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

concat( 
 $id,"^", 
 $person 
) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf die XCN Komponenten wie in IHE RAD TF-2 Rev.19 2020<ref name="IHERADTF2">IHE Radiology (RAD) Technical Framework Volume 2x Rev.19, 2020 [https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf]</ref>, "Table 4.68.4.1.2.3-3: XCN Data type mapping" vorgegeben.

=====Spezifikation für Software und Geräte=====

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

$Modality = Modality (0008,0060)

$Manufacturer = Manufacturer (0008,0070)

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

concat(

"^",

$Modality,"^",

$Manufacturer,"^",

$ManufacturersModelName

) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^CT^Geräthersteller^Gerätename</Value>
</ValueList>
</Slot>
</Classification></pre>

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

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

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

Beispiel:

*"Radiologie"
*"Modalität"

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

Beispiel:

*"Facharzt für Radiologie"
*"Facharzt für Nuklearmedizin"

=====Spezifikation=====

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

Bsp: Fachärztin/Facharzt für Radiologie 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Fachärztin/Facharzt für Radiologie</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Wenn eine Person als Autor vorhanden ist, '''MUSS''' der Wert einem DisplayName aus dem Value Set "ELGA_AuthorSpeciality" entsprechen.

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

{{EndYellowBox}}

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

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Objektklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Objektklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#typeCode_.28und_typeCodeDisplayName.29|typeCode]]
|}

====Spezifikation====

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

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

$code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
classifiedObject="theDocument" nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===confidentialityCode===
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.

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

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

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

====Spezifikation====

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

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

<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="theDocument" nodeRepresentation="N">
<Name>
<LocalizedString value="normal"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:2.16.840.1.113883.5.25</Value>
</ValueList>
</Slot>
</Classification></pre>

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

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

Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From ''UTC''<ref>Timezone Offset From UTC http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</ref> berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

====Spezifikation====

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

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

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

concat(

$date,

$time

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="creationTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.{{EndYellowBox}}

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

====Spezifikation====

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

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

$code = APPC code (alle Achsen) z.B. "2.4.0.5-3-3" 
$displayName = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule" 
$codeSystem = OID des Codesystems APPC: 1.2.40.0.34.5.38 
<pre class="ilfbox_code">
<Classification
classificationScheme=
"urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
classifiedObject="theDocument"
nodeRepresentation="$code">
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
<Name>
<LocalizedString value="$displayName"/>
</Name>
</Classification>
</pre>

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

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

Fester Wert "de-AT"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/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===
Dieses Element darf für XDS-I nicht verwendet werden [NP].

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

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

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

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

concat(

Study Date,

Study Time + Timezone Offset from UTC

)
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="serviceStartTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

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

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

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

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

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

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

$patientID = (0010,0020) Patient ID

$oid = OID des lokalen Patientenidentifikators

concat(

$patientID,

"^^^&amp;",

$oid,

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.
{{BeginYellowBox}}
In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
{{EndYellowBox}}

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

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

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modality Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. ("CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule")
{{BeginYellowBox}}
'''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
{{EndYellowBox}}
====Spezifikation====

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

concat(

Modality,

" ",

Study Description

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Name>
<LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" />
</Name>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
{{EndYellowBox}}

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

Unterscheidung typeCode/classCode:
{| class="wikitable"
|- style="background:white"
|'''typeCode'''
|'''Objektklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
|classCode
|Objektklasse in grober Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29|classCode]]
|}

====Spezifikation====

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

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

 $code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="KeyImageObject"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

$code = "55113-5"

$displayName = "Key images Document Radiology"

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

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

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

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

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

$value = (0008,0018) SOP Instance UID

<pre class="ilfbox_code">
<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. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:

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

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

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

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

{| 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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}
{{BeginYellowBox}}

'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.
{{EndYellowBox}}

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

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

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

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

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

concat

(

$id, "^^^^",

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

"&amp;",

$homeCommunityId, "&amp;ISO"

)

Wie oben angeführt wird folgender CXi Wert für <Value> erstellt:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.

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

=====Spezifikation=====
Bei der Registrierung von KOS Objekten SOLL eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden. Diese dient als Basis für die Verlinkung mit einem Befund der bildgebenden Diagnostik (diagnostic image report). Wird in der ReferenceIdList der XDS-I Metadaten keine Accession Number angeführt, ist eine Verlinkung nicht möglich.

Für Befunde der Bildgebenden Diagnostik (diagnostic image report) kann die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Accession Number z.B. 20201111

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

concat

(

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

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

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"

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

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

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

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

$id = Aufenthaltszahl z.B. Az123456

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

concat

(

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

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

"<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>Az123456^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.4613.3.4<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>
</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

*'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki>. In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.
*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki>

Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId
</nowiki>^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
<Value>20201111^^^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
<Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value>
<Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===intendedRecipient===
Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der ''intendedRecipient'' notwendig. Derzeit wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.

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

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

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

====Spezifikation====
Comments wird gemäß folgender Vorschrift zusammengesetzt:
$comment = (0008,1030) Study Description<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Description">
<LocalizedString value = "$comment"/>
</Description>
</ExtrinsicObject>
</pre> 

==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
===availabilityStatus===
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Objektes.

Mögliche Werte laut IHE sind:

*Approved
*Deprecated

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

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

<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

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

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

===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA, z.B.

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

Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]".
{{EndYellowBox}}

====Spezifikation====

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

$code = Klassifizierung des GDA (Code)

$displayName = Klartext des angegebenen Codes

$codeSystem = OID der ausgebenden Stelle

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

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

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

====Spezifikation====

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

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

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

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

*F044 "Radiologie"
*F052 "Unfallchirurgie"

Im KOS-Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_PracticeSetting_VS ELGA_PracticeSetting_VS]".
{{EndYellowBox}}

====Spezifikation====

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

$code = Code aus Value Set ELGA_PracticeSetting $displayName = Klartext des angegebenen Codes (displayName) $codeSystem = OID des Codesystems (1.2.40.0.34.5.12) 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

Für KOS Objekte wird der fixe Wert "<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="application/dicom"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

==ELGA-spezifische Erweiterungen der XDS-Metadaten==
Die folgenden Daten entsprechen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information.

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

*"true" oder
*"false"

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

====Spezifikation====

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

===elgaHash===
Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot "ELGA-Hash" gespeichert.

Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.

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

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

==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).

CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen.

====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurde.

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

#Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört, grundsätzlich in folgendem Element abgelegt:
##ClinicalDocument/author/assignedAuthor/representedOrganization
#Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:
##'''id'''[1] … ID der Organisation mit den folgenden Attributen:
###@root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)
###@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)
##'''name''' … Name der Organisation als String Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.
#GDA, in deren Gültigkeitsbereich Dokumente erstellt werden können, sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da es vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden.
{{EndYellowBox}}

=====Spezifikation=====

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

$inst … ClinicalDocument/author/assignedAuthor/representedOrganization

*Fall 1: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist nicht vorhanden 

concat( 
$inst/name,"^^^^^^^^^", 
$inst/id[1]/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO</Value>
</ValueList>
</Slot>
</Classification>
</pre>

*Fall 2: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist vorhanden 

concat( 
$inst/name,"^^^^^&", 
$inst/id[1]/@root,"&ISO^^^^" 
$inst/id[1]/@extension 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&amp;ISO^^^^45</Value>
</ValueList>
</Slot>
</Classification>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

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

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

#Laut Festlegung wird der Autor im Header-Element "author" abgelegt:
##ClinicalDocument/author/assignedAuthor
#Der Autor (Person)
##Ein Personenelement enthält unter anderem die folgenden Unterelemente:
###id … ID der Person mit den folgenden Attributen:
####@root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
####@extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
###assignedPerson
####Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
#####name
#Gerät oder Software als Autor
##Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:
###assignedAuthoringDevice
####Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software
#####manufacturerModelName
####Enthält ein Element mit dem Namen des Geräts oder der Software
#####softwareName

=====Spezifikation für Personen=====

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

 $person = ClinicalDocument/author/assignedAuthor

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
{{BeginYellowBox}}
Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.
{{EndYellowBox}}
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

=====Spezifikation für Software und Geräte=====

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

 $person = ClinicalDocument/author/assignedAuthor

concat( 
"^", 
 $person/assignedAuthoringDevice/manufacturerModelName,"^", 
 $person/assignedAuthoringDevice/softwareName 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^Good Health System^Best Health Software Application</Value>
</ValueList>
</Slot>
</Classification></pre>

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

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.

Beispiel:

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

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

#Laut Festlegung wird die "Rolle" der Person, welche das Dokument inhaltlich erstellt hat, im Element functionCode des Autors abgelegt:
##''ClinicalDocument/author/functionCode''
#Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.

=====Spezifikation=====

'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/functionCode/@displayName 
<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorRole">
<ValueList>
<Value>Diensthabender Oberarzt</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.

Beispiel:

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

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

#Laut Festlegung wird die "Fachrichtung" der Person, welche das Dokument inhaltlich erstellt hat, im Element code des Autors abgelegt:
##''ClinicalDocument/author/assignedAuthor/code''
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.

=====Spezifikation=====

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

ClinicalDocument/author/assignedAuthor/code/@displayName 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Anästhesiologie und Intensivmedizin</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

===classCode (und classCodeDisplayName)===
Das ''classCode'' Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Dokumentenklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Dokumentenklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2|typeCode]]
|}

====Spezifikation====

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

$code = ClinicalDocument/code/translation/@code 
$displayName = ClinicalDocument/code/translation/@displayName 
$codeSystem = ClinicalDocument/code/translation/@codeSystem 
<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: 

<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.
Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

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

#Im CDA wird dieser Zeitpunkt wie folgt abgelegt:
##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:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
CreationTime entfällt bei On-Demand Documents.
{{EndYellowBox}}

====Spezifikation====

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 
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: 

Für jedes documentationOf Element 1..n: 

$code = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code 
$displayName = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName 
$codeSystem = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem 
<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: 

 $person = ClinicalDocument/legalAuthenticator/assignedEntity

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<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) Achtung: Diese ID gelangt nicht in die Metadaten!

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

 $code = ClinicalDocument/code/@code 
 $displayName = ClinicalDocument/code/@displayName 
 $codeSystem = ClinicalDocument/code/@codeSystem 
<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: 

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

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

Fall 2 
Attribut ClinicalDocument/id/@extension ist vorhanden

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

<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..1])
#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).

{{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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}

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

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

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

 

===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: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = ClinicalDocument/hl7at:formatCode/@displayName 
$codeSystem = 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:

$code = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code

$displayName = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName

$codeSystem = 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: 
CDA R2: '''text/xml''' 

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

$code = ClinicalDocument/hl7at:practiceSettingCode/@code 
$displayName = ClinicalDocument/hl7at:practiceSettingCode/@displayName 
$codeSystem = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem 
<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"18. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:

*"true" oder
*"false"
18 Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.
====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=

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

ILF:XDS Metadaten (Version 3)

2021-03-26T07:45:31Z

Kuttin: /* Spezifikation */

{{#seo:
|title=XDS Metadaten 3.0.0
|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 (Version 3.0.0)}}



{{#css:
@media screen{
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.toc{
width: 20%;
float: right !important;
margin: 10px 0px 10px 30px !important;
border: 1px solid #AAA;
background-color: #F9F9F9;
display: table;
padding: 7px !important;
}
}
}}

{{Infobox Dokument
|Group = ELGA CDA Implementierungsleitfäden
|Title = ELGA XDS Metadaten (XDSDocumentEntry)
|Subtitle = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA [1.2.40.0.34.7.6.9.3]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0+20210324
|Submitted = ELGA GmbH
|Date = März 2021
|Copyright = 2011-
|Status = Reconciliation
|Period = n.a.
|OID = 1.2.40.0.34.7.6.9.3
|Realm = Austria
}}

{{TOC limit|4}}



{{#css:
.orange{
border: thin black solid;
background-color:#F4C789;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
}
}}

=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;">
==Impressum==
<div class="mw-collapsible-content">
''Medieneigentümer, Herausgeber, Hersteller, Verleger:'' 
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050 
Internet: [http://www.elga.gv.at www.elga.gv.at]
Email: [mailto:cda@elga.gv.at cda@elga.gv.at] 
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch

''Redaktion, Projektleitung, Koordination: '' 
Mag.Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]

''Abbildungen:'' Sofern nicht anders angegeben: © ELGA GmbH

''Nutzung'': Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria [http://www.hl7.at www.hl7.at]. 
Die Nutzung ist ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter [https://www.gesundheit.gv.at www.gesundheit.gv.at] und [https://www.elga.gv.at/cda www.elga.gv.at/cda]
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

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

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

==Sprachliche Gleichbehandlung==
<div class="mw-collapsible-content">
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer, Frauen und andere Geschlechtsidentitäten in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
</div></div>

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

Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> .

===Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")===
<div style="border: thin #77c123 solid;width:100%; margin-left: 10px">
<div style="line-height: 1.25; font-size:16px; border-bottom: 1px solid #81ab1f; box-shadow: 0 4px 0 0 #a2d727;margin-bottom:4px; color:#77c123; width:100%">
Third Party Intellectual Property
</div>
<div style="width:100%;">


Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass der Herausgeber nicht alle Rechte und Ansprüche in und an den Materialien besitzt und dass die Materialien geistiges Eigentum von Dritten enthalten und / oder darauf verweisen können ("Third Party Intellectual Property (IP)"). 

Die Anerkennung dieser Lizenzbestimmungen gewährt dem Lizenznehmer keine Rechte in Bezug auf Third Party IP. Der Lizenznehmer allein ist für die Identifizierung und den Erhalt von notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig verantwortlich. 

Jegliche Handlungen, Ansprüche oder Klagen eines Dritten, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, bleiben die Haftung des Lizenznehmers.

</div>
</div>

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

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

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

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

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

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

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website: [[ILF: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 ([http://www.elga.gv.at/CDA Website der ELGA GmbH]) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:

*ELGA-Gesamtarchitektur<ref name="ELGA-Gesamtarchitektur">ELGA-Gesamtarchitektur 2.30a [http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>
*Beispieldokumente
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
*CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
*Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
*Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
*Hinweise für die zu verwendenden Terminologien
*Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}

==Bedienungshinweise==
===Farbliche Hervorhebungen===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''<Hinweis>''' authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
{{EndYellowBox}}
''Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>
''Verweis auf ELGA Value Set:''
{{BeginILFBox}}
'''<Verweis>''' Zulässige Werte gemäß Value Set '''"ELGA_FormatCode".'''
{{EndILFBox}}

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

===PDF-Navigation===
<div class="mw-collapsible-content">
Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

*Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
*Seitenweise blättern: "Bild" Tasten
*Scrollen: Pfeil nach oben bzw. unten
*Zoomen: Strg + Mouserad drehen
*Suchen im Dokument: Strg + F
</div></div>



=Harmonisierung=
'''Erarbeitung des Implementierungsleitfadens''' 
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%" |Person1
|- 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
|}

1 Namen ohne Titel


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

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.

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

==Hinweise zur Verwendung des Dokuments==
===Codesysteme und Value Sets===
Die in diesem Dokument erwähnten Codesysteme bzw. Value Sets werden am Terminologieserver (https://www.gesundheit.gv.at/gesundheitssystem/professional/it-services/terminologieserver-doku) und auf der Website der ELGA GmbH (http://www.elga.gv.at) veröffentlicht.

Wenn codierte Werte angegeben werden, ist es immer die Aufgabe des Document Consumers, die korrekten lesbaren Werte anzuzeigen. Es wird nicht empfohlen, die in den XDS-Metadaten verfügbaren DisplayNames direkt zur Anzeige zur verwenden, da Schreibweisen der DisplayNames variieren oder in unterschiedlichen Sprachen angegeben sein können.

===OID ===
In diesem Dokument wird an vielen Stellen die Verwendung von OID vorgeschrieben. OID sind Objekt-Identifikatoren oder Objektkennungen, die als weltweit eindeutige Namen für Informationsobjekte dienen (ISO/IEC 9834-1). Weitere Informationen zur Verwendung und Registrierung von OID sind im "OID-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.

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

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

====Bereitstellen [ITI-41] und Veröffentlichen [ITI-42]====
Ein neues Dokument wird entsprechend IHE XDS im Repository gespeichert und durch Registrieren der XDS-Metadaten in der Registry für ELGA bereitgestellt. Neu veröffentlichte Dokument-Metadaten werden immer mit dem Status "approved" versehen.

====Ersetzen eines Dokuments durch eine neue Version ("Updaten") [ITI-41]====
Änderungen eines für ELGA bereitgestellten Dokumentes sind NICHT ERLAUBT.

Es ist allerdings möglich, ein Dokument durch ein anderes zu ersetzen, indem ein neues Dokument (bzw. eine neue Version des Dokumentes) gespeichert und registriert wird. Hierbei MUSS die SetId der referenceIdList in den XDS-Metadaten zum neuen Dokument der der Vorgängerversion entsprechen. Die XDS-Metadaten der Vorgängerversion des Dokumentes bekommen den Status "deprecated". In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp "replace" (RPLC)).

Beim Ersetzen von ELGA Dokumenten wird das ELGA Berechtigungssystem eventuell zugeordnete individuelle Zugriffsberechtigungen unabhängig von ihrer Anzahl auch auf die Nachfolgeversionen anwenden.

====Stornieren [ITI-57, XDS Metadata Update]====
Dokumente werden "storniert", indem der Dokumentstatus auf "deprecated" gesetzt wird und keine neue Dokumentenversion registriert wird.

===Größenbeschränkung ===
ELGA schreibt für die Größe der eingebrachten CDA eine Maximalgröße von 20 MB vor. Größere Dokumente sind abzulehnen. Es liegt generell in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten |Allgemeiner Implementierungsleitfaden
für ELGA CDA Dokumente, Kapitel 6.10]].

==Allgemeines zu XDS-Metadaten==
Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumente entsprechend klassifiziert und beschrieben werden. Diese beschreibenden "Metadaten" werden in Form einer Nachricht gemeinsam mit dem Dokument an das Repository mitgegeben. Da IHE XDS Systeme grundsätzlich für beliebige Dokumentformate offen sind, gilt dies für alle Arten von Dokumenten (CDA, PDF, Bilder, etc.) gleichermaßen.

Die Metadaten eines Dokuments (XDSDocumentEntry) in einem IHE XDS System beinhalten Informationen
* über das Dokument selbst – um eine Klassifizierung und eine korrekte Darstellung des Dokumenteninhalts zu ermöglichen
* über eventuelle Beziehungen zu anderen Dokumenten (z.B. zu älteren Versionen eines Dokuments)
* über den Speicherort des Dokuments
* über den GDA, welcher das Dokument erstellt hat
* über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).
Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE "IT-Infrastructure" (ITI) Technical Framework, Volume 3 festgelegt (IHE ITI TF-3)<ref name="ITITF3"/>.

Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.
{{BeginYellowBox}}
Die Metadaten sind die ausschließliche Grundlage für das Suchen und Filtern von Dokumenten in einem XDS Dokumentenregister und somit im ELGA Verweisregister, daher ist die korrekte Verschlagwortung der Dokumente mit den Metadaten eine notwendige Voraussetzung.
{{EndYellowBox}}

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

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

===Metadaten aus strukturierten Dokumenten (CDA)===
Strukturierte Dokumente bieten die Möglichkeit, die Informationen für die Metadaten beim Einbringen in ein Repository in gewissem Maße aus den Dokumenten selbst automatisiert zu entnehmen. Das vermindert daher die Menge der Informationen, die separat erhoben oder ermittelt werden muss.

Die IHE hat im Rahmen des "Patient Care Coordination" (PCC) Technical Frameworks eine genaue Vorschrift spezifiziert, aus welchen Bereichen des CDA Dokuments die Metadaten entnommen werden sollen.

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

===Metadaten aus "On-Demand Documents" (ODD) ===
Ü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"/>.

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

===XDS Metadaten im Vergleich IHE vs. ELGA===
Die vollständige Liste der XDS Metadaten Elemente kann man in folgende Arten von Elementen unterteilen:
# Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
# Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)
# '''Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können (XDS Document Source)'''
# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
## '''ELGA relevante'''
## Nicht ELGA relevante
Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).

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

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

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

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

{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|K||Aus KOS-Inhalt abgeleitet
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- style="background:#white"
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
|}

''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" |'''Metadaten Element'''
|'''Optionalität'''
|'''Quelle'''
|'''Beschreibung'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''M [1..1]'''
|<nowiki>-</nowiki>
|Die Person oder das Gerät, welche(s) das Dokument verfasst hat
|-
| rowspan="4" |
|authorInstitution
|'''M [1..1]'''
|E1/K
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|-
|authorPerson
|'''R [0..1]'''
|K
|Daten der Person

(Name, ID, etc.)
|-
|authorRole
|'''R [0..1]'''
|K
|Rolle der Person
|-
|authorSpeciality
|'''R [0..1]'''
|E1/K
|Fachrichtung der Person
|-
| colspan="2" |'''classCode'''
|'''M [1..1]'''
|A
|Dokumenten/Objektklasse (Oberklasse)

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

codierter Wert
|-
| colspan="2" |'''uniqueId'''
|'''M [1..1]'''
|K
|Global eindeutige ID des Objektes

z.B. SOP Instance UID
|-
| colspan="2" |'''referenceIdList'''
|'''M [1..*]'''
|K/E1
|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|-
| colspan="5" |'''''Explizit zu setzende Metadaten'''''
|-
| colspan="2" |'''availabilityStatus'''
|'''M [1..1]'''
|E1
|Gültigkeit des Objektes
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|E1
|Format des Objektes
|-
| colspan="2" |'''healthcareFacilityTypeCode'''
|'''M [1..1]'''
|E1
|Klassifizierung des GDA
|-
| colspan="2" |'''mimeType'''
|'''M [1..1]'''
|E1
|Mime Type des Dokuments

Fester Wert für KOS: "application/dicom"
|-
| colspan="2" |'''parentDocumentId'''
|'''O [0..1]'''
|E1
|Verweis auf ein referenziertes Objekt
|-
| colspan="2" |'''parentDocumentRelationship'''
|'''O [0..1]'''
|E1
|Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC, XFRM
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|E1
|Fachliche Zuordnung des Dokuments
|-
| colspan="2" |'''entryUUID'''
|'''M [1..1]'''
|E1
|UUID des Metadaten-Records des Dokuments(XDS DocumentEntry)
|-
| colspan="2" |'''objectType'''
|'''M [1..1]'''
|E1
|Typ des DocumentEntries

Fester Wert "SD"
|-
| colspan="2" |'''comments'''
|'''O [0..1]'''
|K
|Kommentar zum Dokument/Objekt
|-
| colspan="2" |'''patientId'''
|'''M [1..1]'''
|E1
|Patienten-ID in der XDS Affinity Domain
|-
| colspan="5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|-
| colspan="2" |'''hash'''
|'''M [1..1]'''
|A
|Hash Wert des Dokuments. Wird vom Repository befüllt
|-
| colspan="2" |'''homeCommunityId'''
|'''M [1..1]'''
|A
|Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.
|-
| colspan="2" |'''repositoryUniqueId'''
|'''M [1..1]'''
|A
|Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
|-
| colspan="2" |'''size'''
|'''M [1..1]'''
|A
|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository befüllt.
 
|-
| colspan="2" |'''URI'''
|'''NP [0..0]'''[[#%20ftn1|<nowiki/>]][[#%20ftn1|<nowiki/>]]
|A
|Wird in XDS-I nicht verwendet
|-
|-
| colspan="5" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|-
| colspan="2" |'''elgaFlag'''
|'''M [1..1]'''
|B
|Kennzeichnet ein Dokument als "ELGA-Dokument"
|-
| colspan="2" |'''elgaHash'''
|'''M [1..1]'''
|B
|Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes
|}
 [[#%20ftn1|<nowiki/>]]

 


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

In der Tabelle 6 werden die XDS-Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität), jeweils für Stable Documents (SD) und On-Demand-Documents (ODD) angegeben.

''Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|C||Aus CDA-Inhalt abgeleitet (direkt oder indirekt, gilt nicht für On-Demand-Documents)
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- 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="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 6: Überblick XDS Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''
| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''
| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
| rowspan="2" style="text-align:left" |'''Beschreibung '''
|- style="background:#CBD7F1"
|'''SD'''9||'''ODD'''10
|- style="background:#CBD7F1"
| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''
|- style="background:white"
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''M [1..1]'''||'''M [1..1]'''
|C||Die Person, welche das Dokument verfasst hat
|- style="background:white"
| ||authorInstitution||'''M [1..1]'''||'''M [1..1]'''
|C||ID und Name der Organisation (Kurzbezeichnung), der die Person angehört, wie im GDA-Index angegeben.
|- style="background:white"
| ||authorPerson||'''M [1..1]'''||'''M [1..1]'''
|C||Daten der Person (Name, ID, etc.)
|- style="background:white"
| ||authorRole||'''R [0..1]'''||'''NP [0..0]'''
|C||Rolle der Person
|- style="background:white"
| ||authorSpeciality||'''R [0..1]'''||'''NP [0..0]'''
|C||Fachrichtung der Person
|- style="background:white"
| colspan="2" |'''classCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Vertraulichkeitscode des Dokuments
|- style="background:white"
| colspan="2" |'''creationTime'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R [0..*]'''||'''R [0..*]'''
|C||Liste von Gesundheitsdienstleistungen
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Format des Dokumenteninhalts
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O [0..1]'''||'''NP [0..0]'''
|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.
|- style="background:white"
| colspan="2" |'''languageCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Sprachcode des Dokuments z.B.: "de-AT"
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R [0..1]'''||'''NP [0..0]'''
|C||Rechtlicher Unterzeichner des Dokuments
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Fachliche Zuordnung des Dokuments
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''NP [0..0]'''||'''NP [0..0]'''
|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)
|- style="background:white"
| colspan="2" |'''Title'''||'''M [1..1]'''||'''M [1..1]'''
|C||Titel des Dokuments
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Global eindeutige ID des Dokuments
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''M [1..1]'''||'''O [0..1]'''
|C||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''M [1..1]'''||'''M [1..1]'''
|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 z.B.: "text/xml" für CDA
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O [0..1]'''||'''O [0..1]'''
|E1||Verweis auf ein referenziertes Dokument
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O [0..1]'''||'''O [0..1]'''
|E1||Typ der Relation zu dem referenzierten Dokument. 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
|}

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

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

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

''Tabelle 7: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" |'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

'''der Studie'''
|'''Attribut'''

'''im KOS'''
|'''Beschreibung'''
|- style="background:white"
| colspan="2" |author
|M [1..1]
| colspan="3" |
|- style="background:white"
| rowspan="6" |
|author.authorInstitution
|M [1..1]
|(0008,0080)
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

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

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

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

'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
|- style="background:white"
| colspan="5" |Die Person, welche die Studie durchführt, ist als author anzugeben:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,1052)
|
|Performing Physicians Identification Sequence

Code und weitere Daten aus dem ersten Item in der Sequence

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

(0008,1050)
|
|Performing Physicians Name

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

'''Achtung:''' Die Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
|- style="background:white"
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,0060) + (0008,0070) + (0008,1090)
|
|Modality Code + Manufacturer + Manufacturer's Model Name

'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
|- style="background:white"
| colspan="2" |creationTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date + Study Time

Für den Fall, dass Study Date und Study Time nicht zur Verfügung stehen, ist es zulässig, den Erstellungszeitpunkt des KOS ((0008,0023) contentDate + (0008,0033) contentTime) als creationTime zu verwenden.
|- style="background:white"
| colspan="2" |eventCodeList
|M [1..*]
|
|
|Enthält eine Liste von Codes von Gesundheitsdienstleistungen nach APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten<nowiki/>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</ref>
|- style="background:white"
|
|eventCodeList DisplayNameList
|M [1..1]
|
|
|Enthält den Display Name des APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom" />
|- style="background:white"
| colspan="2" |serviceStartTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|- style="background:white"
| colspan="2" |sourcePatientId
|M [1..1]
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|- style="background:white"
| colspan="2" |sourcePatientInfo
|M [1..1]
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|Die ELGA Vorgabe empfiehlt, Name, Geburtstag und Geschlecht NICHT anzugeben.
|- style="background:white"
| colspan="2" |title
|M [1..1]
|(0008,0060) + (0008,1030)
|
|Der relevante Modality Code der Studie oder alle Modality Codes der Studie und die Study Description.

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

'''Anmerkung:'''

Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
 
|- style="background:white"
| colspan="2" |uniqueId
|M [1..1]
|
|(0008,0018)
|Die SOP Instance UID des KOS
|- style="background:white"
| colspan="2" |referenceIdList
|M [1..1]
|
|
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|- style="background:white"
| rowspan="2" |
|value mit CXi.5 = "<nowiki>urn:elga:iti:xds:2014: OwnDocument_setId</nowiki>"
|M [1..1]
|(0020,000D) oder ein vergleichbares Attribut
|(0020,000D) oder ein vergleichbares Attribut
|Die setId zur Klammerung aller Versionen eines KOS

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

Eine mögliche Wahl der setId ist die Study Instance UID. Die geeignete Wahl der setId hängt auch vom implementierten Stornoworkflow ab, siehe KOS Leitfaden (Kapitel 8.2.2.)<ref name="KOS-Leitfaden" />
|- style="background:white"
|value mit CXi.5 = "<nowiki>urn:ihe:iti:xds:2013: accession</nowiki>"
|R [0..1]
|(0008,0050) oder ein vergleichbares Attribut wie z.B.

(0040,1001) Requested Procedure ID
 
|(0008,0050)
 
|Die ID, die zur Verlinkung mit dem Befund heranzuziehen ist.

Diese ist mit dem Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' anzugeben.

'''Achtung:'''

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

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

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

Unabhängig von der Wahl des DICOM Attributs ist aber in jedem Fall der Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' zu verwenden.
|- style="background:white"
| colspan="2" |comments
|O [0..1]
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

===author===
Die Person oder Maschine, die das Dokument erstellt hat. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.

Die ''authorInstitution'' benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden können. Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.

*''oid'': OID der Organisation aus dem GDA-Index (muss ermittelt werden)
*''name'': (0008,0080), Institution Name, Name der Organisation als String,
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden. 

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

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

=====Spezifikation=====

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

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

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

concat( 
$name,"^^^^^^^^^", 
$oid,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

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

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

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

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

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

=====Spezifikation für Personen=====

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

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

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

$person = (0008,1050) Performing Physicians Name

$root = OID-Knoten für den Personenidentifikator

concat( 
 $id,"^", 
 $person,"^", 
 $root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>11375^Musterdoc^Josef^Maria^Msc^DIDr^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>

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

concat( 
 $id,"^", 
 $person 
) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf die XCN Komponenten wie in IHE RAD TF-2 Rev.19 2020<ref name="IHERADTF2">IHE Radiology (RAD) Technical Framework Volume 2x Rev.19, 2020 [https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf]</ref>, "Table 4.68.4.1.2.3-3: XCN Data type mapping" vorgegeben.

=====Spezifikation für Software und Geräte=====

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

$Modality = Modality (0008,0060)

$Manufacturer = Manufacturer (0008,0070)

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

concat(

"^",

$Modality,"^",

$Manufacturer,"^",

$ManufacturersModelName

) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^CT^Geräthersteller^Gerätename</Value>
</ValueList>
</Slot>
</Classification></pre>

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

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

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

Beispiel:

*"Radiologie"
*"Modalität"

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

Beispiel:

*"Facharzt für Radiologie"
*"Facharzt für Nuklearmedizin"

=====Spezifikation=====

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

Bsp: Fachärztin/Facharzt für Radiologie 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Fachärztin/Facharzt für Radiologie</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Wenn eine Person als Autor vorhanden ist, '''MUSS''' der Wert einem DisplayName aus dem Value Set "ELGA_AuthorSpeciality" entsprechen.

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

{{EndYellowBox}}

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

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Objektklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Objektklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#typeCode_.28und_typeCodeDisplayName.29|typeCode]]
|}

====Spezifikation====

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

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

$code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
classifiedObject="theDocument" nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===confidentialityCode===
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.

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

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

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

====Spezifikation====

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

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

<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="theDocument" nodeRepresentation="N">
<Name>
<LocalizedString value="normal"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:2.16.840.1.113883.5.25</Value>
</ValueList>
</Slot>
</Classification></pre>

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

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

Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From ''UTC''<ref>Timezone Offset From UTC http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</ref> berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

====Spezifikation====

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

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

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

concat(

$date,

$time

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="creationTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.{{EndYellowBox}}

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

====Spezifikation====

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

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

$code = APPC code (alle Achsen) z.B. "2.4.0.5-3-3" 
$displayName = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule" 
$codeSystem = OID des Codesystems APPC: 1.2.40.0.34.5.38 
<pre class="ilfbox_code">
<Classification
classificationScheme=
"urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
classifiedObject="theDocument"
nodeRepresentation="$code">
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
<Name>
<LocalizedString value="$displayName"/>
</Name>
</Classification>
</pre>

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

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

Fester Wert "de-AT"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/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===
Dieses Element darf für XDS-I nicht verwendet werden [NP].

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

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

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

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

concat(

Study Date,

Study Time + Timezone Offset from UTC

)
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="serviceStartTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

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

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

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

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

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

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

$patientID = (0010,0020) Patient ID

$oid = OID des lokalen Patientenidentifikators

concat(

$patientID,

"^^^&amp;",

$oid,

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.
{{BeginYellowBox}}
In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
{{EndYellowBox}}

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

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

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modality Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. ("CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule")
{{BeginYellowBox}}
'''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
{{EndYellowBox}}
====Spezifikation====

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

concat(

Modality,

" ",

Study Description

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Name>
<LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" />
</Name>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
{{EndYellowBox}}

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

Unterscheidung typeCode/classCode:
{| class="wikitable"
|- style="background:white"
|'''typeCode'''
|'''Objektklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
|classCode
|Objektklasse in grober Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29|classCode]]
|}

====Spezifikation====

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

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

 $code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="KeyImageObject"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

$code = "55113-5"

$displayName = "Key images Document Radiology"

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

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

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

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

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

$value = (0008,0018) SOP Instance UID

<pre class="ilfbox_code">
<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. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:

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

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

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

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

{| 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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}
{{BeginYellowBox}}

'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.
{{EndYellowBox}}

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

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

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

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

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

concat

(

$id, "^^^^",

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

"&amp;",

$homeCommunityId, "&amp;ISO"

)

Wie oben angeführt wird folgender CXi Wert für <Value> erstellt:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.

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

=====Spezifikation=====
Bei der Registrierung von KOS Objekten SOLL eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden. Diese dient als Basis für die Verlinkung mit einem Befund der bildgebenden Diagnostik (diagnostic image report). Wird in der ReferenceIdList der XDS-I Metadaten keine Accession Number angeführt, ist eine Verlinkung nicht möglich.

Für Befunde der Bildgebenden Diagnostik (diagnostic image report) kann die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Accession Number z.B. 20201111

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

concat

(

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

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

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"

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

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

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

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

$id = Aufenthaltszahl z.B. Az123456

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

concat

(

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

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

"<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>Az123456^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.4613.3.4<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>
</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

*'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki>. In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.
*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki>

Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId
</nowiki>^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
<Value>20201111^^^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
<Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value>
<Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===intendedRecipient===
Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der ''intendedRecipient'' notwendig. Derzeit wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.

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

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

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

====Spezifikation====
Comments wird gemäß folgender Vorschrift zusammengesetzt:
$comment = (0008,1030) Study Description<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Description">
<LocalizedString value = "$comment"/>
</Description>
</ExtrinsicObject>
</pre> 

==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
===availabilityStatus===
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Objektes.

Mögliche Werte laut IHE sind:

*Approved
*Deprecated

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

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

<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

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

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

===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA, z.B.

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

Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]".
{{EndYellowBox}}

====Spezifikation====

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

$code = Klassifizierung des GDA (Code)

$displayName = Klartext des angegebenen Codes

$codeSystem = OID der ausgebenden Stelle

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

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

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

====Spezifikation====

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

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

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

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

*F044 "Radiologie"
*F052 "Unfallchirurgie"

Im KOS-Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_PracticeSetting_VS ELGA_PracticeSetting_VS]".
{{EndYellowBox}}

====Spezifikation====

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

$code = Code aus Value Set ELGA_PracticeSetting $displayName = Klartext des angegebenen Codes (displayName) $codeSystem = OID des Codesystems (1.2.40.0.34.5.12) 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

Für KOS Objekte wird der fixe Wert "<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="application/dicom"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

==ELGA-spezifische Erweiterungen der XDS-Metadaten==
Die folgenden Daten entsprechen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information.

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

*"true" oder
*"false"

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

====Spezifikation====

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

===elgaHash===
Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot "ELGA-Hash" gespeichert.

Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.

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

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

==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).

CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen.

====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurde.

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

#Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört, grundsätzlich in folgendem Element abgelegt:
##ClinicalDocument/author/assignedAuthor/representedOrganization
#Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:
##'''id'''[1] … ID der Organisation mit den folgenden Attributen:
###@root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)
###@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)
##'''name''' … Name der Organisation als String Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.
#GDA, in deren Gültigkeitsbereich Dokumente erstellt werden können, sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da es vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden.
{{EndYellowBox}}

=====Spezifikation=====

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

$inst … ClinicalDocument/author/assignedAuthor/representedOrganization

*Fall 1: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist nicht vorhanden 

concat( 
$inst/name,"^^^^^^^^^", 
$inst/id[1]/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO</Value>
</ValueList>
</Slot>
</Classification>
</pre>

*Fall 2: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist vorhanden 

concat( 
$inst/name,"^^^^^&", 
$inst/id[1]/@root,"&ISO^^^^" 
$inst/id[1]/@extension 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&amp;ISO^^^^45</Value>
</ValueList>
</Slot>
</Classification>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

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

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

#Laut Festlegung wird der Autor im Header-Element "author" abgelegt:
##ClinicalDocument/author/assignedAuthor
#Der Autor (Person)
##Ein Personenelement enthält unter anderem die folgenden Unterelemente:
###id … ID der Person mit den folgenden Attributen:
####@root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
####@extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
###assignedPerson
####Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
#####name
#Gerät oder Software als Autor
##Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:
###assignedAuthoringDevice
####Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software
#####manufacturerModelName
####Enthält ein Element mit dem Namen des Geräts oder der Software
#####softwareName

=====Spezifikation für Personen=====

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

 $person = ClinicalDocument/author/assignedAuthor

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
{{BeginYellowBox}}
Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.
{{EndYellowBox}}
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

=====Spezifikation für Software und Geräte=====

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

 $person = ClinicalDocument/author/assignedAuthor

concat( 
"^", 
 $person/assignedAuthoringDevice/manufacturerModelName,"^", 
 $person/assignedAuthoringDevice/softwareName 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^Good Health System^Best Health Software Application</Value>
</ValueList>
</Slot>
</Classification></pre>

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

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.

Beispiel:

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

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

#Laut Festlegung wird die "Rolle" der Person, welche das Dokument inhaltlich erstellt hat, im Element functionCode des Autors abgelegt:
##''ClinicalDocument/author/functionCode''
#Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.

=====Spezifikation=====

'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/functionCode/@displayName 
<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorRole">
<ValueList>
<Value>Diensthabender Oberarzt</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.

Beispiel:

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

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

#Laut Festlegung wird die "Fachrichtung" der Person, welche das Dokument inhaltlich erstellt hat, im Element code des Autors abgelegt:
##''ClinicalDocument/author/assignedAuthor/code''
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.

=====Spezifikation=====

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

ClinicalDocument/author/assignedAuthor/code/@displayName 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Anästhesiologie und Intensivmedizin</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

===classCode (und classCodeDisplayName)===
Das ''classCode'' Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Dokumentenklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Dokumentenklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2|typeCode]]
|}

====Spezifikation====

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

$code = ClinicalDocument/code/translation/@code 
$displayName = ClinicalDocument/code/translation/@displayName 
$codeSystem = ClinicalDocument/code/translation/@codeSystem 
<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: 

<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.
Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

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

#Im CDA wird dieser Zeitpunkt wie folgt abgelegt:
##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:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
CreationTime entfällt bei On-Demand Documents.
{{EndYellowBox}}

====Spezifikation====

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 
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: 

Für jedes documentationOf Element 1..n: 

$code = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code 
$displayName = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName 
$codeSystem = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem 
<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: 

 $person = ClinicalDocument/legalAuthenticator/assignedEntity

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<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) Achtung: Diese ID gelangt nicht in die Metadaten!

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

 $code = ClinicalDocument/code/@code 
 $displayName = ClinicalDocument/code/@displayName 
 $codeSystem = ClinicalDocument/code/@codeSystem 
<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: 

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

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

Fall 2 
Attribut ClinicalDocument/id/@extension ist vorhanden

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

<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..1])
#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).

{{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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}

{{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=====
Bei der Registrierung von KOS Objekten SOLL eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden. Diese dient als Basis für eine 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.

Für Befunde der bildgebenden Diagnostik (diagnostic image report) KANN die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Accession Number z.B. 20201111

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

concat

(

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

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

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

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

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

 

===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: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = ClinicalDocument/hl7at:formatCode/@displayName 
$codeSystem = 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:

$code = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code

$displayName = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName

$codeSystem = 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: 
CDA R2: '''text/xml''' 

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

$code = ClinicalDocument/hl7at:practiceSettingCode/@code 
$displayName = ClinicalDocument/hl7at:practiceSettingCode/@displayName 
$codeSystem = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem 
<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"18. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:

*"true" oder
*"false"
18 Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.
====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=

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

ILF:XDS Metadaten (Version 3)

2021-03-26T07:42:03Z

Kuttin: /* Spezifikation */

{{#seo:
|title=XDS Metadaten 3.0.0
|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 (Version 3.0.0)}}



{{#css:
@media screen{
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.toc{
width: 20%;
float: right !important;
margin: 10px 0px 10px 30px !important;
border: 1px solid #AAA;
background-color: #F9F9F9;
display: table;
padding: 7px !important;
}
}
}}

{{Infobox Dokument
|Group = ELGA CDA Implementierungsleitfäden
|Title = ELGA XDS Metadaten (XDSDocumentEntry)
|Subtitle = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA [1.2.40.0.34.7.6.9.3]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0+20210324
|Submitted = ELGA GmbH
|Date = März 2021
|Copyright = 2011-
|Status = Reconciliation
|Period = n.a.
|OID = 1.2.40.0.34.7.6.9.3
|Realm = Austria
}}

{{TOC limit|4}}



{{#css:
.orange{
border: thin black solid;
background-color:#F4C789;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
}
}}

=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;">
==Impressum==
<div class="mw-collapsible-content">
''Medieneigentümer, Herausgeber, Hersteller, Verleger:'' 
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050 
Internet: [http://www.elga.gv.at www.elga.gv.at]
Email: [mailto:cda@elga.gv.at cda@elga.gv.at] 
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch

''Redaktion, Projektleitung, Koordination: '' 
Mag.Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]

''Abbildungen:'' Sofern nicht anders angegeben: © ELGA GmbH

''Nutzung'': Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria [http://www.hl7.at www.hl7.at]. 
Die Nutzung ist ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter [https://www.gesundheit.gv.at www.gesundheit.gv.at] und [https://www.elga.gv.at/cda www.elga.gv.at/cda]
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

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

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

==Sprachliche Gleichbehandlung==
<div class="mw-collapsible-content">
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer, Frauen und andere Geschlechtsidentitäten in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
</div></div>

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

Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> .

===Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")===
<div style="border: thin #77c123 solid;width:100%; margin-left: 10px">
<div style="line-height: 1.25; font-size:16px; border-bottom: 1px solid #81ab1f; box-shadow: 0 4px 0 0 #a2d727;margin-bottom:4px; color:#77c123; width:100%">
Third Party Intellectual Property
</div>
<div style="width:100%;">


Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass der Herausgeber nicht alle Rechte und Ansprüche in und an den Materialien besitzt und dass die Materialien geistiges Eigentum von Dritten enthalten und / oder darauf verweisen können ("Third Party Intellectual Property (IP)"). 

Die Anerkennung dieser Lizenzbestimmungen gewährt dem Lizenznehmer keine Rechte in Bezug auf Third Party IP. Der Lizenznehmer allein ist für die Identifizierung und den Erhalt von notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig verantwortlich. 

Jegliche Handlungen, Ansprüche oder Klagen eines Dritten, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, bleiben die Haftung des Lizenznehmers.

</div>
</div>

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

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

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

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

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

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

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website: [[ILF: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 ([http://www.elga.gv.at/CDA Website der ELGA GmbH]) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:

*ELGA-Gesamtarchitektur<ref name="ELGA-Gesamtarchitektur">ELGA-Gesamtarchitektur 2.30a [http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>
*Beispieldokumente
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
*CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
*Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
*Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
*Hinweise für die zu verwendenden Terminologien
*Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}

==Bedienungshinweise==
===Farbliche Hervorhebungen===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''<Hinweis>''' authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
{{EndYellowBox}}
''Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>
''Verweis auf ELGA Value Set:''
{{BeginILFBox}}
'''<Verweis>''' Zulässige Werte gemäß Value Set '''"ELGA_FormatCode".'''
{{EndILFBox}}

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

===PDF-Navigation===
<div class="mw-collapsible-content">
Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

*Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
*Seitenweise blättern: "Bild" Tasten
*Scrollen: Pfeil nach oben bzw. unten
*Zoomen: Strg + Mouserad drehen
*Suchen im Dokument: Strg + F
</div></div>



=Harmonisierung=
'''Erarbeitung des Implementierungsleitfadens''' 
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%" |Person1
|- 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
|}

1 Namen ohne Titel


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

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.

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

==Hinweise zur Verwendung des Dokuments==
===Codesysteme und Value Sets===
Die in diesem Dokument erwähnten Codesysteme bzw. Value Sets werden am Terminologieserver (https://www.gesundheit.gv.at/gesundheitssystem/professional/it-services/terminologieserver-doku) und auf der Website der ELGA GmbH (http://www.elga.gv.at) veröffentlicht.

Wenn codierte Werte angegeben werden, ist es immer die Aufgabe des Document Consumers, die korrekten lesbaren Werte anzuzeigen. Es wird nicht empfohlen, die in den XDS-Metadaten verfügbaren DisplayNames direkt zur Anzeige zur verwenden, da Schreibweisen der DisplayNames variieren oder in unterschiedlichen Sprachen angegeben sein können.

===OID ===
In diesem Dokument wird an vielen Stellen die Verwendung von OID vorgeschrieben. OID sind Objekt-Identifikatoren oder Objektkennungen, die als weltweit eindeutige Namen für Informationsobjekte dienen (ISO/IEC 9834-1). Weitere Informationen zur Verwendung und Registrierung von OID sind im "OID-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.

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

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

====Bereitstellen [ITI-41] und Veröffentlichen [ITI-42]====
Ein neues Dokument wird entsprechend IHE XDS im Repository gespeichert und durch Registrieren der XDS-Metadaten in der Registry für ELGA bereitgestellt. Neu veröffentlichte Dokument-Metadaten werden immer mit dem Status "approved" versehen.

====Ersetzen eines Dokuments durch eine neue Version ("Updaten") [ITI-41]====
Änderungen eines für ELGA bereitgestellten Dokumentes sind NICHT ERLAUBT.

Es ist allerdings möglich, ein Dokument durch ein anderes zu ersetzen, indem ein neues Dokument (bzw. eine neue Version des Dokumentes) gespeichert und registriert wird. Hierbei MUSS die SetId der referenceIdList in den XDS-Metadaten zum neuen Dokument der der Vorgängerversion entsprechen. Die XDS-Metadaten der Vorgängerversion des Dokumentes bekommen den Status "deprecated". In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp "replace" (RPLC)).

Beim Ersetzen von ELGA Dokumenten wird das ELGA Berechtigungssystem eventuell zugeordnete individuelle Zugriffsberechtigungen unabhängig von ihrer Anzahl auch auf die Nachfolgeversionen anwenden.

====Stornieren [ITI-57, XDS Metadata Update]====
Dokumente werden "storniert", indem der Dokumentstatus auf "deprecated" gesetzt wird und keine neue Dokumentenversion registriert wird.

===Größenbeschränkung ===
ELGA schreibt für die Größe der eingebrachten CDA eine Maximalgröße von 20 MB vor. Größere Dokumente sind abzulehnen. Es liegt generell in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten |Allgemeiner Implementierungsleitfaden
für ELGA CDA Dokumente, Kapitel 6.10]].

==Allgemeines zu XDS-Metadaten==
Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumente entsprechend klassifiziert und beschrieben werden. Diese beschreibenden "Metadaten" werden in Form einer Nachricht gemeinsam mit dem Dokument an das Repository mitgegeben. Da IHE XDS Systeme grundsätzlich für beliebige Dokumentformate offen sind, gilt dies für alle Arten von Dokumenten (CDA, PDF, Bilder, etc.) gleichermaßen.

Die Metadaten eines Dokuments (XDSDocumentEntry) in einem IHE XDS System beinhalten Informationen
* über das Dokument selbst – um eine Klassifizierung und eine korrekte Darstellung des Dokumenteninhalts zu ermöglichen
* über eventuelle Beziehungen zu anderen Dokumenten (z.B. zu älteren Versionen eines Dokuments)
* über den Speicherort des Dokuments
* über den GDA, welcher das Dokument erstellt hat
* über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).
Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE "IT-Infrastructure" (ITI) Technical Framework, Volume 3 festgelegt (IHE ITI TF-3)<ref name="ITITF3"/>.

Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.
{{BeginYellowBox}}
Die Metadaten sind die ausschließliche Grundlage für das Suchen und Filtern von Dokumenten in einem XDS Dokumentenregister und somit im ELGA Verweisregister, daher ist die korrekte Verschlagwortung der Dokumente mit den Metadaten eine notwendige Voraussetzung.
{{EndYellowBox}}

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

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

===Metadaten aus strukturierten Dokumenten (CDA)===
Strukturierte Dokumente bieten die Möglichkeit, die Informationen für die Metadaten beim Einbringen in ein Repository in gewissem Maße aus den Dokumenten selbst automatisiert zu entnehmen. Das vermindert daher die Menge der Informationen, die separat erhoben oder ermittelt werden muss.

Die IHE hat im Rahmen des "Patient Care Coordination" (PCC) Technical Frameworks eine genaue Vorschrift spezifiziert, aus welchen Bereichen des CDA Dokuments die Metadaten entnommen werden sollen.

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

===Metadaten aus "On-Demand Documents" (ODD) ===
Ü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"/>.

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

===XDS Metadaten im Vergleich IHE vs. ELGA===
Die vollständige Liste der XDS Metadaten Elemente kann man in folgende Arten von Elementen unterteilen:
# Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
# Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)
# '''Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können (XDS Document Source)'''
# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
## '''ELGA relevante'''
## Nicht ELGA relevante
Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).

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

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

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

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

{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|K||Aus KOS-Inhalt abgeleitet
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- style="background:#white"
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
|}

''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" |'''Metadaten Element'''
|'''Optionalität'''
|'''Quelle'''
|'''Beschreibung'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''M [1..1]'''
|<nowiki>-</nowiki>
|Die Person oder das Gerät, welche(s) das Dokument verfasst hat
|-
| rowspan="4" |
|authorInstitution
|'''M [1..1]'''
|E1/K
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|-
|authorPerson
|'''R [0..1]'''
|K
|Daten der Person

(Name, ID, etc.)
|-
|authorRole
|'''R [0..1]'''
|K
|Rolle der Person
|-
|authorSpeciality
|'''R [0..1]'''
|E1/K
|Fachrichtung der Person
|-
| colspan="2" |'''classCode'''
|'''M [1..1]'''
|A
|Dokumenten/Objektklasse (Oberklasse)

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

codierter Wert
|-
| colspan="2" |'''uniqueId'''
|'''M [1..1]'''
|K
|Global eindeutige ID des Objektes

z.B. SOP Instance UID
|-
| colspan="2" |'''referenceIdList'''
|'''M [1..*]'''
|K/E1
|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|-
| colspan="5" |'''''Explizit zu setzende Metadaten'''''
|-
| colspan="2" |'''availabilityStatus'''
|'''M [1..1]'''
|E1
|Gültigkeit des Objektes
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|E1
|Format des Objektes
|-
| colspan="2" |'''healthcareFacilityTypeCode'''
|'''M [1..1]'''
|E1
|Klassifizierung des GDA
|-
| colspan="2" |'''mimeType'''
|'''M [1..1]'''
|E1
|Mime Type des Dokuments

Fester Wert für KOS: "application/dicom"
|-
| colspan="2" |'''parentDocumentId'''
|'''O [0..1]'''
|E1
|Verweis auf ein referenziertes Objekt
|-
| colspan="2" |'''parentDocumentRelationship'''
|'''O [0..1]'''
|E1
|Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC, XFRM
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|E1
|Fachliche Zuordnung des Dokuments
|-
| colspan="2" |'''entryUUID'''
|'''M [1..1]'''
|E1
|UUID des Metadaten-Records des Dokuments(XDS DocumentEntry)
|-
| colspan="2" |'''objectType'''
|'''M [1..1]'''
|E1
|Typ des DocumentEntries

Fester Wert "SD"
|-
| colspan="2" |'''comments'''
|'''O [0..1]'''
|K
|Kommentar zum Dokument/Objekt
|-
| colspan="2" |'''patientId'''
|'''M [1..1]'''
|E1
|Patienten-ID in der XDS Affinity Domain
|-
| colspan="5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|-
| colspan="2" |'''hash'''
|'''M [1..1]'''
|A
|Hash Wert des Dokuments. Wird vom Repository befüllt
|-
| colspan="2" |'''homeCommunityId'''
|'''M [1..1]'''
|A
|Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.
|-
| colspan="2" |'''repositoryUniqueId'''
|'''M [1..1]'''
|A
|Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
|-
| colspan="2" |'''size'''
|'''M [1..1]'''
|A
|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository befüllt.
 
|-
| colspan="2" |'''URI'''
|'''NP [0..0]'''[[#%20ftn1|<nowiki/>]][[#%20ftn1|<nowiki/>]]
|A
|Wird in XDS-I nicht verwendet
|-
|-
| colspan="5" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|-
| colspan="2" |'''elgaFlag'''
|'''M [1..1]'''
|B
|Kennzeichnet ein Dokument als "ELGA-Dokument"
|-
| colspan="2" |'''elgaHash'''
|'''M [1..1]'''
|B
|Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes
|}
 [[#%20ftn1|<nowiki/>]]

 


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

In der Tabelle 6 werden die XDS-Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität), jeweils für Stable Documents (SD) und On-Demand-Documents (ODD) angegeben.

''Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|C||Aus CDA-Inhalt abgeleitet (direkt oder indirekt, gilt nicht für On-Demand-Documents)
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- 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="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 6: Überblick XDS Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''
| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''
| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
| rowspan="2" style="text-align:left" |'''Beschreibung '''
|- style="background:#CBD7F1"
|'''SD'''9||'''ODD'''10
|- style="background:#CBD7F1"
| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''
|- style="background:white"
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''M [1..1]'''||'''M [1..1]'''
|C||Die Person, welche das Dokument verfasst hat
|- style="background:white"
| ||authorInstitution||'''M [1..1]'''||'''M [1..1]'''
|C||ID und Name der Organisation (Kurzbezeichnung), der die Person angehört, wie im GDA-Index angegeben.
|- style="background:white"
| ||authorPerson||'''M [1..1]'''||'''M [1..1]'''
|C||Daten der Person (Name, ID, etc.)
|- style="background:white"
| ||authorRole||'''R [0..1]'''||'''NP [0..0]'''
|C||Rolle der Person
|- style="background:white"
| ||authorSpeciality||'''R [0..1]'''||'''NP [0..0]'''
|C||Fachrichtung der Person
|- style="background:white"
| colspan="2" |'''classCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Vertraulichkeitscode des Dokuments
|- style="background:white"
| colspan="2" |'''creationTime'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R [0..*]'''||'''R [0..*]'''
|C||Liste von Gesundheitsdienstleistungen
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Format des Dokumenteninhalts
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O [0..1]'''||'''NP [0..0]'''
|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.
|- style="background:white"
| colspan="2" |'''languageCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Sprachcode des Dokuments z.B.: "de-AT"
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R [0..1]'''||'''NP [0..0]'''
|C||Rechtlicher Unterzeichner des Dokuments
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Fachliche Zuordnung des Dokuments
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''NP [0..0]'''||'''NP [0..0]'''
|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)
|- style="background:white"
| colspan="2" |'''Title'''||'''M [1..1]'''||'''M [1..1]'''
|C||Titel des Dokuments
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Global eindeutige ID des Dokuments
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''M [1..1]'''||'''O [0..1]'''
|C||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''M [1..1]'''||'''M [1..1]'''
|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 z.B.: "text/xml" für CDA
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O [0..1]'''||'''O [0..1]'''
|E1||Verweis auf ein referenziertes Dokument
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O [0..1]'''||'''O [0..1]'''
|E1||Typ der Relation zu dem referenzierten Dokument. 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
|}

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

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

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

''Tabelle 7: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" |'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

'''der Studie'''
|'''Attribut'''

'''im KOS'''
|'''Beschreibung'''
|- style="background:white"
| colspan="2" |author
|M [1..1]
| colspan="3" |
|- style="background:white"
| rowspan="6" |
|author.authorInstitution
|M [1..1]
|(0008,0080)
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

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

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

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

'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
|- style="background:white"
| colspan="5" |Die Person, welche die Studie durchführt, ist als author anzugeben:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,1052)
|
|Performing Physicians Identification Sequence

Code und weitere Daten aus dem ersten Item in der Sequence

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

(0008,1050)
|
|Performing Physicians Name

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

'''Achtung:''' Die Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
|- style="background:white"
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,0060) + (0008,0070) + (0008,1090)
|
|Modality Code + Manufacturer + Manufacturer's Model Name

'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
|- style="background:white"
| colspan="2" |creationTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date + Study Time

Für den Fall, dass Study Date und Study Time nicht zur Verfügung stehen, ist es zulässig, den Erstellungszeitpunkt des KOS ((0008,0023) contentDate + (0008,0033) contentTime) als creationTime zu verwenden.
|- style="background:white"
| colspan="2" |eventCodeList
|M [1..*]
|
|
|Enthält eine Liste von Codes von Gesundheitsdienstleistungen nach APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten<nowiki/>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</ref>
|- style="background:white"
|
|eventCodeList DisplayNameList
|M [1..1]
|
|
|Enthält den Display Name des APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom" />
|- style="background:white"
| colspan="2" |serviceStartTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|- style="background:white"
| colspan="2" |sourcePatientId
|M [1..1]
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|- style="background:white"
| colspan="2" |sourcePatientInfo
|M [1..1]
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|Die ELGA Vorgabe empfiehlt, Name, Geburtstag und Geschlecht NICHT anzugeben.
|- style="background:white"
| colspan="2" |title
|M [1..1]
|(0008,0060) + (0008,1030)
|
|Der relevante Modality Code der Studie oder alle Modality Codes der Studie und die Study Description.

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

'''Anmerkung:'''

Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
 
|- style="background:white"
| colspan="2" |uniqueId
|M [1..1]
|
|(0008,0018)
|Die SOP Instance UID des KOS
|- style="background:white"
| colspan="2" |referenceIdList
|M [1..1]
|
|
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|- style="background:white"
| rowspan="2" |
|value mit CXi.5 = "<nowiki>urn:elga:iti:xds:2014: OwnDocument_setId</nowiki>"
|M [1..1]
|(0020,000D) oder ein vergleichbares Attribut
|(0020,000D) oder ein vergleichbares Attribut
|Die setId zur Klammerung aller Versionen eines KOS

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

Eine mögliche Wahl der setId ist die Study Instance UID. Die geeignete Wahl der setId hängt auch vom implementierten Stornoworkflow ab, siehe KOS Leitfaden (Kapitel 8.2.2.)<ref name="KOS-Leitfaden" />
|- style="background:white"
|value mit CXi.5 = "<nowiki>urn:ihe:iti:xds:2013: accession</nowiki>"
|R [0..1]
|(0008,0050) oder ein vergleichbares Attribut wie z.B.

(0040,1001) Requested Procedure ID
 
|(0008,0050)
 
|Die ID, die zur Verlinkung mit dem Befund heranzuziehen ist.

Diese ist mit dem Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' anzugeben.

'''Achtung:'''

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

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

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

Unabhängig von der Wahl des DICOM Attributs ist aber in jedem Fall der Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' zu verwenden.
|- style="background:white"
| colspan="2" |comments
|O [0..1]
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

===author===
Die Person oder Maschine, die das Dokument erstellt hat. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.

Die ''authorInstitution'' benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden können. Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.

*''oid'': OID der Organisation aus dem GDA-Index (muss ermittelt werden)
*''name'': (0008,0080), Institution Name, Name der Organisation als String,
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden. 

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

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

=====Spezifikation=====

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

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

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

concat( 
$name,"^^^^^^^^^", 
$oid,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

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

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

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

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

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

=====Spezifikation für Personen=====

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

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

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

$person = (0008,1050) Performing Physicians Name

$root = OID-Knoten für den Personenidentifikator

concat( 
 $id,"^", 
 $person,"^", 
 $root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>11375^Musterdoc^Josef^Maria^Msc^DIDr^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>

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

concat( 
 $id,"^", 
 $person 
) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf die XCN Komponenten wie in IHE RAD TF-2 Rev.19 2020<ref name="IHERADTF2">IHE Radiology (RAD) Technical Framework Volume 2x Rev.19, 2020 [https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf]</ref>, "Table 4.68.4.1.2.3-3: XCN Data type mapping" vorgegeben.

=====Spezifikation für Software und Geräte=====

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

$Modality = Modality (0008,0060)

$Manufacturer = Manufacturer (0008,0070)

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

concat(

"^",

$Modality,"^",

$Manufacturer,"^",

$ManufacturersModelName

) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^CT^Geräthersteller^Gerätename</Value>
</ValueList>
</Slot>
</Classification></pre>

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

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

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

Beispiel:

*"Radiologie"
*"Modalität"

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

Beispiel:

*"Facharzt für Radiologie"
*"Facharzt für Nuklearmedizin"

=====Spezifikation=====

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

Bsp: Fachärztin/Facharzt für Radiologie 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Fachärztin/Facharzt für Radiologie</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Wenn eine Person als Autor vorhanden ist, '''MUSS''' der Wert einem DisplayName aus dem Value Set "ELGA_AuthorSpeciality" entsprechen.

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

{{EndYellowBox}}

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

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Objektklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Objektklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#typeCode_.28und_typeCodeDisplayName.29|typeCode]]
|}

====Spezifikation====

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

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

$code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
classifiedObject="theDocument" nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===confidentialityCode===
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.

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

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

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

====Spezifikation====

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

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

<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="theDocument" nodeRepresentation="N">
<Name>
<LocalizedString value="normal"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:2.16.840.1.113883.5.25</Value>
</ValueList>
</Slot>
</Classification></pre>

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

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

Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From ''UTC''<ref>Timezone Offset From UTC http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</ref> berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

====Spezifikation====

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

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

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

concat(

$date,

$time

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="creationTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.{{EndYellowBox}}

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

====Spezifikation====

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

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

$code = APPC code (alle Achsen) z.B. "2.4.0.5-3-3" 
$displayName = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule" 
$codeSystem = OID des Codesystems APPC: 1.2.40.0.34.5.38 
<pre class="ilfbox_code">
<Classification
classificationScheme=
"urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
classifiedObject="theDocument"
nodeRepresentation="$code">
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
<Name>
<LocalizedString value="$displayName"/>
</Name>
</Classification>
</pre>

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

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

Fester Wert "de-AT"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/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===
Dieses Element darf für XDS-I nicht verwendet werden [NP].

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

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

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

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

concat(

Study Date,

Study Time + Timezone Offset from UTC

)
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="serviceStartTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

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

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

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

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

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

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

$patientID = (0010,0020) Patient ID

$oid = OID des lokalen Patientenidentifikators

concat(

$patientID,

"^^^&amp;",

$oid,

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.
{{BeginYellowBox}}
In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
{{EndYellowBox}}

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

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

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modality Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. ("CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule")
{{BeginYellowBox}}
'''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
{{EndYellowBox}}
====Spezifikation====

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

concat(

Modality,

" ",

Study Description

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Name>
<LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" />
</Name>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
{{EndYellowBox}}

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

Unterscheidung typeCode/classCode:
{| class="wikitable"
|- style="background:white"
|'''typeCode'''
|'''Objektklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
|classCode
|Objektklasse in grober Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29|classCode]]
|}

====Spezifikation====

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

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

 $code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="KeyImageObject"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

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

$code = "55113-5"

$displayName = "Key images Document Radiology"

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

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

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

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

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

$value = (0008,0018) SOP Instance UID

<pre class="ilfbox_code">
<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. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:

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

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

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

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

{| 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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}
{{BeginYellowBox}}

'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.
{{EndYellowBox}}

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

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

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

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

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

concat

(

$id, "^^^^",

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

"&amp;",

$homeCommunityId, "&amp;ISO"

)

Wie oben angeführt wird folgender CXi Wert für <Value> erstellt:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.

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

=====Spezifikation=====
Bei der Registrierung von KOS Objekten MUSS eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden.

Für Befunde der Bildgebenden Diagnostik (diagnostic image report) kann die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Accession Number z.B. 20201111

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

concat

(

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

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

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"

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

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

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

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

$id = Aufenthaltszahl z.B. Az123456

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

concat

(

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

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

"<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>Az123456^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.4613.3.4<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>
</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

*'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki>. In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.
*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki>

Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId
</nowiki>^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
<Value>20201111^^^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
<Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value>
<Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===intendedRecipient===
Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der ''intendedRecipient'' notwendig. Derzeit wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.

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

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

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
(0008,1030) Study Description (VR:LO, VM:1)

====Spezifikation====
Comments wird gemäß folgender Vorschrift zusammengesetzt:
$comment = (0008,1030) Study Description<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Description">
<LocalizedString value = "$comment"/>
</Description>
</ExtrinsicObject>
</pre> 

==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
===availabilityStatus===
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Objektes.

Mögliche Werte laut IHE sind:

*Approved
*Deprecated

Dieses Attribut wird im Zuge des Einbringens von neuen Objekten ("Submission") durch die empfangende XDS Registry immer auf "'''Approved'''" gesetzt.

availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.

<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

===formatCode (und formatCodeDisplayName)===
Das ''formatCode'' Element beschreibt das Format des registrierten Objekts. Es ermöglicht einem empfangenden System (''Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Objektformats und somit die korrekte Darstellung und Verarbeitung.

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

 
$code = "1.2.840.10008.5.1.4.1.1.88.59" 
$displayName = "Key Object Selection Document" 
$codeSystem = "1.2.840.10008.2.6.1"
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA, z.B.

*158 "Fachärztin/Facharzt"
*300 "Allgemeine Krankenanstalt"

Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]".
{{EndYellowBox}}

====Spezifikation====

'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

$code = Klassifizierung des GDA (Code)

$displayName = Klartext des angegebenen Codes

$codeSystem = OID der ausgebenden Stelle

<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===mimeType===
Das ''mimeType'' Element beschreibt den "Internet Media Type" des Objektes gemäß dem "Multipurpose Internet Mail Extensions" (MIME) Standard. Der Standard wird beschrieben in RFC 2045<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref> und RFC 2049<ref name="RFC2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>.

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, welches das DocumentEntry repräsentiert.

Folgende Mime-Types sind für DICOM KOS Objekte zugelassen:

*application/dicom 
<pre class="ilfbox_code">
<ExtrinsicObject
id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
mimeType="application/dicom"
objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>
</pre>

===practiceSettingCode (und practiceSettingCodeDisplayName)===
Das ''practiceSettingCode'' Element beschreibt die fachliche Zuordnung des Objektes. Es soll den Fachbereich wiedergeben, dem der Inhalt des Objektes am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung, z.B.:

*F044 "Radiologie"
*F052 "Unfallchirurgie"

Im KOS-Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_PracticeSetting_VS ELGA_PracticeSetting_VS]".
{{EndYellowBox}}

====Spezifikation====

'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

$code = Code aus Value Set ELGA_PracticeSetting $displayName = Klartext des angegebenen Codes (displayName) $codeSystem = OID des Codesystems (1.2.40.0.34.5.12) 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===objectType===
Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "stabiles Dokument" (stable document, SD) und "On-demand Dokument" (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.

Für KOS Objekte wird der fixe Wert "<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="application/dicom"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

==ELGA-spezifische Erweiterungen der XDS-Metadaten==
Die folgenden Daten entsprechen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information.

===elgaFlag===
Das elgaFlag dient zur Kennzeichnung eines Objektes als "ELGA-Objekt"18. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:

*"true" oder
*"false"

18 Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Objekte auftreten, die NICHT für ELGA vorgesehen sind.

====Spezifikation====

<pre class="ilfbox_code">
<Slot name="urn:elga-bes:elgaFlag">
<ValueList>
<Value>true</Value>
</ValueList>
</Slot>
</pre>

===elgaHash===
Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot "ELGA-Hash" gespeichert.

Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.

====Spezifikation====
<pre class="ilfbox_code">
<rim:Slot name="urn:elga-bes:elgaHash">
<rim:ValueList>
<rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>
</rim:ValueList>
</rim:Slot>
</pre>

=XDS Metadaten für CDA Dokumente=
Die folgenden Kapitel spezifizieren die XDS-Metadaten von HL7 CDA-Dokumenten für deren Verwendung in ELGA. Nicht angegebene Metadaten sind nicht weiter eingeschränkt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol. 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.<ref name="ITITF3"/>

==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).

CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen.

====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurde.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört, grundsätzlich in folgendem Element abgelegt:
##ClinicalDocument/author/assignedAuthor/representedOrganization
#Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:
##'''id'''[1] … ID der Organisation mit den folgenden Attributen:
###@root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)
###@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)
##'''name''' … Name der Organisation als String Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.
#GDA, in deren Gültigkeitsbereich Dokumente erstellt werden können, sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da es vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden.
{{EndYellowBox}}

=====Spezifikation=====

'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$inst … ClinicalDocument/author/assignedAuthor/representedOrganization

*Fall 1: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist nicht vorhanden 

concat( 
$inst/name,"^^^^^^^^^", 
$inst/id[1]/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO</Value>
</ValueList>
</Slot>
</Classification>
</pre>

*Fall 2: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist vorhanden 

concat( 
$inst/name,"^^^^^&", 
$inst/id[1]/@root,"&ISO^^^^" 
$inst/id[1]/@extension 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&amp;ISO^^^^45</Value>
</ValueList>
</Slot>
</Classification>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

====authorPerson====
Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche das Dokument inhaltlich erstellt hat (also nicht die Schreibkraft).

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit CDA Header Elementen:

#Laut Festlegung wird der Autor im Header-Element "author" abgelegt:
##ClinicalDocument/author/assignedAuthor
#Der Autor (Person)
##Ein Personenelement enthält unter anderem die folgenden Unterelemente:
###id … ID der Person mit den folgenden Attributen:
####@root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
####@extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
###assignedPerson
####Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
#####name
#Gerät oder Software als Autor
##Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:
###assignedAuthoringDevice
####Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software
#####manufacturerModelName
####Enthält ein Element mit dem Namen des Geräts oder der Software
#####softwareName

=====Spezifikation für Personen=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

 $person = ClinicalDocument/author/assignedAuthor

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
{{BeginYellowBox}}
Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.
{{EndYellowBox}}
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

=====Spezifikation für Software und Geräte=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

 $person = ClinicalDocument/author/assignedAuthor

concat( 
"^", 
 $person/assignedAuthoringDevice/manufacturerModelName,"^", 
 $person/assignedAuthoringDevice/softwareName 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^Good Health System^Best Health Software Application</Value>
</ValueList>
</Slot>
</Classification></pre>

Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.

Beispiel:

*"Diensthabender Oberarzt"
*"Verantwortlicher diensthabender Arzt für die Dokumenterstellung"

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Laut Festlegung wird die "Rolle" der Person, welche das Dokument inhaltlich erstellt hat, im Element functionCode des Autors abgelegt:
##''ClinicalDocument/author/functionCode''
#Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.

=====Spezifikation=====

'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/functionCode/@displayName 
<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorRole">
<ValueList>
<Value>Diensthabender Oberarzt</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.

Beispiel:

*"Facharzt für Gynäkologie"
*"Facharzt für interne Medizin"

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Laut Festlegung wird die "Fachrichtung" der Person, welche das Dokument inhaltlich erstellt hat, im Element code des Autors abgelegt:
##''ClinicalDocument/author/assignedAuthor/code''
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.

=====Spezifikation=====

'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/assignedAuthor/code/@displayName 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Anästhesiologie und Intensivmedizin</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

===classCode (und classCodeDisplayName)===
Das ''classCode'' Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Dokumentenklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Dokumentenklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2|typeCode]]
|}

====Spezifikation====

'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 

$code = ClinicalDocument/code/translation/@code 
$displayName = ClinicalDocument/code/translation/@displayName 
$codeSystem = ClinicalDocument/code/translation/@codeSystem 
<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: 

<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.
Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird dieser Zeitpunkt wie folgt abgelegt:
##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:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
CreationTime entfällt bei On-Demand Documents.
{{EndYellowBox}}

====Spezifikation====

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 
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: 

Für jedes documentationOf Element 1..n: 

$code = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code 
$displayName = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName 
$codeSystem = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem 
<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: 

 $person = ClinicalDocument/legalAuthenticator/assignedEntity

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<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) Achtung: Diese ID gelangt nicht in die Metadaten!

====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. 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:

 $code = ClinicalDocument/code/@code 
 $displayName = ClinicalDocument/code/@displayName 
 $codeSystem = ClinicalDocument/code/@codeSystem 
<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: 

Fall 1 
Attribut ClinicalDocument/id/@extension ist nicht vorhanden

$value = concat(ClinicalDocument/id/@root)

Fall 2 
Attribut ClinicalDocument/id/@extension ist vorhanden

$value = concat(
ClinicalDocument/id/@root, "^",
ClinicalDocument/id/@extension
)

<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..1])
#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).

{{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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}

{{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=====
Bei der Registrierung von KOS Objekten SOLL eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden. Diese dient als Basis für eine 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.

Für Befunde der bildgebenden Diagnostik (diagnostic image report) KANN die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Accession Number z.B. 20201111

$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"<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"
 

====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.

 
=====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>

 

===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: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = ClinicalDocument/hl7at:formatCode/@displayName 
$codeSystem = 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:

$code = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code

$displayName = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName

$codeSystem = 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: 
CDA R2: '''text/xml''' 

<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:

$code = ClinicalDocument/hl7at:practiceSettingCode/@code 
$displayName = ClinicalDocument/hl7at:practiceSettingCode/@displayName 
$codeSystem = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem 
<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"18. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:

*"true" oder
*"false"
18 Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.
====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=

==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.

ILF:XDS Metadaten (Version 3)

2021-03-26T07:15:42Z

Kuttin: /* referenceIdList */

{{#seo:
|title=XDS Metadaten 3.0.0
|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 (Version 3.0.0)}}



{{#css:
@media screen{
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.toc{
width: 20%;
float: right !important;
margin: 10px 0px 10px 30px !important;
border: 1px solid #AAA;
background-color: #F9F9F9;
display: table;
padding: 7px !important;
}
}
}}

{{Infobox Dokument
|Group = ELGA CDA Implementierungsleitfäden
|Title = ELGA XDS Metadaten (XDSDocumentEntry)
|Subtitle = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA [1.2.40.0.34.7.6.9.3]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0+20210324
|Submitted = ELGA GmbH
|Date = März 2021
|Copyright = 2011-
|Status = Reconciliation
|Period = n.a.
|OID = 1.2.40.0.34.7.6.9.3
|Realm = Austria
}}

{{TOC limit|4}}



{{#css:
.orange{
border: thin black solid;
background-color:#F4C789;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
}
}}

=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;">
==Impressum==
<div class="mw-collapsible-content">
''Medieneigentümer, Herausgeber, Hersteller, Verleger:'' 
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050 
Internet: [http://www.elga.gv.at www.elga.gv.at]
Email: [mailto:cda@elga.gv.at cda@elga.gv.at] 
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch

''Redaktion, Projektleitung, Koordination: '' 
Mag.Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]

''Abbildungen:'' Sofern nicht anders angegeben: © ELGA GmbH

''Nutzung'': Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria [http://www.hl7.at www.hl7.at]. 
Die Nutzung ist ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter [https://www.gesundheit.gv.at www.gesundheit.gv.at] und [https://www.elga.gv.at/cda www.elga.gv.at/cda]
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

==Haftungsausschluss==
<div class="mw-collapsible-content">
Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht und über ein öffentliches Kommentierungsverfahren kontrolliert. Die Nutzung des vorliegenden Leitfadens erfolgt in ausschließlicher Verantwortung der Anwender. Aus der Verwendung des vorliegenden Leitfadens können keinerlei Rechtsansprüche gegen die Autoren, Herausgeber oder Mitwirkenden erhoben und/oder abgeleitet werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls nicht beabsichtigt und von den Erstellern des Dokumentes nicht gewünscht.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

==Sprachliche Gleichbehandlung==
<div class="mw-collapsible-content">
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer, Frauen und andere Geschlechtsidentitäten in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
</div></div>

==Lizenzinformationen==
Die Verwendung dieses Leitfadens für die Zwecke der Erstellung, des Verkaufs und des Betriebs von Computerprogrammen, sofern nicht anders angegeben oder sich die Standards auf andere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen, ist ausdrücklich genehmigt. 

Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> .

===Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")===
<div style="border: thin #77c123 solid;width:100%; margin-left: 10px">
<div style="line-height: 1.25; font-size:16px; border-bottom: 1px solid #81ab1f; box-shadow: 0 4px 0 0 #a2d727;margin-bottom:4px; color:#77c123; width:100%">
Third Party Intellectual Property
</div>
<div style="width:100%;">


Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass der Herausgeber nicht alle Rechte und Ansprüche in und an den Materialien besitzt und dass die Materialien geistiges Eigentum von Dritten enthalten und / oder darauf verweisen können ("Third Party Intellectual Property (IP)"). 

Die Anerkennung dieser Lizenzbestimmungen gewährt dem Lizenznehmer keine Rechte in Bezug auf Third Party IP. Der Lizenznehmer allein ist für die Identifizierung und den Erhalt von notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig verantwortlich. 

Jegliche Handlungen, Ansprüche oder Klagen eines Dritten, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, bleiben die Haftung des Lizenznehmers.

</div>
</div>

==Verbindlichkeit==
Die Verbindlichkeit und die Umsetzungsfrist von Leitfäden sind im Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.

Ein Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf [http://www.gesundheit.gv.at www.gesundheit.gv.at] zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten ("Mandatory" (M), "Required" (R) und "Fixed" (F)), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.

Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit der Rechtsordnung der Republik Österreich und insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz 2000, Gesundheitstelematikgesetz 2012) zu erfolgen. Technische Möglichkeiten können gesetzliche Bestimmungen selbstverständlich nicht verändern, vielmehr sind die technischen Möglichkeiten im Einklang mit den Gesetzen zu nutzen.

Die Einhaltung der gesetzlichen Bestimmungen liegt im Verantwortungsbereich der Ersteller der CDA-Dokumente.

==Verwendete Grundlagen und Bezug zu anderen Standards==
Grundlage dieses Implementierungsleitfadens ist der internationale Standard IHE ITI Cross-enterprise Document Sharing <ref name="IHE ITI"></ref> von Integrating the Healthcare Enterprise (IHE)<ref name="IHE">Integrating the Healthcare Enterprise (IHE) International, Incorporated [http://www.ihe.net http://www.ihe.net]</ref>.

Weiters bezieht sich dieser Leitfaden auf den internationalen Standard "HL7® Clinical Document Architecture, Release 2.0" (CDA ®)<ref name="CDA"></ref>, für die das Copyright © von Health Level Seven International<ref name="HL7">Health Level Seven International [http://www.hl7.org www.hl7.org]</ref> gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert<ref name="ISO CDA">ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical Document Architecture, Release 2 [https://www.iso.org/standard/44429.html https://www.iso.org/standard/44429.html]</ref>. CDA definiert die Struktur und Semantik von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und Patienten. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen.
Die Dokumentmetadaten für CDA Dokumente im Österreichischen Gesundheitswesen werden grundsätzlich vom "Allgemeinen CDA Implementierungsleitfaden"<ref name="ALF">Allgemeiner Implementierungsleitfaden für CDA Dokumente [https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_(Version_3) https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_(Version_3)]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden. Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens Version 3]''' und gilt entsprechend für alle CDA-Dokumente, die auf Basis des Leitfadens erstellt werden.
{{EndILFBox}}

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website: [[ILF: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 ([http://www.elga.gv.at/CDA Website der ELGA GmbH]) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:

*ELGA-Gesamtarchitektur<ref name="ELGA-Gesamtarchitektur">ELGA-Gesamtarchitektur 2.30a [http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>
*Beispieldokumente
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
*CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
*Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
*Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
*Hinweise für die zu verwendenden Terminologien
*Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}

==Bedienungshinweise==
===Farbliche Hervorhebungen===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''<Hinweis>''' authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
{{EndYellowBox}}
''Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>
''Verweis auf ELGA Value Set:''
{{BeginILFBox}}
'''<Verweis>''' Zulässige Werte gemäß Value Set '''"ELGA_FormatCode".'''
{{EndILFBox}}

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

===PDF-Navigation===
<div class="mw-collapsible-content">
Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

*Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
*Seitenweise blättern: "Bild" Tasten
*Scrollen: Pfeil nach oben bzw. unten
*Zoomen: Strg + Mouserad drehen
*Suchen im Dokument: Strg + F
</div></div>



=Harmonisierung=
'''Erarbeitung des Implementierungsleitfadens''' 
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%" |Person1
|- 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
|}

1 Namen ohne Titel


=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 beim Einbringen von Dokumenten in Form von Befunden<ref name="ALF"></ref> oder Bilddaten in die ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumente (Metadaten der XDSDocumentEntry Objekte): ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 12.0 (22.4.2016) Final Text''<ref name="ITITF3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 12.0 (2016) [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf], zuletzt besucht am 25.01.2021</ref>

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.

Etwaige, Service-spezifische, Vorgaben auf Schnittstellen-Ebene sind in den entsprechenden Schnittstellenspezifikationen (u.a. Schnittstellen Berechtigungssystem, Schnittstellenspezifikation zur Anbindung des elektronischen Impfpasses) angeführt und im Rahmen konkreter System-Anbindungen zu berücksichtigen.

==Hinweise zur Verwendung des Dokuments==
===Codesysteme und Value Sets===
Die in diesem Dokument erwähnten Codesysteme bzw. Value Sets werden am Terminologieserver (https://www.gesundheit.gv.at/gesundheitssystem/professional/it-services/terminologieserver-doku) und auf der Website der ELGA GmbH (http://www.elga.gv.at) veröffentlicht.

Wenn codierte Werte angegeben werden, ist es immer die Aufgabe des Document Consumers, die korrekten lesbaren Werte anzuzeigen. Es wird nicht empfohlen, die in den XDS-Metadaten verfügbaren DisplayNames direkt zur Anzeige zur verwenden, da Schreibweisen der DisplayNames variieren oder in unterschiedlichen Sprachen angegeben sein können.

===OID ===
In diesem Dokument wird an vielen Stellen die Verwendung von OID vorgeschrieben. OID sind Objekt-Identifikatoren oder Objektkennungen, die als weltweit eindeutige Namen für Informationsobjekte dienen (ISO/IEC 9834-1). Weitere Informationen zur Verwendung und Registrierung von OID sind im "OID-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.

Die Vorgaben für die Erstellung der CDA-Dokumente sind in den "ELGA CDA-Implementierungsleitfäden" ersichtlich. Nur über eine Verordnung definierte Dokumentenklassen dürfen in ELGA verwendet werden, alle Dokumente MÜSSEN entsprechend der Spezifikationen der ELGA CDA-Implementierungsleitfäden erstellt werden.

===Dokumentlebenszyklus und XDS-Transaktionen===
ELGA unterstützt die im folgenden aufgezählten Aktionen (in Klammer die entsprechende ITI-Transaktion). Alle Transaktionen werden in den Protokollierungssystemen aufgezeichnet:

====Bereitstellen [ITI-41] und Veröffentlichen [ITI-42]====
Ein neues Dokument wird entsprechend IHE XDS im Repository gespeichert und durch Registrieren der XDS-Metadaten in der Registry für ELGA bereitgestellt. Neu veröffentlichte Dokument-Metadaten werden immer mit dem Status "approved" versehen.

====Ersetzen eines Dokuments durch eine neue Version ("Updaten") [ITI-41]====
Änderungen eines für ELGA bereitgestellten Dokumentes sind NICHT ERLAUBT.

Es ist allerdings möglich, ein Dokument durch ein anderes zu ersetzen, indem ein neues Dokument (bzw. eine neue Version des Dokumentes) gespeichert und registriert wird. Hierbei MUSS die SetId der referenceIdList in den XDS-Metadaten zum neuen Dokument der der Vorgängerversion entsprechen. Die XDS-Metadaten der Vorgängerversion des Dokumentes bekommen den Status "deprecated". In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp "replace" (RPLC)).

Beim Ersetzen von ELGA Dokumenten wird das ELGA Berechtigungssystem eventuell zugeordnete individuelle Zugriffsberechtigungen unabhängig von ihrer Anzahl auch auf die Nachfolgeversionen anwenden.

====Stornieren [ITI-57, XDS Metadata Update]====
Dokumente werden "storniert", indem der Dokumentstatus auf "deprecated" gesetzt wird und keine neue Dokumentenversion registriert wird.

===Größenbeschränkung ===
ELGA schreibt für die Größe der eingebrachten CDA eine Maximalgröße von 20 MB vor. Größere Dokumente sind abzulehnen. Es liegt generell in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten |Allgemeiner Implementierungsleitfaden
für ELGA CDA Dokumente, Kapitel 6.10]].

==Allgemeines zu XDS-Metadaten==
Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumente entsprechend klassifiziert und beschrieben werden. Diese beschreibenden "Metadaten" werden in Form einer Nachricht gemeinsam mit dem Dokument an das Repository mitgegeben. Da IHE XDS Systeme grundsätzlich für beliebige Dokumentformate offen sind, gilt dies für alle Arten von Dokumenten (CDA, PDF, Bilder, etc.) gleichermaßen.

Die Metadaten eines Dokuments (XDSDocumentEntry) in einem IHE XDS System beinhalten Informationen
* über das Dokument selbst – um eine Klassifizierung und eine korrekte Darstellung des Dokumenteninhalts zu ermöglichen
* über eventuelle Beziehungen zu anderen Dokumenten (z.B. zu älteren Versionen eines Dokuments)
* über den Speicherort des Dokuments
* über den GDA, welcher das Dokument erstellt hat
* über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).
Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE "IT-Infrastructure" (ITI) Technical Framework, Volume 3 festgelegt (IHE ITI TF-3)<ref name="ITITF3"/>.

Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.
{{BeginYellowBox}}
Die Metadaten sind die ausschließliche Grundlage für das Suchen und Filtern von Dokumenten in einem XDS Dokumentenregister und somit im ELGA Verweisregister, daher ist die korrekte Verschlagwortung der Dokumente mit den Metadaten eine notwendige Voraussetzung.
{{EndYellowBox}}

'''Hinweis:''' Siehe auch Vorschriften zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3<ref name="ITITF3"/>.

===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument oder binären Objekt entnommen werden und müssen daher von der erstellenden Anwendung mitgegeben werden. Es entsteht dadurch ein zusätzlicher Aufwand insbesondere hinsichtlich der Qualität der Daten. Die Metadaten müssen das beiliegende Dokument oder binäre Objekt korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden.

===Metadaten aus strukturierten Dokumenten (CDA)===
Strukturierte Dokumente bieten die Möglichkeit, die Informationen für die Metadaten beim Einbringen in ein Repository in gewissem Maße aus den Dokumenten selbst automatisiert zu entnehmen. Das vermindert daher die Menge der Informationen, die separat erhoben oder ermittelt werden muss.

Die IHE hat im Rahmen des "Patient Care Coordination" (PCC) Technical Frameworks eine genaue Vorschrift spezifiziert, aus welchen Bereichen des CDA Dokuments die Metadaten entnommen werden sollen.

Die genaue Beschreibung der einzelnen XDS Metadaten Bindings sind im IHE "Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2, Kapitel XDSDocumentEntry Metadata beschrieben.<ref name="IHEPCC">IHE "Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2 [https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf]</ref>

===Metadaten aus "On-Demand Documents" (ODD) ===
Ü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"/>.

===Metadaten aus Bilddaten (KOS)===
Bilddaten können über KOS-Objekte (Key Object Selection Document) referenziert und abgerufen werden. Die notwendigen Metadaten können in gewissem Maße aus diesen KOS-Objekten selbst automatisiert entnommen werden. Eine genaue Beschreibung für den Aufbau von KOS-Objekten findet sich im Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch.

===XDS Metadaten im Vergleich IHE vs. ELGA===
Die vollständige Liste der XDS Metadaten Elemente kann man in folgende Arten von Elementen unterteilen:
# Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
# Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)
# '''Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können (XDS Document Source)'''
# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
## '''ELGA relevante'''
## Nicht ELGA relevante
Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).

==Überblickstabelle der XDS-I Metadaten für DICOM KOS Objekte==

Die folgende Tabelle gibt einen Überblick über alle XDS-I Metadaten-Elemente. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in IHE bzw. ELGA für das Einbringen von DICOM KOS Objekten, sowie die Quelle aus der die Informationen stammen.

In der Tabelle 3 werden die XDS-I Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität) angegeben.

 ''Tabelle 1: Legende zur Spalte "Quelle" der folgenden Tabelle''

{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|K||Aus KOS-Inhalt abgeleitet
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- style="background:#white"
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
|}

''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" |'''Metadaten Element'''
|'''Optionalität'''
|'''Quelle'''
|'''Beschreibung'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''M [1..1]'''
|<nowiki>-</nowiki>
|Die Person oder das Gerät, welche(s) das Dokument verfasst hat
|-
| rowspan="4" |
|authorInstitution
|'''M [1..1]'''
|E1/K
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|-
|authorPerson
|'''R [0..1]'''
|K
|Daten der Person

(Name, ID, etc.)
|-
|authorRole
|'''R [0..1]'''
|K
|Rolle der Person
|-
|authorSpeciality
|'''R [0..1]'''
|E1/K
|Fachrichtung der Person
|-
| colspan="2" |'''classCode'''
|'''M [1..1]'''
|A
|Dokumenten/Objektklasse (Oberklasse)

z.B.: 55113-5 "Key images Document Radiology"
|-
| colspan="2" |'''confidentialityCode'''
|'''M [1..1]'''
|A
|Vertraulichkeitscode. Fester Wert "N"
|-
| colspan="2" |'''creationTime'''
|'''M [1..1]'''
|K
|Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes
|-
| colspan="2" |'''eventCodeList'''
|'''M [1..*]'''
|A/K
|Liste von Codes von Gesundheitsdienstleistungen
|-
|
|'''eventCodeDisplayName'''
|'''M [1..1]'''
|A/K
|Bezeichnung von Gesundheitsdienstleistungen nach APPC
|-
| colspan="2" |'''intendedRecipient'''
|'''NP [0..0]'''
| -
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
|-
| colspan="2" |'''languageCode'''
|'''M [1..1]'''
|A
|Sprachcode. Fester Wert "de-AT"
|-
| colspan="2" |'''legalAuthenticator'''
|'''NP [0..0]'''
| -
|Rechtlicher Unterzeichner
|-
| colspan="2" |'''serviceStartTime'''
|'''M [1..1]'''
|K
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|-
| colspan="2" |'''serviceStopTime'''
|'''NP [0..0]'''
| -
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
|-
| colspan="2" |'''sourcePatientId'''
|'''M [1..1]'''
|K
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|-
| colspan="2" |'''sourcePatientInfo'''
|'''NP [0..0]'''
| -
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
|-
| colspan="2" |'''title'''
|'''M [1..1]'''
|A/K
|Titel des Dokuments
|-
| colspan="2" |'''typeCode'''
|'''M [1..1]'''
|A
|Objekttyp (Unterklasse)

codierter Wert
|-
| colspan="2" |'''uniqueId'''
|'''M [1..1]'''
|K
|Global eindeutige ID des Objektes

z.B. SOP Instance UID
|-
| colspan="2" |'''referenceIdList'''
|'''M [1..*]'''
|K/E1
|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|-
| colspan="5" |'''''Explizit zu setzende Metadaten'''''
|-
| colspan="2" |'''availabilityStatus'''
|'''M [1..1]'''
|E1
|Gültigkeit des Objektes
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|E1
|Format des Objektes
|-
| colspan="2" |'''healthcareFacilityTypeCode'''
|'''M [1..1]'''
|E1
|Klassifizierung des GDA
|-
| colspan="2" |'''mimeType'''
|'''M [1..1]'''
|E1
|Mime Type des Dokuments

Fester Wert für KOS: "application/dicom"
|-
| colspan="2" |'''parentDocumentId'''
|'''O [0..1]'''
|E1
|Verweis auf ein referenziertes Objekt
|-
| colspan="2" |'''parentDocumentRelationship'''
|'''O [0..1]'''
|E1
|Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC, XFRM
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|E1
|Fachliche Zuordnung des Dokuments
|-
| colspan="2" |'''entryUUID'''
|'''M [1..1]'''
|E1
|UUID des Metadaten-Records des Dokuments(XDS DocumentEntry)
|-
| colspan="2" |'''objectType'''
|'''M [1..1]'''
|E1
|Typ des DocumentEntries

Fester Wert "SD"
|-
| colspan="2" |'''comments'''
|'''O [0..1]'''
|K
|Kommentar zum Dokument/Objekt
|-
| colspan="2" |'''patientId'''
|'''M [1..1]'''
|E1
|Patienten-ID in der XDS Affinity Domain
|-
| colspan="5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|-
| colspan="2" |'''hash'''
|'''M [1..1]'''
|A
|Hash Wert des Dokuments. Wird vom Repository befüllt
|-
| colspan="2" |'''homeCommunityId'''
|'''M [1..1]'''
|A
|Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.
|-
| colspan="2" |'''repositoryUniqueId'''
|'''M [1..1]'''
|A
|Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
|-
| colspan="2" |'''size'''
|'''M [1..1]'''
|A
|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository befüllt.
 
|-
| colspan="2" |'''URI'''
|'''NP [0..0]'''[[#%20ftn1|<nowiki/>]][[#%20ftn1|<nowiki/>]]
|A
|Wird in XDS-I nicht verwendet
|-
|-
| colspan="5" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|-
| colspan="2" |'''elgaFlag'''
|'''M [1..1]'''
|B
|Kennzeichnet ein Dokument als "ELGA-Dokument"
|-
| colspan="2" |'''elgaHash'''
|'''M [1..1]'''
|B
|Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes
|}
 [[#%20ftn1|<nowiki/>]]

 


==Überblickstabelle der XDS Metadaten für HL7 CDA Objekte==
Die folgende Tabelle gibt einen Überblick über alle XDS-Metadaten-Elemente. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in IHE bzw. ELGA für das Einbringen von Dokumenten, sowie die Quelle aus der die Informationen stammen.

In der Tabelle 6 werden die XDS-Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität), jeweils für Stable Documents (SD) und On-Demand-Documents (ODD) angegeben.

''Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|C||Aus CDA-Inhalt abgeleitet (direkt oder indirekt, gilt nicht für On-Demand-Documents)
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- 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="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 6: Überblick XDS Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''
| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''
| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
| rowspan="2" style="text-align:left" |'''Beschreibung '''
|- style="background:#CBD7F1"
|'''SD'''9||'''ODD'''10
|- style="background:#CBD7F1"
| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''
|- style="background:white"
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''M [1..1]'''||'''M [1..1]'''
|C||Die Person, welche das Dokument verfasst hat
|- style="background:white"
| ||authorInstitution||'''M [1..1]'''||'''M [1..1]'''
|C||ID und Name der Organisation (Kurzbezeichnung), der die Person angehört, wie im GDA-Index angegeben.
|- style="background:white"
| ||authorPerson||'''M [1..1]'''||'''M [1..1]'''
|C||Daten der Person (Name, ID, etc.)
|- style="background:white"
| ||authorRole||'''R [0..1]'''||'''NP [0..0]'''
|C||Rolle der Person
|- style="background:white"
| ||authorSpeciality||'''R [0..1]'''||'''NP [0..0]'''
|C||Fachrichtung der Person
|- style="background:white"
| colspan="2" |'''classCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Vertraulichkeitscode des Dokuments
|- style="background:white"
| colspan="2" |'''creationTime'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R [0..*]'''||'''R [0..*]'''
|C||Liste von Gesundheitsdienstleistungen
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Format des Dokumenteninhalts
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O [0..1]'''||'''NP [0..0]'''
|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.
|- style="background:white"
| colspan="2" |'''languageCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Sprachcode des Dokuments z.B.: "de-AT"
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R [0..1]'''||'''NP [0..0]'''
|C||Rechtlicher Unterzeichner des Dokuments
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Fachliche Zuordnung des Dokuments
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''NP [0..0]'''||'''NP [0..0]'''
|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)
|- style="background:white"
| colspan="2" |'''Title'''||'''M [1..1]'''||'''M [1..1]'''
|C||Titel des Dokuments
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Global eindeutige ID des Dokuments
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''M [1..1]'''||'''O [0..1]'''
|C||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''M [1..1]'''||'''M [1..1]'''
|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 z.B.: "text/xml" für CDA
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O [0..1]'''||'''O [0..1]'''
|E1||Verweis auf ein referenziertes Dokument
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O [0..1]'''||'''O [0..1]'''
|E1||Typ der Relation zu dem referenzierten Dokument. 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
|}

9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht. 
10 ODD: "On-demand Document": Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird. 
11 Der Inhalt des typeCodes soll mit dem contentTypeCode des Submission Sets übereinstimmen. 
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. 
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein. 

=XDS-I Metadaten für DICOM KOS Objekte=
Die folgenden Kapitel spezifizieren die XDS-I Metadaten von DICOM KOS-Objekten für deren Verwendung in ELGA. Nicht weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt<ref name="ITITF3"/>.

Die folgende Tabelle gibt einen Überblick jener XDS-I Metadaten-Elemente, die direkt aus dem DICOM KOS bzw. der zugrundeliegenden DICOM Study abgeleitet werden können. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in ELGA für das Einbringen von DICOM KOS Objekten, sowie die Quelle aus der die Informationen stammen.

''Tabelle 7: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" |'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

'''der Studie'''
|'''Attribut'''

'''im KOS'''
|'''Beschreibung'''
|- style="background:white"
| colspan="2" |author
|M [1..1]
| colspan="3" |
|- style="background:white"
| rowspan="6" |
|author.authorInstitution
|M [1..1]
|(0008,0080)
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl die Kurzbezeichnung als auch die OID der Institution aus dem GDA-Index anzugeben.

Zur Ermittlung des Namens kann das DICOM Tag (0008,0080) herangezogen werden.

'''Achtung:''' Dieses Attribut ist Type 3 (optional) (General Equipment Module).

'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
|- style="background:white"
| colspan="5" |Die Person, welche die Studie durchführt, ist als author anzugeben:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,1052)
|
|Performing Physicians Identification Sequence

Code und weitere Daten aus dem ersten Item in der Sequence

'''Achtung''': Die Identifikationsdaten der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
|- style="background:white"
|
|
|'''Alternativ:'''

(0008,1050)
|
|Performing Physicians Name

Enthält dieses Attribut mehrere Namen, so ist der erste Name zu wählen.

'''Achtung:''' Die Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
|- style="background:white"
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,0060) + (0008,0070) + (0008,1090)
|
|Modality Code + Manufacturer + Manufacturer's Model Name

'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
|- style="background:white"
| colspan="2" |creationTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date + Study Time

Für den Fall, dass Study Date und Study Time nicht zur Verfügung stehen, ist es zulässig, den Erstellungszeitpunkt des KOS ((0008,0023) contentDate + (0008,0033) contentTime) als creationTime zu verwenden.
|- style="background:white"
| colspan="2" |eventCodeList
|M [1..*]
|
|
|Enthält eine Liste von Codes von Gesundheitsdienstleistungen nach APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten<nowiki/>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</ref>
|- style="background:white"
|
|eventCodeList DisplayNameList
|M [1..1]
|
|
|Enthält den Display Name des APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom" />
|- style="background:white"
| colspan="2" |serviceStartTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|- style="background:white"
| colspan="2" |sourcePatientId
|M [1..1]
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|- style="background:white"
| colspan="2" |sourcePatientInfo
|M [1..1]
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|Die ELGA Vorgabe empfiehlt, Name, Geburtstag und Geschlecht NICHT anzugeben.
|- style="background:white"
| colspan="2" |title
|M [1..1]
|(0008,0060) + (0008,1030)
|
|Der relevante Modality Code der Studie oder alle Modality Codes der Studie und die Study Description.

Alternativ darf anstatt der Study Description der DisplayName des APPC verwendet werden.

'''Anmerkung:'''

Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
 
|- style="background:white"
| colspan="2" |uniqueId
|M [1..1]
|
|(0008,0018)
|Die SOP Instance UID des KOS
|- style="background:white"
| colspan="2" |referenceIdList
|M [1..1]
|
|
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|- style="background:white"
| rowspan="2" |
|value mit CXi.5 = "<nowiki>urn:elga:iti:xds:2014: OwnDocument_setId</nowiki>"
|M [1..1]
|(0020,000D) oder ein vergleichbares Attribut
|(0020,000D) oder ein vergleichbares Attribut
|Die setId zur Klammerung aller Versionen eines KOS

Diese kann von jedem Bereich frei gewählt werden, sie ist mit dem Datentyp '''<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>''' anzugeben.

Eine mögliche Wahl der setId ist die Study Instance UID. Die geeignete Wahl der setId hängt auch vom implementierten Stornoworkflow ab, siehe KOS Leitfaden (Kapitel 8.2.2.)<ref name="KOS-Leitfaden" />
|- style="background:white"
|value mit CXi.5 = "<nowiki>urn:ihe:iti:xds:2013: accession</nowiki>"
|R [0..1]
|(0008,0050) oder ein vergleichbares Attribut wie z.B.

(0040,1001) Requested Procedure ID
 
|(0008,0050)
 
|Die ID, die zur Verlinkung mit dem Befund heranzuziehen ist.

Diese ist mit dem Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' anzugeben.

'''Achtung:'''

Welche ID dazu geeignet ist, die Verlinkung mit dem zugehörigen Befund herzustellen, ist vom jeweils implementierten Workflow abhängig.

Gemäß dem Integrationsprofil IHE RAD Scheduled Workflow dient dazu die Accession Number, die im DICOM Attribut (0008,0050) enthalten ist.

Weicht der lokale radiologische Workflow vom IHE Profil ab, kann es erforderlich sein, ein anderes DICOM Attribut für die Verlinkung heranzuziehen.

Unabhängig von der Wahl des DICOM Attributs ist aber in jedem Fall der Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' zu verwenden.
|- style="background:white"
| colspan="2" |comments
|O [0..1]
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

===author===
Die Person oder Maschine, die das Dokument erstellt hat. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.

Die ''authorInstitution'' benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden können. Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.

*''oid'': OID der Organisation aus dem GDA-Index (muss ermittelt werden)
*''name'': (0008,0080), Institution Name, Name der Organisation als String,
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden. 

'''Achtung:''' Das DICOM-Tag (0008,0080), Institution Name, ist vom Type 3 (optional) (General Equipment Module).

'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
{{EndYellowBox}}

=====Spezifikation=====

'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$name … Name der Organisation, die die Studie erstellt hat

$oid ... OID der Organisation aus dem GDA-Index

concat( 
$name,"^^^^^^^^^", 
$oid,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification>
</pre>

Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.

====authorPerson====
Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche die Bilddaten inhaltlich erstellt hat.

Im Fall eines DICOM Objektes gilt eine Verknüpfung mit folgenden (optionalen) DICOM Attributen:

#Die Person kann aus den DICOM Attributen der Studie abgeleitet werden
#*Identifikator: Code aus Attribut "Performing Physicians Identification Sequence", (0008,1052), Datentyp SQ, wenn vorhanden. Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence.
#*Name: Attribut "Performing Physicians Name", (0008,1050), Datentyp PN (entspricht den ersten 5 Feldern von HL7 V2 Datentyp XPN. Maximum 64 Zeichen pro component group, ohne zusätzliche ideographische und phonetische Zeichen). Wenn mehrere Namen vorhanden sind, ist der erste zu übernehmen.
#*Root: OID-Unterknoten für Personen (entsprechend der Organisations-OID aus dem GDA-Index)
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den folgenden DICOM Attributen abgleitet werden
#*Modalität: Attribut "Modality", (0008,0060), erlaubte Werte siehe DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality <ref name="DICOMModality">DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</ref>
#*Hersteller: Attribut "Manufacturer", (0008,0070)
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090)

{{BeginYellowBox}}
'''Achtung:''' Die Identifikationsdaten und Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.

'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
{{EndYellowBox}}

=====Spezifikation für Personen=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

1.Fall: Bei der lokalen ID handelt es sich um KEINE OID:

$id = Code #1 aus (0008,1052) Performing Physicians Identification Sequence

$person = (0008,1050) Performing Physicians Name

$root = OID-Knoten für den Personenidentifikator

concat( 
 $id,"^", 
 $person,"^", 
 $root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>11375^Musterdoc^Josef^Maria^Msc^DIDr^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>

2. Fall: Bei der lokalen ID handelt es sich um eine OID:

concat( 
 $id,"^", 
 $person 
) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf die XCN Komponenten wie in IHE RAD TF-2 Rev.19 2020<ref name="IHERADTF2">IHE Radiology (RAD) Technical Framework Volume 2x Rev.19, 2020 [https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf]</ref>, "Table 4.68.4.1.2.3-3: XCN Data type mapping" vorgegeben.

=====Spezifikation für Software und Geräte=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$Modality = Modality (0008,0060)

$Manufacturer = Manufacturer (0008,0070)

$ManufacturersModelName = Manufacturer's Model Name (0008,1090)

concat(

"^",

$Modality,"^",

$Manufacturer,"^",

$ManufacturersModelName

) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^CT^Geräthersteller^Gerätename</Value>
</ValueList>
</Slot>
</Classification></pre>

Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objekt Erzeugung innehatte.

Dieser Leitfaden beschreibt keine Einschränkungen für die Verwendung.

Beispiel:

*"Radiologie"
*"Modalität"

====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das KOS-Objekt verfasst hat.

Beispiel:

*"Facharzt für Radiologie"
*"Facharzt für Nuklearmedizin"

=====Spezifikation=====

'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

Bsp: Fachärztin/Facharzt für Radiologie 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Fachärztin/Facharzt für Radiologie</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Wenn eine Person als Autor vorhanden ist, '''MUSS''' der Wert einem DisplayName aus dem Value Set "ELGA_AuthorSpeciality" entsprechen.

Im Fall von Geräten oder Software als Autor '''MUSS''' das Element leer bleiben.

{{EndYellowBox}}

===classCode (und classCodeDisplayName)===
Das ''classCode'' Element klassifiziert (grobe Granularität) das registrierte Objekt und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Objektklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Objektklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#typeCode_.28und_typeCodeDisplayName.29|typeCode]]
|}

====Spezifikation====

'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 

Es wird ein fester Wert gesetzt: 55113-5 "Key images Document Radiology" (LOINC: 2.16.840.1.113883.6.1)

$code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
classifiedObject="theDocument" nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===confidentialityCode===
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.

Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf KOS-Objekte ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt, bzw. fix auf "normal" (N) gesetzt.

Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich. Es wird der Vertraulichkeitscode gemäß folgender Spezifikation übernommen:

Zulässige Werte gemäß Value Set "ELGA_Confidentiality" <ref name="ConfVS">Value Set "ELGA_Confidentiality" https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality</ref>.

====Spezifikation====

confidentialityCode wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$code = "N" $displayName = "normal" $codeSystem = "2.16.840.1.113883.5.25"

<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="theDocument" nodeRepresentation="N">
<Name>
<LocalizedString value="normal"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:2.16.840.1.113883.5.25</Value>
</ValueList>
</Slot>
</Classification></pre>

===creationTime===
Das creationTime Element beschreibt den Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes. Es soll die Zeit angegeben werden, die diese Erstellungszeit am besten beschreibt:

#Erstellungsdatum der Studie (aus dem KOS Objekt oder der DICOM Studie):
#*Study Date (0008,0020)
#*Study Time (0008,0030)
#Sollte das zuvor genannte Attribut nicht verfügbar sein, muss alternativ das Erstellungsdatum des KOS Objektes verwendet werden:
#*Content Date (0008,0023)
#*Content Time (0008,0033)

Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From ''UTC''<ref>Timezone Offset From UTC http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</ref> berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

====Spezifikation====

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 

$date = (0008,0020) Study Date oder (0008,0023) Content Date

$time = (0008,0030) Study Time oder (0008,0033) Content Time und (0008,0201) Timezone Offset from UTC

concat(

$date,

$time

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="creationTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.{{EndYellowBox}}

===eventCodeList (und eventCodeListDisplayName)===
Dieses Element enthält eine Liste der erbrachten Gesundheitsdienstleistungen, die das registrierte Dokument oder Objekt beschreibt. Im Fall von Bilddaten findet der APPC Anwendung. (Die korrekte Verwendung von APPC in DICOM Objekten wird im entsprechenden Leitfaden der DICOM Austria spezifiziert: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten"<ref name="KOS-Leitfaden"></ref>).
Es können mehrere APPC bzw. Events (und displayNames) angegeben werden. Sind mehrere Events vorhanden, muss die Reihenfolge der Events und zugehörigen displayNames gleich sein.

====Spezifikation====

'''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 

Für jedes documentationOf Element [1..n]: 

$code = APPC code (alle Achsen) z.B. "2.4.0.5-3-3" 
$displayName = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule" 
$codeSystem = OID des Codesystems APPC: 1.2.40.0.34.5.38 
<pre class="ilfbox_code">
<Classification
classificationScheme=
"urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
classifiedObject="theDocument"
nodeRepresentation="$code">
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
<Name>
<LocalizedString value="$displayName"/>
</Name>
</Classification>
</pre>

===languageCode===
Das ''languageCode'' Element beschreibt den Sprachcode in dem ein Dokument oder Objekt verfasst bzw. beschlagwortet ist. Derzeit wird ein fester Wert vorgeschrieben: '''de-AT'''
====Spezifikation====

'''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

Fester Wert "de-AT"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/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===
Dieses Element darf für XDS-I nicht verwendet werden [NP].

===serviceStartTime / serviceStopTime===
Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts bzw. der Untersuchung. Für KOS-Objekte kann die ''serviceStartTime'' aus dem Objekt gemappt werden:

#Das Erstellungsdatum der Studie (aus dem KOS Objekt oder bevorzugt der DICOM Studie):
#*Study Date (0008,0020)
#*Study Time (0008,0030)
#Alle Zeiten müssen in XDS in UTC konvertiert werden, daher sollte Timezone Offset From UTC berücksichtigt werden, falls angegeben:
#*Timezone Offset From UTC (0008,0201)

Für die serviceStopTime steht kein Mapping zur Verfügung und wird daher nicht angegeben [NP].

====Spezifikation====
'''serviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat(

Study Date,

Study Time + Timezone Offset from UTC

)
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="serviceStartTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden!
{{EndYellowBox}}

===sourcePatientId===
Das ''sourcePatientId'' Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA.

Für ein Mapping aus KOS steht folgendes Attribut zur Verfügung:

(0010,0020) Patient ID (VR:LO, VM:1)

Eine OID zur Definition des Namensraumes des verwendeten Patientenidentifikators muss entsprechend vorhanden sein.
====Spezifikation====

'''sourcePatientId''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$patientID = (0010,0020) Patient ID

$oid = OID des lokalen Patientenidentifikators

concat(

$patientID,

"^^^&amp;",

$oid,

"&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" />.

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.
{{BeginYellowBox}}
In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
{{EndYellowBox}}

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modality Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. ("CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule")
{{BeginYellowBox}}
'''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
{{EndYellowBox}}
====Spezifikation====

'''title''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:

concat(

Modality,

" ",

Study Description

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Name>
<LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" />
</Name>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
{{EndYellowBox}}

===typeCode (und typeCodeDisplayName)===
Das ''typeCode'' Element beschreibt den Objekttyp, dem das KOS Objekt angehört. Der Objekttyp ist die Spezialisierung einer Objektklasse, jeder Objekttyp gehört zu genau einer Objektklasse.

Unterscheidung typeCode/classCode:
{| class="wikitable"
|- style="background:white"
|'''typeCode'''
|'''Objektklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
|classCode
|Objektklasse in grober Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29|classCode]]
|}

====Spezifikation====

'''typeCode (und typeCodeDisplayName)''' wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:

Es wird ein fester Wert gesetzt: '''55113-5''' "Key images Document Radiology"

 $code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="KeyImageObject"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

====submissionSet.contentTypeCode====
Der contentTypeCode des Submission Sets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.

$code = "55113-5"

$displayName = "Key images Document Radiology"

$codeSystem = "2.16.840.1.113883.6.1"<pre class="ilfbox_code">
<RegistryPackage
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
<Classification
classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
classifiedObject="KeyImageObject"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</RegistryPackage>
</pre>Jeder Container darf dementsprechend nur 1 Objekt enthalten.

===uniqueId===
Das ''uniqueId'' Element beschreibt den global eindeutigen Identifier des Objektes. Dieser Identifier wird vom Document Source Actor erzeugt.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

(0008,0018) SOP Instance UID (VR:UI, VM:1)
====Spezifikation====

uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:

$value = (0008,0018) SOP Instance UID

<pre class="ilfbox_code">
<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. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:

#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId, M [1..1])
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number, R [0..1])
#Verlinkung zwischen DICOM KOS-Objekten und einer Aufenthaltszahl (encounterId, O [0..1])

'''Weitere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.'''

Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.

Dieser Datentyp ist in IHE ITI Data Types in folgender Weise spezifiziert:<ref name="ITITF3"/>

{| 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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}
{{BeginYellowBox}}

'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.
{{EndYellowBox}}

====Versionierung bzw. Versionsklammer (ownDocument_setId)====
Um eine eindeutige Identifikation aller registrierten Versionen eines Objektes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Es kann ein beliebiger Identifikator verwendet werden, solange er die Anforderung erfüllt, alle registrierten Versionen eines KOS-Objektes mit derselben ID eindeutig zu kennzeichnen. Als Best Practice für KOS wird die Verwendung von ''StudyInstanceUID'' vorgeschlagen.

=====Spezifikation=====
ownDocument-SetId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

Für KOS Objekte kann die ''StudyInstanceUID'' (0020,000D) als SetId verwendet werden.

$id = (0020,000D) VR=UI Study Instance UID, z.B. 1.2.40.0.34.99.111.1.1

$homeCommunityId = OID des lokalen ELGA-Bereiches. Diese MUSS [1..1], unabhängig vom für $id gewählten Identifier, angeführt sein, z.B. 1.2.40.0.34.99.999

concat

(

$id, "^^^^",

"<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>", "^",

"&amp;",

$homeCommunityId, "&amp;ISO"

)

Wie oben angeführt wird folgender CXi Wert für <Value> erstellt:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.

====Referenz zwischen Dokument und Studie (Accession Number)====
Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (''acquisition, store'') als auch bei der Befundschreibung (''report'') verfügbar ist. Dies trifft auf die Accession Number zu (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).

=====Spezifikation=====
Bei der Registrierung von KOS Objekten MUSS eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden.

Für Befunde der Bildgebenden Diagnostik (diagnostic image report) kann die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Accession Number z.B. 20201111

$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>20201111^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"

====Referenz zwischen Aufenthaltszahl und Studie (encounterId)====
Durch encounterId wird die Verlinkung sämtlicher Bilddaten (DICOM KOS-Objekte), die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-I Metadaten unterstützt. Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird.

=====Spezifikation=====
Bei der Registrierung von KOS Objekten KANN eine encounterId in den XDS-I Metadaten in der ReferenceIdList angegeben werden.

encounterId wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Aufenthaltszahl z.B. Az123456

$root = OID der Liste der Aufenthaltszahlen der Organisation, z.B. 1.2.40.0.34.99.4613.3.4

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>Az123456^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.4613.3.4<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>
</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

====Weitere Einträge der referenceIDList====
Über die bereits genannten Einträge hinaus sind weitere Einträge in der referenceIdList erlaubt:

*'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki>. In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.
*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki>

Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId
</nowiki>^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
<Value>20201111^^^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
<Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value>
<Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===intendedRecipient===
Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der ''intendedRecipient'' notwendig. Derzeit wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.

Der intendedRecipient entfällt bei der Registrierung von KOS Objekten via XDS-I.

===comments===
Das ''comments'' Element enthält Kommentare zum Objekt. Die Verwendung ist in ELGA optional (wird in einigen Implementierungen nicht angezeigt, z.B. ELGA Bürgerportal)

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
(0008,1030) Study Description (VR:LO, VM:1)

====Spezifikation====
Comments wird gemäß folgender Vorschrift zusammengesetzt:
$comment = (0008,1030) Study Description<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Description">
<LocalizedString value = "$comment"/>
</Description>
</ExtrinsicObject>
</pre> 

==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
===availabilityStatus===
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Objektes.

Mögliche Werte laut IHE sind:

*Approved
*Deprecated

Dieses Attribut wird im Zuge des Einbringens von neuen Objekten ("Submission") durch die empfangende XDS Registry immer auf "'''Approved'''" gesetzt.

availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.

<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

===formatCode (und formatCodeDisplayName)===
Das ''formatCode'' Element beschreibt das Format des registrierten Objekts. Es ermöglicht einem empfangenden System (''Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Objektformats und somit die korrekte Darstellung und Verarbeitung.

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

 
$code = "1.2.840.10008.5.1.4.1.1.88.59" 
$displayName = "Key Object Selection Document" 
$codeSystem = "1.2.840.10008.2.6.1"
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA, z.B.

*158 "Fachärztin/Facharzt"
*300 "Allgemeine Krankenanstalt"

Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]".
{{EndYellowBox}}

====Spezifikation====

'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

$code = Klassifizierung des GDA (Code)

$displayName = Klartext des angegebenen Codes

$codeSystem = OID der ausgebenden Stelle

<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===mimeType===
Das ''mimeType'' Element beschreibt den "Internet Media Type" des Objektes gemäß dem "Multipurpose Internet Mail Extensions" (MIME) Standard. Der Standard wird beschrieben in RFC 2045<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref> und RFC 2049<ref name="RFC2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>.

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, welches das DocumentEntry repräsentiert.

Folgende Mime-Types sind für DICOM KOS Objekte zugelassen:

*application/dicom 
<pre class="ilfbox_code">
<ExtrinsicObject
id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
mimeType="application/dicom"
objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>
</pre>

===practiceSettingCode (und practiceSettingCodeDisplayName)===
Das ''practiceSettingCode'' Element beschreibt die fachliche Zuordnung des Objektes. Es soll den Fachbereich wiedergeben, dem der Inhalt des Objektes am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung, z.B.:

*F044 "Radiologie"
*F052 "Unfallchirurgie"

Im KOS-Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_PracticeSetting_VS ELGA_PracticeSetting_VS]".
{{EndYellowBox}}

====Spezifikation====

'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

$code = Code aus Value Set ELGA_PracticeSetting $displayName = Klartext des angegebenen Codes (displayName) $codeSystem = OID des Codesystems (1.2.40.0.34.5.12) 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===objectType===
Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "stabiles Dokument" (stable document, SD) und "On-demand Dokument" (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.

Für KOS Objekte wird der fixe Wert "<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="application/dicom"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

==ELGA-spezifische Erweiterungen der XDS-Metadaten==
Die folgenden Daten entsprechen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information.

===elgaFlag===
Das elgaFlag dient zur Kennzeichnung eines Objektes als "ELGA-Objekt"18. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:

*"true" oder
*"false"

18 Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Objekte auftreten, die NICHT für ELGA vorgesehen sind.

====Spezifikation====

<pre class="ilfbox_code">
<Slot name="urn:elga-bes:elgaFlag">
<ValueList>
<Value>true</Value>
</ValueList>
</Slot>
</pre>

===elgaHash===
Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot "ELGA-Hash" gespeichert.

Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.

====Spezifikation====
<pre class="ilfbox_code">
<rim:Slot name="urn:elga-bes:elgaHash">
<rim:ValueList>
<rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>
</rim:ValueList>
</rim:Slot>
</pre>

=XDS Metadaten für CDA Dokumente=
Die folgenden Kapitel spezifizieren die XDS-Metadaten von HL7 CDA-Dokumenten für deren Verwendung in ELGA. Nicht angegebene Metadaten sind nicht weiter eingeschränkt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol. 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.<ref name="ITITF3"/>

==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).

CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen.

====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurde.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört, grundsätzlich in folgendem Element abgelegt:
##ClinicalDocument/author/assignedAuthor/representedOrganization
#Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:
##'''id'''[1] … ID der Organisation mit den folgenden Attributen:
###@root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)
###@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)
##'''name''' … Name der Organisation als String Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.
#GDA, in deren Gültigkeitsbereich Dokumente erstellt werden können, sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da es vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden.
{{EndYellowBox}}

=====Spezifikation=====

'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$inst … ClinicalDocument/author/assignedAuthor/representedOrganization

*Fall 1: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist nicht vorhanden 

concat( 
$inst/name,"^^^^^^^^^", 
$inst/id[1]/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO</Value>
</ValueList>
</Slot>
</Classification>
</pre>

*Fall 2: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist vorhanden 

concat( 
$inst/name,"^^^^^&", 
$inst/id[1]/@root,"&ISO^^^^" 
$inst/id[1]/@extension 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&amp;ISO^^^^45</Value>
</ValueList>
</Slot>
</Classification>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

====authorPerson====
Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche das Dokument inhaltlich erstellt hat (also nicht die Schreibkraft).

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit CDA Header Elementen:

#Laut Festlegung wird der Autor im Header-Element "author" abgelegt:
##ClinicalDocument/author/assignedAuthor
#Der Autor (Person)
##Ein Personenelement enthält unter anderem die folgenden Unterelemente:
###id … ID der Person mit den folgenden Attributen:
####@root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
####@extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
###assignedPerson
####Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
#####name
#Gerät oder Software als Autor
##Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:
###assignedAuthoringDevice
####Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software
#####manufacturerModelName
####Enthält ein Element mit dem Namen des Geräts oder der Software
#####softwareName

=====Spezifikation für Personen=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

 $person = ClinicalDocument/author/assignedAuthor

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
{{BeginYellowBox}}
Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.
{{EndYellowBox}}
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

=====Spezifikation für Software und Geräte=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

 $person = ClinicalDocument/author/assignedAuthor

concat( 
"^", 
 $person/assignedAuthoringDevice/manufacturerModelName,"^", 
 $person/assignedAuthoringDevice/softwareName 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^Good Health System^Best Health Software Application</Value>
</ValueList>
</Slot>
</Classification></pre>

Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.

Beispiel:

*"Diensthabender Oberarzt"
*"Verantwortlicher diensthabender Arzt für die Dokumenterstellung"

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Laut Festlegung wird die "Rolle" der Person, welche das Dokument inhaltlich erstellt hat, im Element functionCode des Autors abgelegt:
##''ClinicalDocument/author/functionCode''
#Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.

=====Spezifikation=====

'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/functionCode/@displayName 
<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorRole">
<ValueList>
<Value>Diensthabender Oberarzt</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.

Beispiel:

*"Facharzt für Gynäkologie"
*"Facharzt für interne Medizin"

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Laut Festlegung wird die "Fachrichtung" der Person, welche das Dokument inhaltlich erstellt hat, im Element code des Autors abgelegt:
##''ClinicalDocument/author/assignedAuthor/code''
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.

=====Spezifikation=====

'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/assignedAuthor/code/@displayName 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Anästhesiologie und Intensivmedizin</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

===classCode (und classCodeDisplayName)===
Das ''classCode'' Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Dokumentenklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Dokumentenklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2|typeCode]]
|}

====Spezifikation====

'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 

$code = ClinicalDocument/code/translation/@code 
$displayName = ClinicalDocument/code/translation/@displayName 
$codeSystem = ClinicalDocument/code/translation/@codeSystem 
<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: 

<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.
Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird dieser Zeitpunkt wie folgt abgelegt:
##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:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
CreationTime entfällt bei On-Demand Documents.
{{EndYellowBox}}

====Spezifikation====

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 
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: 

Für jedes documentationOf Element 1..n: 

$code = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code 
$displayName = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName 
$codeSystem = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem 
<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: 

 $person = ClinicalDocument/legalAuthenticator/assignedEntity

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<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) Achtung: Diese ID gelangt nicht in die Metadaten!

====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. 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:

 $code = ClinicalDocument/code/@code 
 $displayName = ClinicalDocument/code/@displayName 
 $codeSystem = ClinicalDocument/code/@codeSystem 
<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: 

Fall 1 
Attribut ClinicalDocument/id/@extension ist nicht vorhanden

$value = concat(ClinicalDocument/id/@root)

Fall 2 
Attribut ClinicalDocument/id/@extension ist vorhanden

$value = concat(
ClinicalDocument/id/@root, "^",
ClinicalDocument/id/@extension
)

<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..1])
#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).

{{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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}

{{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 (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).

=====Spezifikation=====
Bei der Registrierung von KOS Objekten MUSS eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden.

Für Befunde der Bildgebenden Diagnostik (diagnostic image report) KANN die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Accession Number z.B. 20201111

$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"<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"
 
====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.

 
=====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>

 

===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: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = ClinicalDocument/hl7at:formatCode/@displayName 
$codeSystem = 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:

$code = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code

$displayName = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName

$codeSystem = 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: 
CDA R2: '''text/xml''' 

<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:

$code = ClinicalDocument/hl7at:practiceSettingCode/@code 
$displayName = ClinicalDocument/hl7at:practiceSettingCode/@displayName 
$codeSystem = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem 
<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"18. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:

*"true" oder
*"false"
18 Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.
====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=

==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.

ILF:XDS Metadaten (Version 3)

2021-03-26T07:13:07Z

Kuttin: /* Überblickstabelle der XDS-I Metadaten für DICOM KOS Objekte */

{{#seo:
|title=XDS Metadaten 3.0.0
|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 (Version 3.0.0)}}



{{#css:
@media screen{
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.toc{
width: 20%;
float: right !important;
margin: 10px 0px 10px 30px !important;
border: 1px solid #AAA;
background-color: #F9F9F9;
display: table;
padding: 7px !important;
}
}
}}

{{Infobox Dokument
|Group = ELGA CDA Implementierungsleitfäden
|Title = ELGA XDS Metadaten (XDSDocumentEntry)
|Subtitle = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA [1.2.40.0.34.7.6.9.3]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0+20210324
|Submitted = ELGA GmbH
|Date = März 2021
|Copyright = 2011-
|Status = Reconciliation
|Period = n.a.
|OID = 1.2.40.0.34.7.6.9.3
|Realm = Austria
}}

{{TOC limit|4}}



{{#css:
.orange{
border: thin black solid;
background-color:#F4C789;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
}
}}

=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;">
==Impressum==
<div class="mw-collapsible-content">
''Medieneigentümer, Herausgeber, Hersteller, Verleger:'' 
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050 
Internet: [http://www.elga.gv.at www.elga.gv.at]
Email: [mailto:cda@elga.gv.at cda@elga.gv.at] 
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch

''Redaktion, Projektleitung, Koordination: '' 
Mag.Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]

''Abbildungen:'' Sofern nicht anders angegeben: © ELGA GmbH

''Nutzung'': Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria [http://www.hl7.at www.hl7.at]. 
Die Nutzung ist ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter [https://www.gesundheit.gv.at www.gesundheit.gv.at] und [https://www.elga.gv.at/cda www.elga.gv.at/cda]
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

==Haftungsausschluss==
<div class="mw-collapsible-content">
Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht und über ein öffentliches Kommentierungsverfahren kontrolliert. Die Nutzung des vorliegenden Leitfadens erfolgt in ausschließlicher Verantwortung der Anwender. Aus der Verwendung des vorliegenden Leitfadens können keinerlei Rechtsansprüche gegen die Autoren, Herausgeber oder Mitwirkenden erhoben und/oder abgeleitet werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls nicht beabsichtigt und von den Erstellern des Dokumentes nicht gewünscht.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

==Sprachliche Gleichbehandlung==
<div class="mw-collapsible-content">
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer, Frauen und andere Geschlechtsidentitäten in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
</div></div>

==Lizenzinformationen==
Die Verwendung dieses Leitfadens für die Zwecke der Erstellung, des Verkaufs und des Betriebs von Computerprogrammen, sofern nicht anders angegeben oder sich die Standards auf andere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen, ist ausdrücklich genehmigt. 

Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> .

===Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")===
<div style="border: thin #77c123 solid;width:100%; margin-left: 10px">
<div style="line-height: 1.25; font-size:16px; border-bottom: 1px solid #81ab1f; box-shadow: 0 4px 0 0 #a2d727;margin-bottom:4px; color:#77c123; width:100%">
Third Party Intellectual Property
</div>
<div style="width:100%;">


Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass der Herausgeber nicht alle Rechte und Ansprüche in und an den Materialien besitzt und dass die Materialien geistiges Eigentum von Dritten enthalten und / oder darauf verweisen können ("Third Party Intellectual Property (IP)"). 

Die Anerkennung dieser Lizenzbestimmungen gewährt dem Lizenznehmer keine Rechte in Bezug auf Third Party IP. Der Lizenznehmer allein ist für die Identifizierung und den Erhalt von notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig verantwortlich. 

Jegliche Handlungen, Ansprüche oder Klagen eines Dritten, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, bleiben die Haftung des Lizenznehmers.

</div>
</div>

==Verbindlichkeit==
Die Verbindlichkeit und die Umsetzungsfrist von Leitfäden sind im Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.

Ein Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf [http://www.gesundheit.gv.at www.gesundheit.gv.at] zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten ("Mandatory" (M), "Required" (R) und "Fixed" (F)), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.

Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit der Rechtsordnung der Republik Österreich und insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz 2000, Gesundheitstelematikgesetz 2012) zu erfolgen. Technische Möglichkeiten können gesetzliche Bestimmungen selbstverständlich nicht verändern, vielmehr sind die technischen Möglichkeiten im Einklang mit den Gesetzen zu nutzen.

Die Einhaltung der gesetzlichen Bestimmungen liegt im Verantwortungsbereich der Ersteller der CDA-Dokumente.

==Verwendete Grundlagen und Bezug zu anderen Standards==
Grundlage dieses Implementierungsleitfadens ist der internationale Standard IHE ITI Cross-enterprise Document Sharing <ref name="IHE ITI"></ref> von Integrating the Healthcare Enterprise (IHE)<ref name="IHE">Integrating the Healthcare Enterprise (IHE) International, Incorporated [http://www.ihe.net http://www.ihe.net]</ref>.

Weiters bezieht sich dieser Leitfaden auf den internationalen Standard "HL7® Clinical Document Architecture, Release 2.0" (CDA ®)<ref name="CDA"></ref>, für die das Copyright © von Health Level Seven International<ref name="HL7">Health Level Seven International [http://www.hl7.org www.hl7.org]</ref> gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert<ref name="ISO CDA">ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical Document Architecture, Release 2 [https://www.iso.org/standard/44429.html https://www.iso.org/standard/44429.html]</ref>. CDA definiert die Struktur und Semantik von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und Patienten. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen.
Die Dokumentmetadaten für CDA Dokumente im Österreichischen Gesundheitswesen werden grundsätzlich vom "Allgemeinen CDA Implementierungsleitfaden"<ref name="ALF">Allgemeiner Implementierungsleitfaden für CDA Dokumente [https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_(Version_3) https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_(Version_3)]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden. Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens Version 3]''' und gilt entsprechend für alle CDA-Dokumente, die auf Basis des Leitfadens erstellt werden.
{{EndILFBox}}

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website: [[ILF: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 ([http://www.elga.gv.at/CDA Website der ELGA GmbH]) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:

*ELGA-Gesamtarchitektur<ref name="ELGA-Gesamtarchitektur">ELGA-Gesamtarchitektur 2.30a [http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>
*Beispieldokumente
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
*CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
*Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
*Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
*Hinweise für die zu verwendenden Terminologien
*Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}

==Bedienungshinweise==
===Farbliche Hervorhebungen===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''<Hinweis>''' authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
{{EndYellowBox}}
''Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>
''Verweis auf ELGA Value Set:''
{{BeginILFBox}}
'''<Verweis>''' Zulässige Werte gemäß Value Set '''"ELGA_FormatCode".'''
{{EndILFBox}}

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

===PDF-Navigation===
<div class="mw-collapsible-content">
Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

*Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
*Seitenweise blättern: "Bild" Tasten
*Scrollen: Pfeil nach oben bzw. unten
*Zoomen: Strg + Mouserad drehen
*Suchen im Dokument: Strg + F
</div></div>



=Harmonisierung=
'''Erarbeitung des Implementierungsleitfadens''' 
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%" |Person1
|- 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
|}

1 Namen ohne Titel


=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 beim Einbringen von Dokumenten in Form von Befunden<ref name="ALF"></ref> oder Bilddaten in die ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumente (Metadaten der XDSDocumentEntry Objekte): ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 12.0 (22.4.2016) Final Text''<ref name="ITITF3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 12.0 (2016) [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf], zuletzt besucht am 25.01.2021</ref>

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.

Etwaige, Service-spezifische, Vorgaben auf Schnittstellen-Ebene sind in den entsprechenden Schnittstellenspezifikationen (u.a. Schnittstellen Berechtigungssystem, Schnittstellenspezifikation zur Anbindung des elektronischen Impfpasses) angeführt und im Rahmen konkreter System-Anbindungen zu berücksichtigen.

==Hinweise zur Verwendung des Dokuments==
===Codesysteme und Value Sets===
Die in diesem Dokument erwähnten Codesysteme bzw. Value Sets werden am Terminologieserver (https://www.gesundheit.gv.at/gesundheitssystem/professional/it-services/terminologieserver-doku) und auf der Website der ELGA GmbH (http://www.elga.gv.at) veröffentlicht.

Wenn codierte Werte angegeben werden, ist es immer die Aufgabe des Document Consumers, die korrekten lesbaren Werte anzuzeigen. Es wird nicht empfohlen, die in den XDS-Metadaten verfügbaren DisplayNames direkt zur Anzeige zur verwenden, da Schreibweisen der DisplayNames variieren oder in unterschiedlichen Sprachen angegeben sein können.

===OID ===
In diesem Dokument wird an vielen Stellen die Verwendung von OID vorgeschrieben. OID sind Objekt-Identifikatoren oder Objektkennungen, die als weltweit eindeutige Namen für Informationsobjekte dienen (ISO/IEC 9834-1). Weitere Informationen zur Verwendung und Registrierung von OID sind im "OID-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.

Die Vorgaben für die Erstellung der CDA-Dokumente sind in den "ELGA CDA-Implementierungsleitfäden" ersichtlich. Nur über eine Verordnung definierte Dokumentenklassen dürfen in ELGA verwendet werden, alle Dokumente MÜSSEN entsprechend der Spezifikationen der ELGA CDA-Implementierungsleitfäden erstellt werden.

===Dokumentlebenszyklus und XDS-Transaktionen===
ELGA unterstützt die im folgenden aufgezählten Aktionen (in Klammer die entsprechende ITI-Transaktion). Alle Transaktionen werden in den Protokollierungssystemen aufgezeichnet:

====Bereitstellen [ITI-41] und Veröffentlichen [ITI-42]====
Ein neues Dokument wird entsprechend IHE XDS im Repository gespeichert und durch Registrieren der XDS-Metadaten in der Registry für ELGA bereitgestellt. Neu veröffentlichte Dokument-Metadaten werden immer mit dem Status "approved" versehen.

====Ersetzen eines Dokuments durch eine neue Version ("Updaten") [ITI-41]====
Änderungen eines für ELGA bereitgestellten Dokumentes sind NICHT ERLAUBT.

Es ist allerdings möglich, ein Dokument durch ein anderes zu ersetzen, indem ein neues Dokument (bzw. eine neue Version des Dokumentes) gespeichert und registriert wird. Hierbei MUSS die SetId der referenceIdList in den XDS-Metadaten zum neuen Dokument der der Vorgängerversion entsprechen. Die XDS-Metadaten der Vorgängerversion des Dokumentes bekommen den Status "deprecated". In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp "replace" (RPLC)).

Beim Ersetzen von ELGA Dokumenten wird das ELGA Berechtigungssystem eventuell zugeordnete individuelle Zugriffsberechtigungen unabhängig von ihrer Anzahl auch auf die Nachfolgeversionen anwenden.

====Stornieren [ITI-57, XDS Metadata Update]====
Dokumente werden "storniert", indem der Dokumentstatus auf "deprecated" gesetzt wird und keine neue Dokumentenversion registriert wird.

===Größenbeschränkung ===
ELGA schreibt für die Größe der eingebrachten CDA eine Maximalgröße von 20 MB vor. Größere Dokumente sind abzulehnen. Es liegt generell in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten |Allgemeiner Implementierungsleitfaden
für ELGA CDA Dokumente, Kapitel 6.10]].

==Allgemeines zu XDS-Metadaten==
Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumente entsprechend klassifiziert und beschrieben werden. Diese beschreibenden "Metadaten" werden in Form einer Nachricht gemeinsam mit dem Dokument an das Repository mitgegeben. Da IHE XDS Systeme grundsätzlich für beliebige Dokumentformate offen sind, gilt dies für alle Arten von Dokumenten (CDA, PDF, Bilder, etc.) gleichermaßen.

Die Metadaten eines Dokuments (XDSDocumentEntry) in einem IHE XDS System beinhalten Informationen
* über das Dokument selbst – um eine Klassifizierung und eine korrekte Darstellung des Dokumenteninhalts zu ermöglichen
* über eventuelle Beziehungen zu anderen Dokumenten (z.B. zu älteren Versionen eines Dokuments)
* über den Speicherort des Dokuments
* über den GDA, welcher das Dokument erstellt hat
* über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).
Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE "IT-Infrastructure" (ITI) Technical Framework, Volume 3 festgelegt (IHE ITI TF-3)<ref name="ITITF3"/>.

Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.
{{BeginYellowBox}}
Die Metadaten sind die ausschließliche Grundlage für das Suchen und Filtern von Dokumenten in einem XDS Dokumentenregister und somit im ELGA Verweisregister, daher ist die korrekte Verschlagwortung der Dokumente mit den Metadaten eine notwendige Voraussetzung.
{{EndYellowBox}}

'''Hinweis:''' Siehe auch Vorschriften zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3<ref name="ITITF3"/>.

===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument oder binären Objekt entnommen werden und müssen daher von der erstellenden Anwendung mitgegeben werden. Es entsteht dadurch ein zusätzlicher Aufwand insbesondere hinsichtlich der Qualität der Daten. Die Metadaten müssen das beiliegende Dokument oder binäre Objekt korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden.

===Metadaten aus strukturierten Dokumenten (CDA)===
Strukturierte Dokumente bieten die Möglichkeit, die Informationen für die Metadaten beim Einbringen in ein Repository in gewissem Maße aus den Dokumenten selbst automatisiert zu entnehmen. Das vermindert daher die Menge der Informationen, die separat erhoben oder ermittelt werden muss.

Die IHE hat im Rahmen des "Patient Care Coordination" (PCC) Technical Frameworks eine genaue Vorschrift spezifiziert, aus welchen Bereichen des CDA Dokuments die Metadaten entnommen werden sollen.

Die genaue Beschreibung der einzelnen XDS Metadaten Bindings sind im IHE "Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2, Kapitel XDSDocumentEntry Metadata beschrieben.<ref name="IHEPCC">IHE "Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2 [https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf]</ref>

===Metadaten aus "On-Demand Documents" (ODD) ===
Ü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"/>.

===Metadaten aus Bilddaten (KOS)===
Bilddaten können über KOS-Objekte (Key Object Selection Document) referenziert und abgerufen werden. Die notwendigen Metadaten können in gewissem Maße aus diesen KOS-Objekten selbst automatisiert entnommen werden. Eine genaue Beschreibung für den Aufbau von KOS-Objekten findet sich im Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch.

===XDS Metadaten im Vergleich IHE vs. ELGA===
Die vollständige Liste der XDS Metadaten Elemente kann man in folgende Arten von Elementen unterteilen:
# Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
# Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)
# '''Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können (XDS Document Source)'''
# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
## '''ELGA relevante'''
## Nicht ELGA relevante
Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).

==Überblickstabelle der XDS-I Metadaten für DICOM KOS Objekte==

Die folgende Tabelle gibt einen Überblick über alle XDS-I Metadaten-Elemente. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in IHE bzw. ELGA für das Einbringen von DICOM KOS Objekten, sowie die Quelle aus der die Informationen stammen.

In der Tabelle 3 werden die XDS-I Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität) angegeben.

 ''Tabelle 1: Legende zur Spalte "Quelle" der folgenden Tabelle''

{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|K||Aus KOS-Inhalt abgeleitet
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- style="background:#white"
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
|}

''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" |'''Metadaten Element'''
|'''Optionalität'''
|'''Quelle'''
|'''Beschreibung'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''M [1..1]'''
|<nowiki>-</nowiki>
|Die Person oder das Gerät, welche(s) das Dokument verfasst hat
|-
| rowspan="4" |
|authorInstitution
|'''M [1..1]'''
|E1/K
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|-
|authorPerson
|'''R [0..1]'''
|K
|Daten der Person

(Name, ID, etc.)
|-
|authorRole
|'''R [0..1]'''
|K
|Rolle der Person
|-
|authorSpeciality
|'''R [0..1]'''
|E1/K
|Fachrichtung der Person
|-
| colspan="2" |'''classCode'''
|'''M [1..1]'''
|A
|Dokumenten/Objektklasse (Oberklasse)

z.B.: 55113-5 "Key images Document Radiology"
|-
| colspan="2" |'''confidentialityCode'''
|'''M [1..1]'''
|A
|Vertraulichkeitscode. Fester Wert "N"
|-
| colspan="2" |'''creationTime'''
|'''M [1..1]'''
|K
|Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes
|-
| colspan="2" |'''eventCodeList'''
|'''M [1..*]'''
|A/K
|Liste von Codes von Gesundheitsdienstleistungen
|-
|
|'''eventCodeDisplayName'''
|'''M [1..1]'''
|A/K
|Bezeichnung von Gesundheitsdienstleistungen nach APPC
|-
| colspan="2" |'''intendedRecipient'''
|'''NP [0..0]'''
| -
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
|-
| colspan="2" |'''languageCode'''
|'''M [1..1]'''
|A
|Sprachcode. Fester Wert "de-AT"
|-
| colspan="2" |'''legalAuthenticator'''
|'''NP [0..0]'''
| -
|Rechtlicher Unterzeichner
|-
| colspan="2" |'''serviceStartTime'''
|'''M [1..1]'''
|K
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|-
| colspan="2" |'''serviceStopTime'''
|'''NP [0..0]'''
| -
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
|-
| colspan="2" |'''sourcePatientId'''
|'''M [1..1]'''
|K
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|-
| colspan="2" |'''sourcePatientInfo'''
|'''NP [0..0]'''
| -
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
|-
| colspan="2" |'''title'''
|'''M [1..1]'''
|A/K
|Titel des Dokuments
|-
| colspan="2" |'''typeCode'''
|'''M [1..1]'''
|A
|Objekttyp (Unterklasse)

codierter Wert
|-
| colspan="2" |'''uniqueId'''
|'''M [1..1]'''
|K
|Global eindeutige ID des Objektes

z.B. SOP Instance UID
|-
| colspan="2" |'''referenceIdList'''
|'''M [1..*]'''
|K/E1
|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|-
| colspan="5" |'''''Explizit zu setzende Metadaten'''''
|-
| colspan="2" |'''availabilityStatus'''
|'''M [1..1]'''
|E1
|Gültigkeit des Objektes
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|E1
|Format des Objektes
|-
| colspan="2" |'''healthcareFacilityTypeCode'''
|'''M [1..1]'''
|E1
|Klassifizierung des GDA
|-
| colspan="2" |'''mimeType'''
|'''M [1..1]'''
|E1
|Mime Type des Dokuments

Fester Wert für KOS: "application/dicom"
|-
| colspan="2" |'''parentDocumentId'''
|'''O [0..1]'''
|E1
|Verweis auf ein referenziertes Objekt
|-
| colspan="2" |'''parentDocumentRelationship'''
|'''O [0..1]'''
|E1
|Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC, XFRM
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|E1
|Fachliche Zuordnung des Dokuments
|-
| colspan="2" |'''entryUUID'''
|'''M [1..1]'''
|E1
|UUID des Metadaten-Records des Dokuments(XDS DocumentEntry)
|-
| colspan="2" |'''objectType'''
|'''M [1..1]'''
|E1
|Typ des DocumentEntries

Fester Wert "SD"
|-
| colspan="2" |'''comments'''
|'''O [0..1]'''
|K
|Kommentar zum Dokument/Objekt
|-
| colspan="2" |'''patientId'''
|'''M [1..1]'''
|E1
|Patienten-ID in der XDS Affinity Domain
|-
| colspan="5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|-
| colspan="2" |'''hash'''
|'''M [1..1]'''
|A
|Hash Wert des Dokuments. Wird vom Repository befüllt
|-
| colspan="2" |'''homeCommunityId'''
|'''M [1..1]'''
|A
|Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.
|-
| colspan="2" |'''repositoryUniqueId'''
|'''M [1..1]'''
|A
|Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
|-
| colspan="2" |'''size'''
|'''M [1..1]'''
|A
|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository befüllt.
 
|-
| colspan="2" |'''URI'''
|'''NP [0..0]'''[[#%20ftn1|<nowiki/>]][[#%20ftn1|<nowiki/>]]
|A
|Wird in XDS-I nicht verwendet
|-
|-
| colspan="5" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|-
| colspan="2" |'''elgaFlag'''
|'''M [1..1]'''
|B
|Kennzeichnet ein Dokument als "ELGA-Dokument"
|-
| colspan="2" |'''elgaHash'''
|'''M [1..1]'''
|B
|Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes
|}
 [[#%20ftn1|<nowiki/>]]

 


==Überblickstabelle der XDS Metadaten für HL7 CDA Objekte==
Die folgende Tabelle gibt einen Überblick über alle XDS-Metadaten-Elemente. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in IHE bzw. ELGA für das Einbringen von Dokumenten, sowie die Quelle aus der die Informationen stammen.

In der Tabelle 6 werden die XDS-Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität), jeweils für Stable Documents (SD) und On-Demand-Documents (ODD) angegeben.

''Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|C||Aus CDA-Inhalt abgeleitet (direkt oder indirekt, gilt nicht für On-Demand-Documents)
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- 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="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 6: Überblick XDS Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''
| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''
| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
| rowspan="2" style="text-align:left" |'''Beschreibung '''
|- style="background:#CBD7F1"
|'''SD'''9||'''ODD'''10
|- style="background:#CBD7F1"
| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''
|- style="background:white"
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''M [1..1]'''||'''M [1..1]'''
|C||Die Person, welche das Dokument verfasst hat
|- style="background:white"
| ||authorInstitution||'''M [1..1]'''||'''M [1..1]'''
|C||ID und Name der Organisation (Kurzbezeichnung), der die Person angehört, wie im GDA-Index angegeben.
|- style="background:white"
| ||authorPerson||'''M [1..1]'''||'''M [1..1]'''
|C||Daten der Person (Name, ID, etc.)
|- style="background:white"
| ||authorRole||'''R [0..1]'''||'''NP [0..0]'''
|C||Rolle der Person
|- style="background:white"
| ||authorSpeciality||'''R [0..1]'''||'''NP [0..0]'''
|C||Fachrichtung der Person
|- style="background:white"
| colspan="2" |'''classCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Vertraulichkeitscode des Dokuments
|- style="background:white"
| colspan="2" |'''creationTime'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R [0..*]'''||'''R [0..*]'''
|C||Liste von Gesundheitsdienstleistungen
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Format des Dokumenteninhalts
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O [0..1]'''||'''NP [0..0]'''
|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.
|- style="background:white"
| colspan="2" |'''languageCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Sprachcode des Dokuments z.B.: "de-AT"
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R [0..1]'''||'''NP [0..0]'''
|C||Rechtlicher Unterzeichner des Dokuments
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Fachliche Zuordnung des Dokuments
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''NP [0..0]'''||'''NP [0..0]'''
|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)
|- style="background:white"
| colspan="2" |'''Title'''||'''M [1..1]'''||'''M [1..1]'''
|C||Titel des Dokuments
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Global eindeutige ID des Dokuments
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''M [1..1]'''||'''O [0..1]'''
|C||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''M [1..1]'''||'''M [1..1]'''
|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 z.B.: "text/xml" für CDA
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O [0..1]'''||'''O [0..1]'''
|E1||Verweis auf ein referenziertes Dokument
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O [0..1]'''||'''O [0..1]'''
|E1||Typ der Relation zu dem referenzierten Dokument. 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
|}

9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht. 
10 ODD: "On-demand Document": Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird. 
11 Der Inhalt des typeCodes soll mit dem contentTypeCode des Submission Sets übereinstimmen. 
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. 
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein. 

=XDS-I Metadaten für DICOM KOS Objekte=
Die folgenden Kapitel spezifizieren die XDS-I Metadaten von DICOM KOS-Objekten für deren Verwendung in ELGA. Nicht weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt<ref name="ITITF3"/>.

Die folgende Tabelle gibt einen Überblick jener XDS-I Metadaten-Elemente, die direkt aus dem DICOM KOS bzw. der zugrundeliegenden DICOM Study abgeleitet werden können. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in ELGA für das Einbringen von DICOM KOS Objekten, sowie die Quelle aus der die Informationen stammen.

''Tabelle 7: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" |'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

'''der Studie'''
|'''Attribut'''

'''im KOS'''
|'''Beschreibung'''
|- style="background:white"
| colspan="2" |author
|M [1..1]
| colspan="3" |
|- style="background:white"
| rowspan="6" |
|author.authorInstitution
|M [1..1]
|(0008,0080)
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl die Kurzbezeichnung als auch die OID der Institution aus dem GDA-Index anzugeben.

Zur Ermittlung des Namens kann das DICOM Tag (0008,0080) herangezogen werden.

'''Achtung:''' Dieses Attribut ist Type 3 (optional) (General Equipment Module).

'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
|- style="background:white"
| colspan="5" |Die Person, welche die Studie durchführt, ist als author anzugeben:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,1052)
|
|Performing Physicians Identification Sequence

Code und weitere Daten aus dem ersten Item in der Sequence

'''Achtung''': Die Identifikationsdaten der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
|- style="background:white"
|
|
|'''Alternativ:'''

(0008,1050)
|
|Performing Physicians Name

Enthält dieses Attribut mehrere Namen, so ist der erste Name zu wählen.

'''Achtung:''' Die Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
|- style="background:white"
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,0060) + (0008,0070) + (0008,1090)
|
|Modality Code + Manufacturer + Manufacturer's Model Name

'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
|- style="background:white"
| colspan="2" |creationTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date + Study Time

Für den Fall, dass Study Date und Study Time nicht zur Verfügung stehen, ist es zulässig, den Erstellungszeitpunkt des KOS ((0008,0023) contentDate + (0008,0033) contentTime) als creationTime zu verwenden.
|- style="background:white"
| colspan="2" |eventCodeList
|M [1..*]
|
|
|Enthält eine Liste von Codes von Gesundheitsdienstleistungen nach APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten<nowiki/>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</ref>
|- style="background:white"
|
|eventCodeList DisplayNameList
|M [1..1]
|
|
|Enthält den Display Name des APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom" />
|- style="background:white"
| colspan="2" |serviceStartTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|- style="background:white"
| colspan="2" |sourcePatientId
|M [1..1]
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|- style="background:white"
| colspan="2" |sourcePatientInfo
|M [1..1]
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|Die ELGA Vorgabe empfiehlt, Name, Geburtstag und Geschlecht NICHT anzugeben.
|- style="background:white"
| colspan="2" |title
|M [1..1]
|(0008,0060) + (0008,1030)
|
|Der relevante Modality Code der Studie oder alle Modality Codes der Studie und die Study Description.

Alternativ darf anstatt der Study Description der DisplayName des APPC verwendet werden.

'''Anmerkung:'''

Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
 
|- style="background:white"
| colspan="2" |uniqueId
|M [1..1]
|
|(0008,0018)
|Die SOP Instance UID des KOS
|- style="background:white"
| colspan="2" |referenceIdList
|M [1..1]
|
|
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|- style="background:white"
| rowspan="2" |
|value mit CXi.5 = "<nowiki>urn:elga:iti:xds:2014: OwnDocument_setId</nowiki>"
|M [1..1]
|(0020,000D) oder ein vergleichbares Attribut
|(0020,000D) oder ein vergleichbares Attribut
|Die setId zur Klammerung aller Versionen eines KOS

Diese kann von jedem Bereich frei gewählt werden, sie ist mit dem Datentyp '''<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>''' anzugeben.

Eine mögliche Wahl der setId ist die Study Instance UID. Die geeignete Wahl der setId hängt auch vom implementierten Stornoworkflow ab, siehe KOS Leitfaden (Kapitel 8.2.2.)<ref name="KOS-Leitfaden" />
|- style="background:white"
|value mit CXi.5 = "<nowiki>urn:ihe:iti:xds:2013: accession</nowiki>"
|R [0..1]
|(0008,0050) oder ein vergleichbares Attribut wie z.B.

(0040,1001) Requested Procedure ID
 
|(0008,0050)
 
|Die ID, die zur Verlinkung mit dem Befund heranzuziehen ist.

Diese ist mit dem Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' anzugeben.

'''Achtung:'''

Welche ID dazu geeignet ist, die Verlinkung mit dem zugehörigen Befund herzustellen, ist vom jeweils implementierten Workflow abhängig.

Gemäß dem Integrationsprofil IHE RAD Scheduled Workflow dient dazu die Accession Number, die im DICOM Attribut (0008,0050) enthalten ist.

Weicht der lokale radiologische Workflow vom IHE Profil ab, kann es erforderlich sein, ein anderes DICOM Attribut für die Verlinkung heranzuziehen.

Unabhängig von der Wahl des DICOM Attributs ist aber in jedem Fall der Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' zu verwenden.
|- style="background:white"
| colspan="2" |comments
|O [0..1]
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

===author===
Die Person oder Maschine, die das Dokument erstellt hat. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.

Die ''authorInstitution'' benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden können. Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.

*''oid'': OID der Organisation aus dem GDA-Index (muss ermittelt werden)
*''name'': (0008,0080), Institution Name, Name der Organisation als String,
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden. 

'''Achtung:''' Das DICOM-Tag (0008,0080), Institution Name, ist vom Type 3 (optional) (General Equipment Module).

'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
{{EndYellowBox}}

=====Spezifikation=====

'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$name … Name der Organisation, die die Studie erstellt hat

$oid ... OID der Organisation aus dem GDA-Index

concat( 
$name,"^^^^^^^^^", 
$oid,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification>
</pre>

Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.

====authorPerson====
Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche die Bilddaten inhaltlich erstellt hat.

Im Fall eines DICOM Objektes gilt eine Verknüpfung mit folgenden (optionalen) DICOM Attributen:

#Die Person kann aus den DICOM Attributen der Studie abgeleitet werden
#*Identifikator: Code aus Attribut "Performing Physicians Identification Sequence", (0008,1052), Datentyp SQ, wenn vorhanden. Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence.
#*Name: Attribut "Performing Physicians Name", (0008,1050), Datentyp PN (entspricht den ersten 5 Feldern von HL7 V2 Datentyp XPN. Maximum 64 Zeichen pro component group, ohne zusätzliche ideographische und phonetische Zeichen). Wenn mehrere Namen vorhanden sind, ist der erste zu übernehmen.
#*Root: OID-Unterknoten für Personen (entsprechend der Organisations-OID aus dem GDA-Index)
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den folgenden DICOM Attributen abgleitet werden
#*Modalität: Attribut "Modality", (0008,0060), erlaubte Werte siehe DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality <ref name="DICOMModality">DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</ref>
#*Hersteller: Attribut "Manufacturer", (0008,0070)
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090)

{{BeginYellowBox}}
'''Achtung:''' Die Identifikationsdaten und Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.

'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
{{EndYellowBox}}

=====Spezifikation für Personen=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

1.Fall: Bei der lokalen ID handelt es sich um KEINE OID:

$id = Code #1 aus (0008,1052) Performing Physicians Identification Sequence

$person = (0008,1050) Performing Physicians Name

$root = OID-Knoten für den Personenidentifikator

concat( 
 $id,"^", 
 $person,"^", 
 $root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>11375^Musterdoc^Josef^Maria^Msc^DIDr^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>

2. Fall: Bei der lokalen ID handelt es sich um eine OID:

concat( 
 $id,"^", 
 $person 
) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf die XCN Komponenten wie in IHE RAD TF-2 Rev.19 2020<ref name="IHERADTF2">IHE Radiology (RAD) Technical Framework Volume 2x Rev.19, 2020 [https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf]</ref>, "Table 4.68.4.1.2.3-3: XCN Data type mapping" vorgegeben.

=====Spezifikation für Software und Geräte=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$Modality = Modality (0008,0060)

$Manufacturer = Manufacturer (0008,0070)

$ManufacturersModelName = Manufacturer's Model Name (0008,1090)

concat(

"^",

$Modality,"^",

$Manufacturer,"^",

$ManufacturersModelName

) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^CT^Geräthersteller^Gerätename</Value>
</ValueList>
</Slot>
</Classification></pre>

Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objekt Erzeugung innehatte.

Dieser Leitfaden beschreibt keine Einschränkungen für die Verwendung.

Beispiel:

*"Radiologie"
*"Modalität"

====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das KOS-Objekt verfasst hat.

Beispiel:

*"Facharzt für Radiologie"
*"Facharzt für Nuklearmedizin"

=====Spezifikation=====

'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

Bsp: Fachärztin/Facharzt für Radiologie 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Fachärztin/Facharzt für Radiologie</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Wenn eine Person als Autor vorhanden ist, '''MUSS''' der Wert einem DisplayName aus dem Value Set "ELGA_AuthorSpeciality" entsprechen.

Im Fall von Geräten oder Software als Autor '''MUSS''' das Element leer bleiben.

{{EndYellowBox}}

===classCode (und classCodeDisplayName)===
Das ''classCode'' Element klassifiziert (grobe Granularität) das registrierte Objekt und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Objektklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Objektklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#typeCode_.28und_typeCodeDisplayName.29|typeCode]]
|}

====Spezifikation====

'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 

Es wird ein fester Wert gesetzt: 55113-5 "Key images Document Radiology" (LOINC: 2.16.840.1.113883.6.1)

$code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
classifiedObject="theDocument" nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===confidentialityCode===
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.

Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf KOS-Objekte ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt, bzw. fix auf "normal" (N) gesetzt.

Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich. Es wird der Vertraulichkeitscode gemäß folgender Spezifikation übernommen:

Zulässige Werte gemäß Value Set "ELGA_Confidentiality" <ref name="ConfVS">Value Set "ELGA_Confidentiality" https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality</ref>.

====Spezifikation====

confidentialityCode wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$code = "N" $displayName = "normal" $codeSystem = "2.16.840.1.113883.5.25"

<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="theDocument" nodeRepresentation="N">
<Name>
<LocalizedString value="normal"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:2.16.840.1.113883.5.25</Value>
</ValueList>
</Slot>
</Classification></pre>

===creationTime===
Das creationTime Element beschreibt den Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes. Es soll die Zeit angegeben werden, die diese Erstellungszeit am besten beschreibt:

#Erstellungsdatum der Studie (aus dem KOS Objekt oder der DICOM Studie):
#*Study Date (0008,0020)
#*Study Time (0008,0030)
#Sollte das zuvor genannte Attribut nicht verfügbar sein, muss alternativ das Erstellungsdatum des KOS Objektes verwendet werden:
#*Content Date (0008,0023)
#*Content Time (0008,0033)

Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From ''UTC''<ref>Timezone Offset From UTC http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</ref> berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

====Spezifikation====

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 

$date = (0008,0020) Study Date oder (0008,0023) Content Date

$time = (0008,0030) Study Time oder (0008,0033) Content Time und (0008,0201) Timezone Offset from UTC

concat(

$date,

$time

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="creationTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.{{EndYellowBox}}

===eventCodeList (und eventCodeListDisplayName)===
Dieses Element enthält eine Liste der erbrachten Gesundheitsdienstleistungen, die das registrierte Dokument oder Objekt beschreibt. Im Fall von Bilddaten findet der APPC Anwendung. (Die korrekte Verwendung von APPC in DICOM Objekten wird im entsprechenden Leitfaden der DICOM Austria spezifiziert: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten"<ref name="KOS-Leitfaden"></ref>).
Es können mehrere APPC bzw. Events (und displayNames) angegeben werden. Sind mehrere Events vorhanden, muss die Reihenfolge der Events und zugehörigen displayNames gleich sein.

====Spezifikation====

'''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 

Für jedes documentationOf Element [1..n]: 

$code = APPC code (alle Achsen) z.B. "2.4.0.5-3-3" 
$displayName = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule" 
$codeSystem = OID des Codesystems APPC: 1.2.40.0.34.5.38 
<pre class="ilfbox_code">
<Classification
classificationScheme=
"urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
classifiedObject="theDocument"
nodeRepresentation="$code">
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
<Name>
<LocalizedString value="$displayName"/>
</Name>
</Classification>
</pre>

===languageCode===
Das ''languageCode'' Element beschreibt den Sprachcode in dem ein Dokument oder Objekt verfasst bzw. beschlagwortet ist. Derzeit wird ein fester Wert vorgeschrieben: '''de-AT'''
====Spezifikation====

'''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

Fester Wert "de-AT"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/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===
Dieses Element darf für XDS-I nicht verwendet werden [NP].

===serviceStartTime / serviceStopTime===
Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts bzw. der Untersuchung. Für KOS-Objekte kann die ''serviceStartTime'' aus dem Objekt gemappt werden:

#Das Erstellungsdatum der Studie (aus dem KOS Objekt oder bevorzugt der DICOM Studie):
#*Study Date (0008,0020)
#*Study Time (0008,0030)
#Alle Zeiten müssen in XDS in UTC konvertiert werden, daher sollte Timezone Offset From UTC berücksichtigt werden, falls angegeben:
#*Timezone Offset From UTC (0008,0201)

Für die serviceStopTime steht kein Mapping zur Verfügung und wird daher nicht angegeben [NP].

====Spezifikation====
'''serviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat(

Study Date,

Study Time + Timezone Offset from UTC

)
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="serviceStartTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden!
{{EndYellowBox}}

===sourcePatientId===
Das ''sourcePatientId'' Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA.

Für ein Mapping aus KOS steht folgendes Attribut zur Verfügung:

(0010,0020) Patient ID (VR:LO, VM:1)

Eine OID zur Definition des Namensraumes des verwendeten Patientenidentifikators muss entsprechend vorhanden sein.
====Spezifikation====

'''sourcePatientId''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$patientID = (0010,0020) Patient ID

$oid = OID des lokalen Patientenidentifikators

concat(

$patientID,

"^^^&amp;",

$oid,

"&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" />.

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.
{{BeginYellowBox}}
In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
{{EndYellowBox}}

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modality Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. ("CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule")
{{BeginYellowBox}}
'''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
{{EndYellowBox}}
====Spezifikation====

'''title''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:

concat(

Modality,

" ",

Study Description

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Name>
<LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" />
</Name>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
{{EndYellowBox}}

===typeCode (und typeCodeDisplayName)===
Das ''typeCode'' Element beschreibt den Objekttyp, dem das KOS Objekt angehört. Der Objekttyp ist die Spezialisierung einer Objektklasse, jeder Objekttyp gehört zu genau einer Objektklasse.

Unterscheidung typeCode/classCode:
{| class="wikitable"
|- style="background:white"
|'''typeCode'''
|'''Objektklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
|classCode
|Objektklasse in grober Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29|classCode]]
|}

====Spezifikation====

'''typeCode (und typeCodeDisplayName)''' wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:

Es wird ein fester Wert gesetzt: '''55113-5''' "Key images Document Radiology"

 $code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="KeyImageObject"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

====submissionSet.contentTypeCode====
Der contentTypeCode des Submission Sets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.

$code = "55113-5"

$displayName = "Key images Document Radiology"

$codeSystem = "2.16.840.1.113883.6.1"<pre class="ilfbox_code">
<RegistryPackage
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
<Classification
classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
classifiedObject="KeyImageObject"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</RegistryPackage>
</pre>Jeder Container darf dementsprechend nur 1 Objekt enthalten.

===uniqueId===
Das ''uniqueId'' Element beschreibt den global eindeutigen Identifier des Objektes. Dieser Identifier wird vom Document Source Actor erzeugt.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

(0008,0018) SOP Instance UID (VR:UI, VM:1)
====Spezifikation====

uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:

$value = (0008,0018) SOP Instance UID

<pre class="ilfbox_code">
<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. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:

#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId, M [1..1])
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number, M [1..1])
#Verlinkung zwischen DICOM KOS-Objekten und einer Aufenthaltszahl (encounterId, O [0..1])

'''Weitere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.'''

Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.

Dieser Datentyp ist in IHE ITI Data Types in folgender Weise spezifiziert:<ref name="ITITF3"/>

{| 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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}
{{BeginYellowBox}}

'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.
{{EndYellowBox}}

====Versionierung bzw. Versionsklammer (ownDocument_setId)====
Um eine eindeutige Identifikation aller registrierten Versionen eines Objektes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Es kann ein beliebiger Identifikator verwendet werden, solange er die Anforderung erfüllt, alle registrierten Versionen eines KOS-Objektes mit derselben ID eindeutig zu kennzeichnen. Als Best Practice für KOS wird die Verwendung von ''StudyInstanceUID'' vorgeschlagen.

=====Spezifikation=====
ownDocument-SetId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

Für KOS Objekte kann die ''StudyInstanceUID'' (0020,000D) als SetId verwendet werden.

$id = (0020,000D) VR=UI Study Instance UID, z.B. 1.2.40.0.34.99.111.1.1

$homeCommunityId = OID des lokalen ELGA-Bereiches. Diese MUSS [1..1], unabhängig vom für $id gewählten Identifier, angeführt sein, z.B. 1.2.40.0.34.99.999

concat

(

$id, "^^^^",

"<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>", "^",

"&amp;",

$homeCommunityId, "&amp;ISO"

)

Wie oben angeführt wird folgender CXi Wert für <Value> erstellt:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.

====Referenz zwischen Dokument und Studie (Accession Number)====
Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (''acquisition, store'') als auch bei der Befundschreibung (''report'') verfügbar ist. Dies trifft auf die Accession Number zu (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).

=====Spezifikation=====
Bei der Registrierung von KOS Objekten MUSS eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden.

Für Befunde der Bildgebenden Diagnostik (diagnostic image report) kann die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Accession Number z.B. 20201111

$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>20201111^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"

====Referenz zwischen Aufenthaltszahl und Studie (encounterId)====
Durch encounterId wird die Verlinkung sämtlicher Bilddaten (DICOM KOS-Objekte), die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-I Metadaten unterstützt. Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird.

=====Spezifikation=====
Bei der Registrierung von KOS Objekten KANN eine encounterId in den XDS-I Metadaten in der ReferenceIdList angegeben werden.

encounterId wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Aufenthaltszahl z.B. Az123456

$root = OID der Liste der Aufenthaltszahlen der Organisation, z.B. 1.2.40.0.34.99.4613.3.4

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>Az123456^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.4613.3.4<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>
</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

====Weitere Einträge der referenceIDList====
Über die bereits genannten Einträge hinaus sind weitere Einträge in der referenceIdList erlaubt:

*'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki>. In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.
*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki>

Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId
</nowiki>^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
<Value>20201111^^^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
<Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value>
<Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===intendedRecipient===
Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der ''intendedRecipient'' notwendig. Derzeit wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.

Der intendedRecipient entfällt bei der Registrierung von KOS Objekten via XDS-I.

===comments===
Das ''comments'' Element enthält Kommentare zum Objekt. Die Verwendung ist in ELGA optional (wird in einigen Implementierungen nicht angezeigt, z.B. ELGA Bürgerportal)

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
(0008,1030) Study Description (VR:LO, VM:1)

====Spezifikation====
Comments wird gemäß folgender Vorschrift zusammengesetzt:
$comment = (0008,1030) Study Description<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Description">
<LocalizedString value = "$comment"/>
</Description>
</ExtrinsicObject>
</pre> 

==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
===availabilityStatus===
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Objektes.

Mögliche Werte laut IHE sind:

*Approved
*Deprecated

Dieses Attribut wird im Zuge des Einbringens von neuen Objekten ("Submission") durch die empfangende XDS Registry immer auf "'''Approved'''" gesetzt.

availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.

<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

===formatCode (und formatCodeDisplayName)===
Das ''formatCode'' Element beschreibt das Format des registrierten Objekts. Es ermöglicht einem empfangenden System (''Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Objektformats und somit die korrekte Darstellung und Verarbeitung.

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

 
$code = "1.2.840.10008.5.1.4.1.1.88.59" 
$displayName = "Key Object Selection Document" 
$codeSystem = "1.2.840.10008.2.6.1"
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA, z.B.

*158 "Fachärztin/Facharzt"
*300 "Allgemeine Krankenanstalt"

Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]".
{{EndYellowBox}}

====Spezifikation====

'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

$code = Klassifizierung des GDA (Code)

$displayName = Klartext des angegebenen Codes

$codeSystem = OID der ausgebenden Stelle

<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===mimeType===
Das ''mimeType'' Element beschreibt den "Internet Media Type" des Objektes gemäß dem "Multipurpose Internet Mail Extensions" (MIME) Standard. Der Standard wird beschrieben in RFC 2045<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref> und RFC 2049<ref name="RFC2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>.

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, welches das DocumentEntry repräsentiert.

Folgende Mime-Types sind für DICOM KOS Objekte zugelassen:

*application/dicom 
<pre class="ilfbox_code">
<ExtrinsicObject
id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
mimeType="application/dicom"
objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>
</pre>

===practiceSettingCode (und practiceSettingCodeDisplayName)===
Das ''practiceSettingCode'' Element beschreibt die fachliche Zuordnung des Objektes. Es soll den Fachbereich wiedergeben, dem der Inhalt des Objektes am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung, z.B.:

*F044 "Radiologie"
*F052 "Unfallchirurgie"

Im KOS-Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_PracticeSetting_VS ELGA_PracticeSetting_VS]".
{{EndYellowBox}}

====Spezifikation====

'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

$code = Code aus Value Set ELGA_PracticeSetting $displayName = Klartext des angegebenen Codes (displayName) $codeSystem = OID des Codesystems (1.2.40.0.34.5.12) 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===objectType===
Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "stabiles Dokument" (stable document, SD) und "On-demand Dokument" (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.

Für KOS Objekte wird der fixe Wert "<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="application/dicom"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

==ELGA-spezifische Erweiterungen der XDS-Metadaten==
Die folgenden Daten entsprechen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information.

===elgaFlag===
Das elgaFlag dient zur Kennzeichnung eines Objektes als "ELGA-Objekt"18. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:

*"true" oder
*"false"

18 Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Objekte auftreten, die NICHT für ELGA vorgesehen sind.

====Spezifikation====

<pre class="ilfbox_code">
<Slot name="urn:elga-bes:elgaFlag">
<ValueList>
<Value>true</Value>
</ValueList>
</Slot>
</pre>

===elgaHash===
Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot "ELGA-Hash" gespeichert.

Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.

====Spezifikation====
<pre class="ilfbox_code">
<rim:Slot name="urn:elga-bes:elgaHash">
<rim:ValueList>
<rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>
</rim:ValueList>
</rim:Slot>
</pre>

=XDS Metadaten für CDA Dokumente=
Die folgenden Kapitel spezifizieren die XDS-Metadaten von HL7 CDA-Dokumenten für deren Verwendung in ELGA. Nicht angegebene Metadaten sind nicht weiter eingeschränkt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol. 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.<ref name="ITITF3"/>

==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).

CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen.

====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurde.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört, grundsätzlich in folgendem Element abgelegt:
##ClinicalDocument/author/assignedAuthor/representedOrganization
#Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:
##'''id'''[1] … ID der Organisation mit den folgenden Attributen:
###@root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)
###@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)
##'''name''' … Name der Organisation als String Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.
#GDA, in deren Gültigkeitsbereich Dokumente erstellt werden können, sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da es vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden.
{{EndYellowBox}}

=====Spezifikation=====

'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$inst … ClinicalDocument/author/assignedAuthor/representedOrganization

*Fall 1: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist nicht vorhanden 

concat( 
$inst/name,"^^^^^^^^^", 
$inst/id[1]/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO</Value>
</ValueList>
</Slot>
</Classification>
</pre>

*Fall 2: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist vorhanden 

concat( 
$inst/name,"^^^^^&", 
$inst/id[1]/@root,"&ISO^^^^" 
$inst/id[1]/@extension 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&amp;ISO^^^^45</Value>
</ValueList>
</Slot>
</Classification>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

====authorPerson====
Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche das Dokument inhaltlich erstellt hat (also nicht die Schreibkraft).

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit CDA Header Elementen:

#Laut Festlegung wird der Autor im Header-Element "author" abgelegt:
##ClinicalDocument/author/assignedAuthor
#Der Autor (Person)
##Ein Personenelement enthält unter anderem die folgenden Unterelemente:
###id … ID der Person mit den folgenden Attributen:
####@root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
####@extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
###assignedPerson
####Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
#####name
#Gerät oder Software als Autor
##Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:
###assignedAuthoringDevice
####Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software
#####manufacturerModelName
####Enthält ein Element mit dem Namen des Geräts oder der Software
#####softwareName

=====Spezifikation für Personen=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

 $person = ClinicalDocument/author/assignedAuthor

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
{{BeginYellowBox}}
Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.
{{EndYellowBox}}
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

=====Spezifikation für Software und Geräte=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

 $person = ClinicalDocument/author/assignedAuthor

concat( 
"^", 
 $person/assignedAuthoringDevice/manufacturerModelName,"^", 
 $person/assignedAuthoringDevice/softwareName 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^Good Health System^Best Health Software Application</Value>
</ValueList>
</Slot>
</Classification></pre>

Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.

Beispiel:

*"Diensthabender Oberarzt"
*"Verantwortlicher diensthabender Arzt für die Dokumenterstellung"

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Laut Festlegung wird die "Rolle" der Person, welche das Dokument inhaltlich erstellt hat, im Element functionCode des Autors abgelegt:
##''ClinicalDocument/author/functionCode''
#Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.

=====Spezifikation=====

'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/functionCode/@displayName 
<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorRole">
<ValueList>
<Value>Diensthabender Oberarzt</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.

Beispiel:

*"Facharzt für Gynäkologie"
*"Facharzt für interne Medizin"

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Laut Festlegung wird die "Fachrichtung" der Person, welche das Dokument inhaltlich erstellt hat, im Element code des Autors abgelegt:
##''ClinicalDocument/author/assignedAuthor/code''
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.

=====Spezifikation=====

'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/assignedAuthor/code/@displayName 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Anästhesiologie und Intensivmedizin</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

===classCode (und classCodeDisplayName)===
Das ''classCode'' Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Dokumentenklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Dokumentenklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2|typeCode]]
|}

====Spezifikation====

'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 

$code = ClinicalDocument/code/translation/@code 
$displayName = ClinicalDocument/code/translation/@displayName 
$codeSystem = ClinicalDocument/code/translation/@codeSystem 
<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: 

<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.
Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird dieser Zeitpunkt wie folgt abgelegt:
##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:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
CreationTime entfällt bei On-Demand Documents.
{{EndYellowBox}}

====Spezifikation====

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 
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: 

Für jedes documentationOf Element 1..n: 

$code = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code 
$displayName = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName 
$codeSystem = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem 
<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: 

 $person = ClinicalDocument/legalAuthenticator/assignedEntity

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<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) Achtung: Diese ID gelangt nicht in die Metadaten!

====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. 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:

 $code = ClinicalDocument/code/@code 
 $displayName = ClinicalDocument/code/@displayName 
 $codeSystem = ClinicalDocument/code/@codeSystem 
<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: 

Fall 1 
Attribut ClinicalDocument/id/@extension ist nicht vorhanden

$value = concat(ClinicalDocument/id/@root)

Fall 2 
Attribut ClinicalDocument/id/@extension ist vorhanden

$value = concat(
ClinicalDocument/id/@root, "^",
ClinicalDocument/id/@extension
)

<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..1])
#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).

{{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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}

{{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 (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).

=====Spezifikation=====
Bei der Registrierung von KOS Objekten MUSS eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden.

Für Befunde der Bildgebenden Diagnostik (diagnostic image report) KANN die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Accession Number z.B. 20201111

$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"<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"
 
====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.

 
=====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>

 

===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: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = ClinicalDocument/hl7at:formatCode/@displayName 
$codeSystem = 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:

$code = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code

$displayName = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName

$codeSystem = 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: 
CDA R2: '''text/xml''' 

<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:

$code = ClinicalDocument/hl7at:practiceSettingCode/@code 
$displayName = ClinicalDocument/hl7at:practiceSettingCode/@displayName 
$codeSystem = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem 
<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"18. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:

*"true" oder
*"false"
18 Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.
====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=

==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.

ILF:XDS Metadaten (Version 3)

2021-03-26T07:08:08Z

Kuttin: /* authorRole */

{{#seo:
|title=XDS Metadaten 3.0.0
|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 (Version 3.0.0)}}



{{#css:
@media screen{
.orange{
border: thin black solid;
background-color:#F4C789;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
padding: 5px 5px 5px 5px;
margin-left:6px;
width:70%;
}
.toc{
width: 20%;
float: right !important;
margin: 10px 0px 10px 30px !important;
border: 1px solid #AAA;
background-color: #F9F9F9;
display: table;
padding: 7px !important;
}
}
}}

{{Infobox Dokument
|Group = ELGA CDA Implementierungsleitfäden
|Title = ELGA XDS Metadaten (XDSDocumentEntry)
|Subtitle = Leitfaden zur Registrierung von CDA Dokumenten mit IHE Cross-Enterprise Document Sharing in ELGA [1.2.40.0.34.7.6.9.3]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0+20210324
|Submitted = ELGA GmbH
|Date = März 2021
|Copyright = 2011-
|Status = Reconciliation
|Period = n.a.
|OID = 1.2.40.0.34.7.6.9.3
|Realm = Austria
}}

{{TOC limit|4}}



{{#css:
.orange{
border: thin black solid;
background-color:#F4C789;
}
.violet{
border: thin black solid;
background-color:#E5D0EE;
}
}}

=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;">
==Impressum==
<div class="mw-collapsible-content">
''Medieneigentümer, Herausgeber, Hersteller, Verleger:'' 
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050 
Internet: [http://www.elga.gv.at www.elga.gv.at]
Email: [mailto:cda@elga.gv.at cda@elga.gv.at] 
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch

''Redaktion, Projektleitung, Koordination: '' 
Mag.Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]

''Abbildungen:'' Sofern nicht anders angegeben: © ELGA GmbH

''Nutzung'': Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria [http://www.hl7.at www.hl7.at]. 
Die Nutzung ist ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.

Download unter [https://www.gesundheit.gv.at www.gesundheit.gv.at] und [https://www.elga.gv.at/cda www.elga.gv.at/cda]
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

==Haftungsausschluss==
<div class="mw-collapsible-content">
Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht und über ein öffentliches Kommentierungsverfahren kontrolliert. Die Nutzung des vorliegenden Leitfadens erfolgt in ausschließlicher Verantwortung der Anwender. Aus der Verwendung des vorliegenden Leitfadens können keinerlei Rechtsansprüche gegen die Autoren, Herausgeber oder Mitwirkenden erhoben und/oder abgeleitet werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls nicht beabsichtigt und von den Erstellern des Dokumentes nicht gewünscht.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

==Sprachliche Gleichbehandlung==
<div class="mw-collapsible-content">
Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer, Frauen und andere Geschlechtsidentitäten in gleicher Weise. Unter dem Begriff "Patient" werden sowohl Bürger, Kunden und Klienten zusammengefasst, welche an einem Behandlungs- oder Pflegeprozess teilnehmen als auch gesunde Bürger, die derzeit nicht an einem solchen teilnehmen. Es wird ebenso darauf hingewiesen, dass umgekehrt der Begriff Bürger auch Patienten, Kunden und Klienten mit einbezieht.
</div></div>

==Lizenzinformationen==
Die Verwendung dieses Leitfadens für die Zwecke der Erstellung, des Verkaufs und des Betriebs von Computerprogrammen, sofern nicht anders angegeben oder sich die Standards auf andere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen, ist ausdrücklich genehmigt. 

Die Lizenzinformationen und Richtlinien zum geistigen Eigentum von IHE International sind beschrieben in Anhang A der IHE International Principles of Governance<ref name="IHE Governance">[https://www.ihe.net/wp-content/uploads/2018/07/IHE-International-Principles-of-Governance.pdf IHE Principles of Governance]</ref> .

===Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")===
<div style="border: thin #77c123 solid;width:100%; margin-left: 10px">
<div style="line-height: 1.25; font-size:16px; border-bottom: 1px solid #81ab1f; box-shadow: 0 4px 0 0 #a2d727;margin-bottom:4px; color:#77c123; width:100%">
Third Party Intellectual Property
</div>
<div style="width:100%;">


Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass der Herausgeber nicht alle Rechte und Ansprüche in und an den Materialien besitzt und dass die Materialien geistiges Eigentum von Dritten enthalten und / oder darauf verweisen können ("Third Party Intellectual Property (IP)"). 

Die Anerkennung dieser Lizenzbestimmungen gewährt dem Lizenznehmer keine Rechte in Bezug auf Third Party IP. Der Lizenznehmer allein ist für die Identifizierung und den Erhalt von notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig verantwortlich. 

Jegliche Handlungen, Ansprüche oder Klagen eines Dritten, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, bleiben die Haftung des Lizenznehmers.

</div>
</div>

==Verbindlichkeit==
Die Verbindlichkeit und die Umsetzungsfrist von Leitfäden sind im Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.

Ein Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf [http://www.gesundheit.gv.at www.gesundheit.gv.at] zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten ("Mandatory" (M), "Required" (R) und "Fixed" (F)), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.

Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit der Rechtsordnung der Republik Österreich und insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz 2000, Gesundheitstelematikgesetz 2012) zu erfolgen. Technische Möglichkeiten können gesetzliche Bestimmungen selbstverständlich nicht verändern, vielmehr sind die technischen Möglichkeiten im Einklang mit den Gesetzen zu nutzen.

Die Einhaltung der gesetzlichen Bestimmungen liegt im Verantwortungsbereich der Ersteller der CDA-Dokumente.

==Verwendete Grundlagen und Bezug zu anderen Standards==
Grundlage dieses Implementierungsleitfadens ist der internationale Standard IHE ITI Cross-enterprise Document Sharing <ref name="IHE ITI"></ref> von Integrating the Healthcare Enterprise (IHE)<ref name="IHE">Integrating the Healthcare Enterprise (IHE) International, Incorporated [http://www.ihe.net http://www.ihe.net]</ref>.

Weiters bezieht sich dieser Leitfaden auf den internationalen Standard "HL7® Clinical Document Architecture, Release 2.0" (CDA ®)<ref name="CDA"></ref>, für die das Copyright © von Health Level Seven International<ref name="HL7">Health Level Seven International [http://www.hl7.org www.hl7.org]</ref> gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert<ref name="ISO CDA">ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical Document Architecture, Release 2 [https://www.iso.org/standard/44429.html https://www.iso.org/standard/44429.html]</ref>. CDA definiert die Struktur und Semantik von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und Patienten. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen.
Die Dokumentmetadaten für CDA Dokumente im Österreichischen Gesundheitswesen werden grundsätzlich vom "Allgemeinen CDA Implementierungsleitfaden"<ref name="ALF">Allgemeiner Implementierungsleitfaden für CDA Dokumente [https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_(Version_3) https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Implementierungsleitfaden_(Version_3)]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden. Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens Version 3]''' und gilt entsprechend für alle CDA-Dokumente, die auf Basis des Leitfadens erstellt werden.
{{EndILFBox}}

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website: [[ILF: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 ([http://www.elga.gv.at/CDA Website der ELGA GmbH]) weitere Dateien und Dokumente zur Unterstützung bereitgestellt:

*ELGA-Gesamtarchitektur<ref name="ELGA-Gesamtarchitektur">ELGA-Gesamtarchitektur 2.30a [http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/ http://www.elga.gv.at/technischer-hintergrund/technischer-aufbau-im-ueberblick/]</ref>
*Beispieldokumente
*Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
*CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
*Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
*Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
*Hinweise für die zu verwendenden Terminologien
*Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [mailto:cda@elga.gv.at cda@elga.gv.at] gesendet werden. Weitere Informationen finden Sie unter [http://www.elga.gv.at/CDA www.elga.gv.at/CDA]. {{EndYellowBox}}

==Bedienungshinweise==
===Farbliche Hervorhebungen===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''<Hinweis>''' authorInstitution wird gemäß folgender Vorschrift zusammengesetzt:
{{EndYellowBox}}
''Themenbezogenes Beispiel-Codefragment (XPath, XML oder RIM-Classification):''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>
''Verweis auf ELGA Value Set:''
{{BeginILFBox}}
'''<Verweis>''' Zulässige Werte gemäß Value Set '''"ELGA_FormatCode".'''
{{EndILFBox}}

<div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">

===PDF-Navigation===
<div class="mw-collapsible-content">
Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

*Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
*Seitenweise blättern: "Bild" Tasten
*Scrollen: Pfeil nach oben bzw. unten
*Zoomen: Strg + Mouserad drehen
*Suchen im Dokument: Strg + F
</div></div>



=Harmonisierung=
'''Erarbeitung des Implementierungsleitfadens''' 
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%" |Person1
|- 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
|}

1 Namen ohne Titel


=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 beim Einbringen von Dokumenten in Form von Befunden<ref name="ALF"></ref> oder Bilddaten in die ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumente (Metadaten der XDSDocumentEntry Objekte): ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 12.0 (22.4.2016) Final Text''<ref name="ITITF3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 12.0 (2016) [https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Rev12.2_Vol3_FT_2016-04-22.pdf], zuletzt besucht am 25.01.2021</ref>

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.

Etwaige, Service-spezifische, Vorgaben auf Schnittstellen-Ebene sind in den entsprechenden Schnittstellenspezifikationen (u.a. Schnittstellen Berechtigungssystem, Schnittstellenspezifikation zur Anbindung des elektronischen Impfpasses) angeführt und im Rahmen konkreter System-Anbindungen zu berücksichtigen.

==Hinweise zur Verwendung des Dokuments==
===Codesysteme und Value Sets===
Die in diesem Dokument erwähnten Codesysteme bzw. Value Sets werden am Terminologieserver (https://www.gesundheit.gv.at/gesundheitssystem/professional/it-services/terminologieserver-doku) und auf der Website der ELGA GmbH (http://www.elga.gv.at) veröffentlicht.

Wenn codierte Werte angegeben werden, ist es immer die Aufgabe des Document Consumers, die korrekten lesbaren Werte anzuzeigen. Es wird nicht empfohlen, die in den XDS-Metadaten verfügbaren DisplayNames direkt zur Anzeige zur verwenden, da Schreibweisen der DisplayNames variieren oder in unterschiedlichen Sprachen angegeben sein können.

===OID ===
In diesem Dokument wird an vielen Stellen die Verwendung von OID vorgeschrieben. OID sind Objekt-Identifikatoren oder Objektkennungen, die als weltweit eindeutige Namen für Informationsobjekte dienen (ISO/IEC 9834-1). Weitere Informationen zur Verwendung und Registrierung von OID sind im "OID-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.

Die Vorgaben für die Erstellung der CDA-Dokumente sind in den "ELGA CDA-Implementierungsleitfäden" ersichtlich. Nur über eine Verordnung definierte Dokumentenklassen dürfen in ELGA verwendet werden, alle Dokumente MÜSSEN entsprechend der Spezifikationen der ELGA CDA-Implementierungsleitfäden erstellt werden.

===Dokumentlebenszyklus und XDS-Transaktionen===
ELGA unterstützt die im folgenden aufgezählten Aktionen (in Klammer die entsprechende ITI-Transaktion). Alle Transaktionen werden in den Protokollierungssystemen aufgezeichnet:

====Bereitstellen [ITI-41] und Veröffentlichen [ITI-42]====
Ein neues Dokument wird entsprechend IHE XDS im Repository gespeichert und durch Registrieren der XDS-Metadaten in der Registry für ELGA bereitgestellt. Neu veröffentlichte Dokument-Metadaten werden immer mit dem Status "approved" versehen.

====Ersetzen eines Dokuments durch eine neue Version ("Updaten") [ITI-41]====
Änderungen eines für ELGA bereitgestellten Dokumentes sind NICHT ERLAUBT.

Es ist allerdings möglich, ein Dokument durch ein anderes zu ersetzen, indem ein neues Dokument (bzw. eine neue Version des Dokumentes) gespeichert und registriert wird. Hierbei MUSS die SetId der referenceIdList in den XDS-Metadaten zum neuen Dokument der der Vorgängerversion entsprechen. Die XDS-Metadaten der Vorgängerversion des Dokumentes bekommen den Status "deprecated". In den XDS-Metadaten und in den CDA-Metadaten der neuen Version werden Verweise auf das ersetzte Dokument eingetragen (Beziehungstyp "replace" (RPLC)).

Beim Ersetzen von ELGA Dokumenten wird das ELGA Berechtigungssystem eventuell zugeordnete individuelle Zugriffsberechtigungen unabhängig von ihrer Anzahl auch auf die Nachfolgeversionen anwenden.

====Stornieren [ITI-57, XDS Metadata Update]====
Dokumente werden "storniert", indem der Dokumentstatus auf "deprecated" gesetzt wird und keine neue Dokumentenversion registriert wird.

===Größenbeschränkung ===
ELGA schreibt für die Größe der eingebrachten CDA eine Maximalgröße von 20 MB vor. Größere Dokumente sind abzulehnen. Es liegt generell in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten |Allgemeiner Implementierungsleitfaden
für ELGA CDA Dokumente, Kapitel 6.10]].

==Allgemeines zu XDS-Metadaten==
Werden Dokumente in ein IHE XDS Repository eingebracht, so müssen alle Dokumente entsprechend klassifiziert und beschrieben werden. Diese beschreibenden "Metadaten" werden in Form einer Nachricht gemeinsam mit dem Dokument an das Repository mitgegeben. Da IHE XDS Systeme grundsätzlich für beliebige Dokumentformate offen sind, gilt dies für alle Arten von Dokumenten (CDA, PDF, Bilder, etc.) gleichermaßen.

Die Metadaten eines Dokuments (XDSDocumentEntry) in einem IHE XDS System beinhalten Informationen
* über das Dokument selbst – um eine Klassifizierung und eine korrekte Darstellung des Dokumenteninhalts zu ermöglichen
* über eventuelle Beziehungen zu anderen Dokumenten (z.B. zu älteren Versionen eines Dokuments)
* über den Speicherort des Dokuments
* über den GDA, welcher das Dokument erstellt hat
* über weitere systemrelevante Informationen (z.B. Dokumentgröße, Mime-Type, etc.).
Die Spezifikation, welche Metadaten in welchem Format und Datentyp angegeben werden müssen, ist im IHE "IT-Infrastructure" (ITI) Technical Framework, Volume 3 festgelegt (IHE ITI TF-3)<ref name="ITITF3"/>.

Die Angabe der Metadaten muss von der Anwendung vorgenommen werden, die das Dokument einbringt.
{{BeginYellowBox}}
Die Metadaten sind die ausschließliche Grundlage für das Suchen und Filtern von Dokumenten in einem XDS Dokumentenregister und somit im ELGA Verweisregister, daher ist die korrekte Verschlagwortung der Dokumente mit den Metadaten eine notwendige Voraussetzung.
{{EndYellowBox}}

'''Hinweis:''' Siehe auch Vorschriften zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3<ref name="ITITF3"/>.

===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument oder binären Objekt entnommen werden und müssen daher von der erstellenden Anwendung mitgegeben werden. Es entsteht dadurch ein zusätzlicher Aufwand insbesondere hinsichtlich der Qualität der Daten. Die Metadaten müssen das beiliegende Dokument oder binäre Objekt korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden.

===Metadaten aus strukturierten Dokumenten (CDA)===
Strukturierte Dokumente bieten die Möglichkeit, die Informationen für die Metadaten beim Einbringen in ein Repository in gewissem Maße aus den Dokumenten selbst automatisiert zu entnehmen. Das vermindert daher die Menge der Informationen, die separat erhoben oder ermittelt werden muss.

Die IHE hat im Rahmen des "Patient Care Coordination" (PCC) Technical Frameworks eine genaue Vorschrift spezifiziert, aus welchen Bereichen des CDA Dokuments die Metadaten entnommen werden sollen.

Die genaue Beschreibung der einzelnen XDS Metadaten Bindings sind im IHE "Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2, Kapitel XDSDocumentEntry Metadata beschrieben.<ref name="IHEPCC">IHE "Patient Care Coordination" (PCC) Technical Frameworks Revision 11.0, Volume 2 [https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_TF_Vol2.pdf]</ref>

===Metadaten aus "On-Demand Documents" (ODD) ===
Ü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"/>.

===Metadaten aus Bilddaten (KOS)===
Bilddaten können über KOS-Objekte (Key Object Selection Document) referenziert und abgerufen werden. Die notwendigen Metadaten können in gewissem Maße aus diesen KOS-Objekten selbst automatisiert entnommen werden. Eine genaue Beschreibung für den Aufbau von KOS-Objekten findet sich im Leitfaden zur Erstellung und Verwendung von KOS Objekten für den ELGA Bilddatenaustausch.

===XDS Metadaten im Vergleich IHE vs. ELGA===
Die vollständige Liste der XDS Metadaten Elemente kann man in folgende Arten von Elementen unterteilen:
# Jene, die vom Dokumentenspeicher automatisch gesetzt werden (XDS Document Repository)
# Jene, die vom Dokumentenregister automatisch gesetzt werden (XDS Document Registry)
# '''Jene, die im Falle von CDA Dokumenten aus dem CDA Inhalt automatisch generiert werden können (XDS Document Source)'''
# Jene, die in jedem Fall explizit gesetzt werden müssen (XDS Document Source)
## '''ELGA relevante'''
## Nicht ELGA relevante
Dieses Dokument behandelt nur XDS Metadaten Elemente der Kategorien 3 und 4.1 (fett markiert).

==Überblickstabelle der XDS-I Metadaten für DICOM KOS Objekte==

Die folgende Tabelle gibt einen Überblick über alle XDS-I Metadaten-Elemente. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in IHE bzw. ELGA für das Einbringen von DICOM KOS Objekten, sowie die Quelle aus der die Informationen stammen.

In der Tabelle 3 werden die XDS-I Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität) angegeben.

 ''Tabelle 1: Legende zur Spalte "Quelle" der folgenden Tabelle''

{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|K||Aus KOS-Inhalt abgeleitet
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- style="background:#white"
|B||Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt
|}

''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" |'''Metadaten Element'''
|'''Optionalität'''
|'''Quelle'''
|'''Beschreibung'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''M [1..1]'''
|<nowiki>-</nowiki>
|Die Person oder das Gerät, welche(s) das Dokument verfasst hat
|-
| rowspan="4" |
|authorInstitution
|'''M [1..1]'''
|E1/K
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|-
|authorPerson
|'''R [0..1]'''
|K
|Daten der Person

(Name, ID, etc.)
|-
|authorRole
|'''R [0..1]'''
|K
|Rolle der Person
|-
|authorSpeciality
|'''R [0..1]'''
|E1/K
|Fachrichtung der Person
|-
| colspan="2" |'''classCode'''
|'''M [1..1]'''
|A
|Dokumenten/Objektklasse (Oberklasse)

z.B.: 55113-5 "Key images Document Radiology"
|-
| colspan="2" |'''confidentialityCode'''
|'''M [1..1]'''
|A
|Vertraulichkeitscode. Fester Wert "N"
|-
| colspan="2" |'''creationTime'''
|'''M [1..1]'''
|K
|Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes
|-
| colspan="2" |'''eventCodeList'''
|'''M [1..*]'''
|A/K
|Liste von Codes von Gesundheitsdienstleistungen
|-
|
|'''eventCodeDisplayName'''
|'''M [1..1]'''
|A/K
|Bezeichnung von Gesundheitsdienstleistungen nach APPC
|-
| colspan="2" |'''intendedRecipient'''
|'''NP [0..0]'''
| -
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
|-
| colspan="2" |'''languageCode'''
|'''M [1..1]'''
|A
|Sprachcode. Fester Wert "de-AT"
|-
| colspan="2" |'''legalAuthenticator'''
|'''NP [0..0]'''
| -
|Rechtlicher Unterzeichner
|-
| colspan="2" |'''serviceStartTime'''
|'''M [1..1]'''
|K
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|-
| colspan="2" |'''serviceStopTime'''
|'''NP [0..0]'''
| -
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
|-
| colspan="2" |'''sourcePatientId'''
|'''M [1..1]'''
|K
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|-
| colspan="2" |'''sourcePatientInfo'''
|'''NP [0..0]'''
| -
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
|-
| colspan="2" |'''title'''
|'''M [1..1]'''
|A/K
|Titel des Dokuments
|-
| colspan="2" |'''typeCode'''
|'''M [1..1]'''
|A
|Objekttyp (Unterklasse)

codierter Wert
|-
| colspan="2" |'''uniqueId'''
|'''M [1..1]'''
|K
|Global eindeutige ID des Objektes

z.B. SOP Instance UID
|-
| colspan="2" |'''referenceIdList'''
|'''M [1..*]'''
|K
|Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|-
| colspan="5" |'''''Explizit zu setzende Metadaten'''''
|-
| colspan="2" |'''availabilityStatus'''
|'''M [1..1]'''
|E1
|Gültigkeit des Objektes
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|E1
|Format des Objektes
|-
| colspan="2" |'''healthcareFacilityTypeCode'''
|'''M [1..1]'''
|E1
|Klassifizierung des GDA
|-
| colspan="2" |'''mimeType'''
|'''M [1..1]'''
|E1
|Mime Type des Dokuments

Fester Wert für KOS: "application/dicom"
|-
| colspan="2" |'''parentDocumentId'''
|'''O [0..1]'''
|E1
|Verweis auf ein referenziertes Objekt
|-
| colspan="2" |'''parentDocumentRelationship'''
|'''O [0..1]'''
|E1
|Typ der Relation zu dem referenzierten Objekt. z.B.: APPND, RPLC, XFRM
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|E1
|Fachliche Zuordnung des Dokuments
|-
| colspan="2" |'''entryUUID'''
|'''M [1..1]'''
|E1
|UUID des Metadaten-Records des Dokuments(XDS DocumentEntry)
|-
| colspan="2" |'''objectType'''
|'''M [1..1]'''
|E1
|Typ des DocumentEntries

Fester Wert "SD"
|-
| colspan="2" |'''comments'''
|'''O [0..1]'''
|K
|Kommentar zum Dokument/Objekt
|-
| colspan="2" |'''patientId'''
|'''M [1..1]'''
|E1
|Patienten-ID in der XDS Affinity Domain
|-
| colspan="5" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|-
| colspan="2" |'''hash'''
|'''M [1..1]'''
|A
|Hash Wert des Dokuments. Wird vom Repository befüllt
|-
| colspan="2" |'''homeCommunityId'''
|'''M [1..1]'''
|A
|Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.
|-
| colspan="2" |'''repositoryUniqueId'''
|'''M [1..1]'''
|A
|Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.
|-
| colspan="2" |'''size'''
|'''M [1..1]'''
|A
|Größe des Dokuments (des KOS-Objekts) in Bytes. Wird vom Repository befüllt.
 
|-
| colspan="2" |'''URI'''
|'''NP [0..0]'''[[#%20ftn1|<nowiki/>]][[#%20ftn1|<nowiki/>]]
|A
|Wird in XDS-I nicht verwendet
|-
|-
| colspan="5" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|-
| colspan="2" |'''elgaFlag'''
|'''M [1..1]'''
|B
|Kennzeichnet ein Dokument als "ELGA-Dokument"
|-
| colspan="2" |'''elgaHash'''
|'''M [1..1]'''
|B
|Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes
|}
 [[#%20ftn1|<nowiki/>]]

 


==Überblickstabelle der XDS Metadaten für HL7 CDA Objekte==
Die folgende Tabelle gibt einen Überblick über alle XDS-Metadaten-Elemente. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in IHE bzw. ELGA für das Einbringen von Dokumenten, sowie die Quelle aus der die Informationen stammen.

In der Tabelle 6 werden die XDS-Metadaten-Elemente mit der minimalen Anzahl des Vorkommens der Elemente (Optionalität), jeweils für Stable Documents (SD) und On-Demand-Documents (ODD) angegeben.

''Tabelle 4: Legende zur Spalte "Quelle" der folgenden Tabelle''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:#CBD7F1"
|C||Aus CDA-Inhalt abgeleitet (direkt oder indirekt, gilt nicht für On-Demand-Documents)
|- style="background:#white"
|E1||Explizit gesetzt (ELGA relevant)
|- style="background:#white"
|E2||Explizit gesetzt (nicht ELGA relevant)
|- style="background:#white"
|A||Von Registry oder Repository automatisch gesetzt
|- 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="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|M||Das '''Element''' MUSS mit einem korrekten "echten" Wert angegeben werden.
"Dummy"-Werte sind NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R] ''("required")''.
|- style="background:white"
|R||Das '''Element''' SOLL in der Instanz vorhanden sein, sofern bekannt. Wenn nicht bekannt, darf es nicht in der Instanz codiert sein und muss weggelassen werden. Entspricht der in älteren Leitfäden gebräuchlichen Notation [R2] ''("required if known")''.
|- style="background:white"
|O||Optional
|- style="background:white"
|NP||Das '''Element i'''st NICHT ERLAUBT. Entspricht der in älteren Leitfäden gebräuchlichen Notation [X] (''"prohibited"'')
|}

''Tabelle 6: Überblick XDS Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" rowspan="2" style="text-align:left" width="20%" |'''Metadaten Element'''
| colspan="2" style="text-align:center" width="10%" |'''Optionalität'''
| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
| rowspan="2" style="text-align:left" |'''Beschreibung '''
|- style="background:#CBD7F1"
|'''SD'''9||'''ODD'''10
|- style="background:#CBD7F1"
| colspan="6" style="text-align:center" |'''''Aus dem CDA-Inhalt ableitbare Metadaten'''''
|- style="background:white"
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)||'''M [1..1]'''||'''M [1..1]'''
|C||Die Person, welche das Dokument verfasst hat
|- style="background:white"
| ||authorInstitution||'''M [1..1]'''||'''M [1..1]'''
|C||ID und Name der Organisation (Kurzbezeichnung), der die Person angehört, wie im GDA-Index angegeben.
|- style="background:white"
| ||authorPerson||'''M [1..1]'''||'''M [1..1]'''
|C||Daten der Person (Name, ID, etc.)
|- style="background:white"
| ||authorRole||'''R [0..1]'''||'''NP [0..0]'''
|C||Rolle der Person
|- style="background:white"
| ||authorSpeciality||'''R [0..1]'''||'''NP [0..0]'''
|C||Fachrichtung der Person
|- style="background:white"
| colspan="2" |'''classCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Vertraulichkeitscode des Dokuments
|- style="background:white"
| colspan="2" |'''creationTime'''||'''M [1..1]'''||'''NP [0..0]'''
|C||Medizinisch relevantes Datum, je nach Definition im speziellen Leitfaden
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R [0..*]'''||'''R [0..*]'''
|C||Liste von Gesundheitsdienstleistungen
|-
| colspan="2" |'''formatCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Format des Dokumenteninhalts
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O [0..1]'''||'''NP [0..0]'''
|C||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.
|- style="background:white"
| colspan="2" |'''languageCode'''||'''M [1..1]'''||'''M [1..1]'''
|C||Sprachcode des Dokuments z.B.: "de-AT"
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R [0..1]'''||'''NP [0..0]'''
|C||Rechtlicher Unterzeichner des Dokuments
|-
| colspan="2" |'''practiceSettingCode'''
|'''M [1..1]'''
|'''M [1..1]'''
|C
|Fachliche Zuordnung des Dokuments
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R [0..1]'''||'''O [0..1]'''
|C||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''NP [0..0]'''||'''NP [0..0]'''
|C||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)
|- style="background:white"
| colspan="2" |'''Title'''||'''M [1..1]'''||'''M [1..1]'''
|C||Titel des Dokuments
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''M [1..1]'''||'''M [1..1]'''
|C||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''M [1..1]'''||'''M [1..1]'''
|C||Global eindeutige ID des Dokuments
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''M [1..1]'''||'''O [0..1]'''
|C||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''M [1..1]'''||'''M [1..1]'''
|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 z.B.: "text/xml" für CDA
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O [0..1]'''||'''O [0..1]'''
|E1||Verweis auf ein referenziertes Dokument
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O [0..1]'''||'''O [0..1]'''
|E1||Typ der Relation zu dem referenzierten Dokument. 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
|}

9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht. 
10 ODD: "On-demand Document": Dokument, das nur als Verweis in der Registry existiert und erst zum Abfragezeitpunkt generiert wird. 
11 Der Inhalt des typeCodes soll mit dem contentTypeCode des Submission Sets übereinstimmen. 
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. 
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein. 

=XDS-I Metadaten für DICOM KOS Objekte=
Die folgenden Kapitel spezifizieren die XDS-I Metadaten von DICOM KOS-Objekten für deren Verwendung in ELGA. Nicht weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt<ref name="ITITF3"/>.

Die folgende Tabelle gibt einen Überblick jener XDS-I Metadaten-Elemente, die direkt aus dem DICOM KOS bzw. der zugrundeliegenden DICOM Study abgeleitet werden können. Die Spalten zeigen jeweils den Namen des Metadaten-Elements, dessen Optionalität in ELGA für das Einbringen von DICOM KOS Objekten, sowie die Quelle aus der die Informationen stammen.

''Tabelle 7: XDS Metadaten aus dem DICOM KOS Objekt abgeleitet''
{| class="wikitable" width="100%"
|- style="background:#CBD7F1"
| colspan="2" |'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

'''der Studie'''
|'''Attribut'''

'''im KOS'''
|'''Beschreibung'''
|- style="background:white"
| colspan="2" |author
|M [1..1]
| colspan="3" |
|- style="background:white"
| rowspan="6" |
|author.authorInstitution
|M [1..1]
|(0008,0080)
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl die Kurzbezeichnung als auch die OID der Institution aus dem GDA-Index anzugeben.

Zur Ermittlung des Namens kann das DICOM Tag (0008,0080) herangezogen werden.

'''Achtung:''' Dieses Attribut ist Type 3 (optional) (General Equipment Module).

'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
|- style="background:white"
| colspan="5" |Die Person, welche die Studie durchführt, ist als author anzugeben:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,1052)
|
|Performing Physicians Identification Sequence

Code und weitere Daten aus dem ersten Item in der Sequence

'''Achtung''': Die Identifikationsdaten der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
|- style="background:white"
|
|
|'''Alternativ:'''

(0008,1050)
|
|Performing Physicians Name

Enthält dieses Attribut mehrere Namen, so ist der erste Name zu wählen.

'''Achtung:''' Die Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.
|- style="background:white"
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|- style="background:white"
|author.authorPerson
|R [0..1]
|(0008,0060) + (0008,0070) + (0008,1090)
|
|Modality Code + Manufacturer + Manufacturer's Model Name

'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
|- style="background:white"
| colspan="2" |creationTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date + Study Time

Für den Fall, dass Study Date und Study Time nicht zur Verfügung stehen, ist es zulässig, den Erstellungszeitpunkt des KOS ((0008,0023) contentDate + (0008,0033) contentTime) als creationTime zu verwenden.
|- style="background:white"
| colspan="2" |eventCodeList
|M [1..*]
|
|
|Enthält eine Liste von Codes von Gesundheitsdienstleistungen nach APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom">Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten<nowiki/>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</ref>
|- style="background:white"
|
|eventCodeList DisplayNameList
|M [1..1]
|
|
|Enthält den Display Name des APPC

siehe "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten" <ref name="LFAPPCDicom" />
|- style="background:white"
| colspan="2" |serviceStartTime
|M [1..1]
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|- style="background:white"
| colspan="2" |sourcePatientId
|M [1..1]
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|- style="background:white"
| colspan="2" |sourcePatientInfo
|M [1..1]
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|(0010,0020)

(0010,0010)

(0010,0030)

(0010,0040)
|Die ELGA Vorgabe empfiehlt, Name, Geburtstag und Geschlecht NICHT anzugeben.
|- style="background:white"
| colspan="2" |title
|M [1..1]
|(0008,0060) + (0008,1030)
|
|Der relevante Modality Code der Studie oder alle Modality Codes der Studie und die Study Description.

Alternativ darf anstatt der Study Description der DisplayName des APPC verwendet werden.

'''Anmerkung:'''

Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
 
|- style="background:white"
| colspan="2" |uniqueId
|M [1..1]
|
|(0008,0018)
|Die SOP Instance UID des KOS
|- style="background:white"
| colspan="2" |referenceIdList
|M [1..1]
|
|
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|- style="background:white"
| rowspan="2" |
|value mit CXi.5 = "<nowiki>urn:elga:iti:xds:2014: OwnDocument_setId</nowiki>"
|M [1..1]
|(0020,000D) oder ein vergleichbares Attribut
|(0020,000D) oder ein vergleichbares Attribut
|Die setId zur Klammerung aller Versionen eines KOS

Diese kann von jedem Bereich frei gewählt werden, sie ist mit dem Datentyp '''<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>''' anzugeben.

Eine mögliche Wahl der setId ist die Study Instance UID. Die geeignete Wahl der setId hängt auch vom implementierten Stornoworkflow ab, siehe KOS Leitfaden (Kapitel 8.2.2.)<ref name="KOS-Leitfaden" />
|- style="background:white"
|value mit CXi.5 = "<nowiki>urn:ihe:iti:xds:2013: accession</nowiki>"
|R [0..1]
|(0008,0050) oder ein vergleichbares Attribut wie z.B.

(0040,1001) Requested Procedure ID
 
|(0008,0050)
 
|Die ID, die zur Verlinkung mit dem Befund heranzuziehen ist.

Diese ist mit dem Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' anzugeben.

'''Achtung:'''

Welche ID dazu geeignet ist, die Verlinkung mit dem zugehörigen Befund herzustellen, ist vom jeweils implementierten Workflow abhängig.

Gemäß dem Integrationsprofil IHE RAD Scheduled Workflow dient dazu die Accession Number, die im DICOM Attribut (0008,0050) enthalten ist.

Weicht der lokale radiologische Workflow vom IHE Profil ab, kann es erforderlich sein, ein anderes DICOM Attribut für die Verlinkung heranzuziehen.

Unabhängig von der Wahl des DICOM Attributs ist aber in jedem Fall der Datentyp '''<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>''' zu verwenden.
|- style="background:white"
| colspan="2" |comments
|O [0..1]
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

===author===
Die Person oder Maschine, die das Dokument erstellt hat. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).
====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich ein Bilddatenobjekt erstellt wurde. Zur Befüllung dieser Information gibt es mehrere Möglichkeiten, beispielsweise über InstitutionName aus dem DICOM Header der Studie: Institution Name, (0008,0080) oder wenn dort nicht verfügbar, muss er aus anderen Quellen ermittelt und eingetragen werden.

Die ''authorInstitution'' benötigt einen Namen und eine OID, die aus dem GDA-Index abgleitet werden können. Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.

*''oid'': OID der Organisation aus dem GDA-Index (muss ermittelt werden)
*''name'': (0008,0080), Institution Name, Name der Organisation als String,
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden. 

'''Achtung:''' Das DICOM-Tag (0008,0080), Institution Name, ist vom Type 3 (optional) (General Equipment Module).

'''Achtung:''' Prinzipiell können sich die Werte in der Studie und im KOS unterscheiden. Auch zur Studie können Geräte in verschiedenen Institutionen beitragen. Bei der Ermittlung der Institution ist Sorge zu tragen, dass die maßgeblich an der Erzeugung der Studie beteiligte Institution als Metadatum verwendet wird.
{{EndYellowBox}}

=====Spezifikation=====

'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$name … Name der Organisation, die die Studie erstellt hat

$oid ... OID der Organisation aus dem GDA-Index

concat( 
$name,"^^^^^^^^^", 
$oid,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification>
</pre>

Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.

====authorPerson====
Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche die Bilddaten inhaltlich erstellt hat.

Im Fall eines DICOM Objektes gilt eine Verknüpfung mit folgenden (optionalen) DICOM Attributen:

#Die Person kann aus den DICOM Attributen der Studie abgeleitet werden
#*Identifikator: Code aus Attribut "Performing Physicians Identification Sequence", (0008,1052), Datentyp SQ, wenn vorhanden. Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence.
#*Name: Attribut "Performing Physicians Name", (0008,1050), Datentyp PN (entspricht den ersten 5 Feldern von HL7 V2 Datentyp XPN. Maximum 64 Zeichen pro component group, ohne zusätzliche ideographische und phonetische Zeichen). Wenn mehrere Namen vorhanden sind, ist der erste zu übernehmen.
#*Root: OID-Unterknoten für Personen (entsprechend der Organisations-OID aus dem GDA-Index)
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den folgenden DICOM Attributen abgleitet werden
#*Modalität: Attribut "Modality", (0008,0060), erlaubte Werte siehe DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality <ref name="DICOMModality">DICOM PS3.3 2021a - Information Object Definitions - C.7.3.1.1.1 Modality http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</ref>
#*Hersteller: Attribut "Manufacturer", (0008,0070)
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090)

{{BeginYellowBox}}
'''Achtung:''' Die Identifikationsdaten und Namen der durchführenden Ärzte können in verschiedenen Serien der Studie unterschiedlich sein. Bei der Ermittlung des Autors ist Sorge zu tragen, dass die Person angegeben wird, die die maßgeblichen Teile der Studie verantwortet.

'''Achtung:''' Zur Studie können mehrere Geräte beitragen. Bei der Ermittlung des Autors ist Sorge zu tragen, dass das maßgeblich an der Erzeugung der Studie beteiligte Gerät als Metadatum verwendet wird.
{{EndYellowBox}}

=====Spezifikation für Personen=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

1.Fall: Bei der lokalen ID handelt es sich um KEINE OID:

$id = Code #1 aus (0008,1052) Performing Physicians Identification Sequence

$person = (0008,1050) Performing Physicians Name

$root = OID-Knoten für den Personenidentifikator

concat( 
 $id,"^", 
 $person,"^", 
 $root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>11375^Musterdoc^Josef^Maria^Msc^DIDr^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>

2. Fall: Bei der lokalen ID handelt es sich um eine OID:

concat( 
 $id,"^", 
 $person 
) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2.999.1.2.3.1375^Welby^Marcus^^MD^Dr</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies folgt dem Mapping von DICOM Datentyp PN (der auch aus mehreren Komponenten besteht) auf die XCN Komponenten wie in IHE RAD TF-2 Rev.19 2020<ref name="IHERADTF2">IHE Radiology (RAD) Technical Framework Volume 2x Rev.19, 2020 [https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf https://ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf]</ref>, "Table 4.68.4.1.2.3-3: XCN Data type mapping" vorgegeben.

=====Spezifikation für Software und Geräte=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$Modality = Modality (0008,0060)

$Manufacturer = Manufacturer (0008,0070)

$ManufacturersModelName = Manufacturer's Model Name (0008,1090)

concat(

"^",

$Modality,"^",

$Manufacturer,"^",

$ManufacturersModelName

) <pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^CT^Geräthersteller^Gerätename</Value>
</ValueList>
</Slot>
</Classification></pre>

Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objekt Erzeugung innehatte.

Dieser Leitfaden beschreibt keine Einschränkungen für die Verwendung.

Beispiel:

*"Radiologie"
*"Modalität"

====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das KOS-Objekt verfasst hat.

Beispiel:

*"Facharzt für Radiologie"
*"Facharzt für Nuklearmedizin"

=====Spezifikation=====

'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

Bsp: Fachärztin/Facharzt für Radiologie 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Fachärztin/Facharzt für Radiologie</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Wenn eine Person als Autor vorhanden ist, '''MUSS''' der Wert einem DisplayName aus dem Value Set "ELGA_AuthorSpeciality" entsprechen.

Im Fall von Geräten oder Software als Autor '''MUSS''' das Element leer bleiben.

{{EndYellowBox}}

===classCode (und classCodeDisplayName)===
Das ''classCode'' Element klassifiziert (grobe Granularität) das registrierte Objekt und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Objektklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Objektklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#typeCode_.28und_typeCodeDisplayName.29|typeCode]]
|}

====Spezifikation====

'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 

Es wird ein fester Wert gesetzt: 55113-5 "Key images Document Radiology" (LOINC: 2.16.840.1.113883.6.1)

$code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a"
classifiedObject="theDocument" nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===confidentialityCode===
Das ''confidentialityCode'' Element beschreibt die Vertraulichkeitsstufe des DICOM KOS Objektes.

Die Konzeption des ELGA Berechtigungssystems sieht vor, den Zugriff auf KOS-Objekte ausschließlich in der ELGA Infrastruktur zu verwalten, dementsprechend wird dieses Element vorerst nicht genutzt, bzw. fix auf "normal" (N) gesetzt.

Die Angabe dieses verpflichtenden XDS Metadaten Elements ist dennoch erforderlich. Es wird der Vertraulichkeitscode gemäß folgender Spezifikation übernommen:

Zulässige Werte gemäß Value Set "ELGA_Confidentiality" <ref name="ConfVS">Value Set "ELGA_Confidentiality" https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality</ref>.

====Spezifikation====

confidentialityCode wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$code = "N" $displayName = "normal" $codeSystem = "2.16.840.1.113883.5.25"

<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f"
classifiedObject="theDocument" nodeRepresentation="N">
<Name>
<LocalizedString value="normal"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:2.16.840.1.113883.5.25</Value>
</ValueList>
</Slot>
</Classification></pre>

===creationTime===
Das creationTime Element beschreibt den Zeitpunkt der Erstellung des registrierten Dokuments oder Objektes. Es soll die Zeit angegeben werden, die diese Erstellungszeit am besten beschreibt:

#Erstellungsdatum der Studie (aus dem KOS Objekt oder der DICOM Studie):
#*Study Date (0008,0020)
#*Study Time (0008,0030)
#Sollte das zuvor genannte Attribut nicht verfügbar sein, muss alternativ das Erstellungsdatum des KOS Objektes verwendet werden:
#*Content Date (0008,0023)
#*Content Time (0008,0033)

Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen müssen. Alle Zeiten in XDS MÜSSEN in UTC konvertiert werden. Dazu kann Timezone Offset From ''UTC''<ref>Timezone Offset From UTC http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</ref> berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

====Spezifikation====

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 

$date = (0008,0020) Study Date oder (0008,0023) Content Date

$time = (0008,0030) Study Time oder (0008,0033) Content Time und (0008,0201) Timezone Offset from UTC

concat(

$date,

$time

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="creationTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden! Dies entspricht einer Transformation auf den HL7 v2 DTM Datentyp gemäß IHE ITI TF-3<ref name="ITITF3" />.{{EndYellowBox}}

===eventCodeList (und eventCodeListDisplayName)===
Dieses Element enthält eine Liste der erbrachten Gesundheitsdienstleistungen, die das registrierte Dokument oder Objekt beschreibt. Im Fall von Bilddaten findet der APPC Anwendung. (Die korrekte Verwendung von APPC in DICOM Objekten wird im entsprechenden Leitfaden der DICOM Austria spezifiziert: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten"<ref name="KOS-Leitfaden"></ref>).
Es können mehrere APPC bzw. Events (und displayNames) angegeben werden. Sind mehrere Events vorhanden, muss die Reihenfolge der Events und zugehörigen displayNames gleich sein.

====Spezifikation====

'''eventCodeList (und eventCodeListDisplayName)''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 

Für jedes documentationOf Element [1..n]: 

$code = APPC code (alle Achsen) z.B. "2.4.0.5-3-3" 
$displayName = APPC displayName z.B. "CT.Unpaarig.Unbestimmte Prozedur.Lendenwirbelsäule" 
$codeSystem = OID des Codesystems APPC: 1.2.40.0.34.5.38 
<pre class="ilfbox_code">
<Classification
classificationScheme=
"urn:uuid:2c6b8cb7-8b2a-4051-b291-b1ae6a575ef4"
classifiedObject="theDocument"
nodeRepresentation="$code">
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
<Name>
<LocalizedString value="$displayName"/>
</Name>
</Classification>
</pre>

===languageCode===
Das ''languageCode'' Element beschreibt den Sprachcode in dem ein Dokument oder Objekt verfasst bzw. beschlagwortet ist. Derzeit wird ein fester Wert vorgeschrieben: '''de-AT'''
====Spezifikation====

'''languageCode''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

Fester Wert "de-AT"
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/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===
Dieses Element darf für XDS-I nicht verwendet werden [NP].

===serviceStartTime / serviceStopTime===
Die ''serviceStartTime/serviceStopTime'' Elemente beschreiben die Zeitpunkte des Beginns und Beendigung des Patientenkontakts bzw. der Untersuchung. Für KOS-Objekte kann die ''serviceStartTime'' aus dem Objekt gemappt werden:

#Das Erstellungsdatum der Studie (aus dem KOS Objekt oder bevorzugt der DICOM Studie):
#*Study Date (0008,0020)
#*Study Time (0008,0030)
#Alle Zeiten müssen in XDS in UTC konvertiert werden, daher sollte Timezone Offset From UTC berücksichtigt werden, falls angegeben:
#*Timezone Offset From UTC (0008,0201)

Für die serviceStopTime steht kein Mapping zur Verfügung und wird daher nicht angegeben [NP].

====Spezifikation====
'''serviceStartTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat(

Study Date,

Study Time + Timezone Offset from UTC

)
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="serviceStartTime">
<ValueList>
<Value>20100511134500</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Das Datum '''MUSS''' immer entweder 8-stellig oder 14-stellig angegeben werden. Bei fehlender Genauigkeit sind fehlende Stellen mit Nullen aufzufüllen (z.B. 2016051814 in 20160518140000).

In den XDS Metadaten können keine Zeitzonen abgebildet werden, daher '''MUSS''' eine Zeitangabe zuvor gemäß der Zeitzone in UTC Zeit konvertiert werden!
{{EndYellowBox}}

===sourcePatientId===
Das ''sourcePatientId'' Element beschreibt die Patienten ID des Patienten im lokalen Informationssystem des GDA.

Für ein Mapping aus KOS steht folgendes Attribut zur Verfügung:

(0010,0020) Patient ID (VR:LO, VM:1)

Eine OID zur Definition des Namensraumes des verwendeten Patientenidentifikators muss entsprechend vorhanden sein.
====Spezifikation====

'''sourcePatientId''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$patientID = (0010,0020) Patient ID

$oid = OID des lokalen Patientenidentifikators

concat(

$patientID,

"^^^&amp;",

$oid,

"&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" />.

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten.
{{BeginYellowBox}}
In ELGA werden die Elemente name, administrativeGender, birthTime und addr NICHT zur Identifikation des Patienten benötigt, die Speicherung dieser Daten erhöht aber den Sicherheits- und Schutzbedarf der Registry unnötig. Eine Speicherung in der Registry ist im Sinne der Datenminimierung (DSGVO) NICHT ERLAUBT.
{{EndYellowBox}}

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modality Codes in der Studie verfügbar sind, soll entweder die relevante Modality verwendet werden oder alle zum Titel hinzugefügt werden.
#Wenn Study Description nicht angegeben ist, muss ein sprechender Titel aus dem DisplayName des APPC generiert werden, z.B. ("CT.Unpaarig.Unbestimmte Proze-dur.Lendenwirbelsäule")
{{BeginYellowBox}}
'''Achtung:''' Für den Fall, dass alle Objekte einer Studie mittels IOCM storniert wurden, enthält diese Studie nur noch die Rejection Note. Der Modality Code ist in diesem Fall "KO".
{{EndYellowBox}}
====Spezifikation====

'''title''' wird als ebRIM "Name/@value"-Attribut im Container "ExtrinsicObject" gemäß folgender Vorschrift zusammengesetzt:

concat(

Modality,

" ",

Study Description

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Name>
<LocalizedString charset="UTF-8" value="DX Digitales Röntgen des Schädels" xml:lang="de-AT" />
</Name>
</ExtrinsicObject>
</pre>
{{BeginYellowBox}}
Die Verwendung von Zeichenketten für Line Feed (lf) oder Carriage Return (cr) ist innerhalb des title generell NICHT ERLAUBT.
{{EndYellowBox}}

===typeCode (und typeCodeDisplayName)===
Das ''typeCode'' Element beschreibt den Objekttyp, dem das KOS Objekt angehört. Der Objekttyp ist die Spezialisierung einer Objektklasse, jeder Objekttyp gehört zu genau einer Objektklasse.

Unterscheidung typeCode/classCode:
{| class="wikitable"
|- style="background:white"
|'''typeCode'''
|'''Objektklasse in feiner Granularität (Spezialisierung).'''
|- style="background:white"
|classCode
|Objektklasse in grober Granularität. Siehe Kapitel [[ILF:XDS Metadaten (Version 3)#classCode_.28und_classCodeDisplayName.29|classCode]]
|}

====Spezifikation====

'''typeCode (und typeCodeDisplayName)''' wird als ebRIM Classification zum DocumentEntry umgesetzt und gemäß folgender Vorschrift zusammengesetzt:

Es wird ein fester Wert gesetzt: '''55113-5''' "Key images Document Radiology"

 $code = "55113-5" $displayName = "Key images Document Radiology" $codeSystem = "2.16.840.1.113883.6.1" 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983"
classifiedObject="KeyImageObject"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

====submissionSet.contentTypeCode====
Der contentTypeCode des Submission Sets wird als ebRIM Classification umgesetzt und soll dieselben Werte wie typeCode des DocumentEntry tragen.

$code = "55113-5"

$displayName = "Key images Document Radiology"

$codeSystem = "2.16.840.1.113883.6.1"<pre class="ilfbox_code">
<RegistryPackage
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
<Classification
classificationScheme="urn:uuid:aa543740-bdda-424e-8c96-df4873be8500"
classifiedObject="KeyImageObject"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</RegistryPackage>
</pre>Jeder Container darf dementsprechend nur 1 Objekt enthalten.

===uniqueId===
Das ''uniqueId'' Element beschreibt den global eindeutigen Identifier des Objektes. Dieser Identifier wird vom Document Source Actor erzeugt.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

(0008,0018) SOP Instance UID (VR:UI, VM:1)
====Spezifikation====

uniqueId wird als ebRIM ExternalIdentifier zum DocumentEntry gemäß folgender Vorschrift zusammengesetzt:

$value = (0008,0018) SOP Instance UID

<pre class="ilfbox_code">
<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. Für Bilddaten sind drei unterschiedliche Einträge in referenceIdList vorgesehen:

#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId, M [1..1])
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number, M [1..1])
#Verlinkung zwischen DICOM KOS-Objekten und einer Aufenthaltszahl (encounterId, O [0..1])

'''Weitere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.'''

Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen.

Dieser Datentyp ist in IHE ITI Data Types in folgender Weise spezifiziert:<ref name="ITITF3"/>

{| 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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}
{{BeginYellowBox}}

'''ACHTUNG: '''Aufgrund der Tatsache, dass es bei den entsprechenden Elementen im CDA Dokument keine Einschränkung bezüglich der Länge gibt wird davon ausgegangen, dass in Abänderung der HL7 Vorgaben hier keine Einzel-Längenprüfungen stattfinden. Aus sicherheitstechnischen Überlegungen ist im Rahmen von ELGA als Grenze für das einzelne CXi Element 255 Zeichen vorgeschrieben.
{{EndYellowBox}}

====Versionierung bzw. Versionsklammer (ownDocument_setId)====
Um eine eindeutige Identifikation aller registrierten Versionen eines Objektes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig. Es kann ein beliebiger Identifikator verwendet werden, solange er die Anforderung erfüllt, alle registrierten Versionen eines KOS-Objektes mit derselben ID eindeutig zu kennzeichnen. Als Best Practice für KOS wird die Verwendung von ''StudyInstanceUID'' vorgeschlagen.

=====Spezifikation=====
ownDocument-SetId wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

Für KOS Objekte kann die ''StudyInstanceUID'' (0020,000D) als SetId verwendet werden.

$id = (0020,000D) VR=UI Study Instance UID, z.B. 1.2.40.0.34.99.111.1.1

$homeCommunityId = OID des lokalen ELGA-Bereiches. Diese MUSS [1..1], unabhängig vom für $id gewählten Identifier, angeführt sein, z.B. 1.2.40.0.34.99.999

concat

(

$id, "^^^^",

"<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>", "^",

"&amp;",

$homeCommunityId, "&amp;ISO"

)

Wie oben angeführt wird folgender CXi Wert für <Value> erstellt:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>
Die homeCommunityId ist die eindeutige OID, unter welcher die ELGA Affinity Domäne registriert ist.

====Referenz zwischen Dokument und Studie (Accession Number)====
Um eine Verknüpfung zwischen den über ein KOS Objekt referenzierten Bilddaten und den zugehörigen Befunden herzustellen, wird ein weiterer Identifier benötigt, der sowohl bei der Aufnahme (''acquisition, store'') als auch bei der Befundschreibung (''report'') verfügbar ist. Dies trifft auf die Accession Number zu (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).

=====Spezifikation=====
Bei der Registrierung von KOS Objekten MUSS eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden.

Für Befunde der Bildgebenden Diagnostik (diagnostic image report) kann die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Accession Number z.B. 20201111

$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>20201111^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>Siehe auch IHE RAD TF3 4.68.4.1.2.4.1 "Linking Report to Set of DICOM Instances"

====Referenz zwischen Aufenthaltszahl und Studie (encounterId)====
Durch encounterId wird die Verlinkung sämtlicher Bilddaten (DICOM KOS-Objekte), die im Rahmen eines Aufenthaltes verfasst wurden, in den XDS-I Metadaten unterstützt. Dies geschieht, indem dieselbe Aufenthaltszahl als encounterId in den XDS-I Metadaten der zu gruppierenden Objekte strukturiert wird.

=====Spezifikation=====
Bei der Registrierung von KOS Objekten KANN eine encounterId in den XDS-I Metadaten in der ReferenceIdList angegeben werden.

encounterId wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Aufenthaltszahl z.B. Az123456

$root = OID der Liste der Aufenthaltszahlen der Organisation, z.B. 1.2.40.0.34.99.4613.3.4

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>"

)<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>Az123456^^^<nowiki>&</nowiki>amp;amp;1.2.40.0.34.99.4613.3.4<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2015:encounterId</nowiki>
</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

====Weitere Einträge der referenceIDList====
Über die bereits genannten Einträge hinaus sind weitere Einträge in der referenceIdList erlaubt:

*'''Study Instance UID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2016:studyInstanceUid</nowiki>. In diesem Fall wird im CXI-Wert auch "Issuing Authority" weggelassen, weil die ID weltweit eindeutig ist.
*'''UniqueID''' mit dem Datentyp: <nowiki>urn:ihe:iti:xds:2013:uniqueId</nowiki>

Folgend ein Beispiel, das alle bereits erwähnten Möglichkeiten der Referenzierungen enthält:<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Slot name="<nowiki>urn:ihe:iti:xds:2013:referenceIdList</nowiki>">
<ValueList>
<Value>1.2.40.0.34.99.111.1.1^^^^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId
</nowiki>^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO</Value>
<Value>20201111^^^amp;1.2.40.0.34.99.999<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:ihe:iti:xds:2013:accession</nowiki></Value>
<Value>Study_UID^^^^urn:ihe:iti:xds:2016:studyInstanceUid</Value>
<Value>UID^^^&1.2.40.0.34.99.111.1.1&ISO^urn:ihe:iti:xds:2013:uniqueId</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===intendedRecipient===
Für die spätere Verwendung von IHE Cross Enterprise Document Workflow (XDW) ist der ''intendedRecipient'' notwendig. Derzeit wird dieses Element in ELGA nicht verwendet. Sobald IHE XDW für ELGA zugelassen wird, folgt die Spezifikation dieses Elementes.

Der intendedRecipient entfällt bei der Registrierung von KOS Objekten via XDS-I.

===comments===
Das ''comments'' Element enthält Kommentare zum Objekt. Die Verwendung ist in ELGA optional (wird in einigen Implementierungen nicht angezeigt, z.B. ELGA Bürgerportal)

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:
(0008,1030) Study Description (VR:LO, VM:1)

====Spezifikation====
Comments wird gemäß folgender Vorschrift zusammengesetzt:
$comment = (0008,1030) Study Description<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>"
status="<nowiki>urn:oasis:names:tc:ebxml-regrep:StatusType:Approved</nowiki>"
id="<nowiki>urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be</nowiki>">
<Description">
<LocalizedString value = "$comment"/>
</Description>
</ExtrinsicObject>
</pre> 

==XDS Metadaten 2: explizit zu setzen (ELGA relevant)==
===availabilityStatus===
Das availabilityStatus-Element beschreibt die Aktualität/Sichtbarkeit des eingebrachten Objektes.

Mögliche Werte laut IHE sind:

*Approved
*Deprecated

Dieses Attribut wird im Zuge des Einbringens von neuen Objekten ("Submission") durch die empfangende XDS Registry immer auf "'''Approved'''" gesetzt.

availabilityStatus wird im Attribut @status des ebRIM ExtrinsicObject abgebildet, das das DocumentEntry repräsentiert.

<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

===formatCode (und formatCodeDisplayName)===
Das ''formatCode'' Element beschreibt das Format des registrierten Objekts. Es ermöglicht einem empfangenden System (''Document Consumer Actor'') die Identifizierung des für die Weiterverarbeitung zu erwartenden Objektformats und somit die korrekte Darstellung und Verarbeitung.

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

 
$code = "1.2.840.10008.5.1.4.1.1.88.59" 
$displayName = "Key Object Selection Document" 
$codeSystem = "1.2.840.10008.2.6.1"
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)===
Das ''healthcareFacilityTypeCode'' Element beschreibt die Klassifizierung des GDA, z.B.

*158 "Fachärztin/Facharzt"
*300 "Allgemeine Krankenanstalt"

Im KOS Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung. (Eine vorgeschlagene Methodik siehe Kapitel zu authorInstitution).
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_HealthcareFacilityTypeCode ELGA_ HealthcareFacilityTypeCode]".
{{EndYellowBox}}

====Spezifikation====

'''healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

$code = Klassifizierung des GDA (Code)

$displayName = Klartext des angegebenen Codes

$codeSystem = OID der ausgebenden Stelle

<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===mimeType===
Das ''mimeType'' Element beschreibt den "Internet Media Type" des Objektes gemäß dem "Multipurpose Internet Mail Extensions" (MIME) Standard. Der Standard wird beschrieben in RFC 2045<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref> und RFC 2049<ref name="RFC2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>.

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, welches das DocumentEntry repräsentiert.

Folgende Mime-Types sind für DICOM KOS Objekte zugelassen:

*application/dicom 
<pre class="ilfbox_code">
<ExtrinsicObject
id="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
mimeType="application/dicom"
objectType="urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"/>
</pre>

===practiceSettingCode (und practiceSettingCodeDisplayName)===
Das ''practiceSettingCode'' Element beschreibt die fachliche Zuordnung des Objektes. Es soll den Fachbereich wiedergeben, dem der Inhalt des Objektes am besten entspricht, unabhängig von der Fachrichtung des Autors oder der erstellenden Abteilung, z.B.:

*F044 "Radiologie"
*F052 "Unfallchirurgie"

Im KOS-Objekt steht kein Element für ein automatisches Mapping in dieses Feld zur Verfügung.
{{BeginYellowBox}}
Zulässige Werte gemäß Value Set "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_PracticeSetting_VS ELGA_PracticeSetting_VS]".
{{EndYellowBox}}

====Spezifikation====

'''practiceSettingCode (und practiceSettingCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt:

$code = Code aus Value Set ELGA_PracticeSetting $displayName = Klartext des angegebenen Codes (displayName) $codeSystem = OID des Codesystems (1.2.40.0.34.5.12) 
<pre class="ilfbox_code">
<Classification
classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:63134a8d-9d4c-4fe0-ad9b-9198b6deeddf"
nodeRepresentation="$code">
<Name>
<LocalizedString value="$displayName"/>
</Name>
<Slot name="codingScheme">
<ValueList>
<Value>urn:oid:$codeSystem</Value>
</ValueList>
</Slot>
</Classification>
</pre>

===objectType===
Das objectType Element gibt den Typ des XDS DocumentEntry wieder. Entsprechend den IHE XDS Vorgaben wird zwischen den Typen "stabiles Dokument" (stable document, SD) und "On-demand Dokument" (on-demand document, ODD) unterschieden. Der objectType ist als ebRIM ExtrinsicObjectist/@objectType Attribut umgesetzt und jeweils durch eine fixe UUID identifiziert.

Für KOS Objekte wird der fixe Wert "<nowiki>urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1</nowiki>" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="application/dicom"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

==ELGA-spezifische Erweiterungen der XDS-Metadaten==
Die folgenden Daten entsprechen nicht dem IHE-Standard und werden vom ELGA-Berechtigungssteuerungssystem automatisch gesetzt. Die Angabe in diesem Leitfaden dient nur zur Information.

===elgaFlag===
Das elgaFlag dient zur Kennzeichnung eines Objektes als "ELGA-Objekt"18. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:

*"true" oder
*"false"

18 Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Objekte auftreten, die NICHT für ELGA vorgesehen sind.

====Spezifikation====

<pre class="ilfbox_code">
<Slot name="urn:elga-bes:elgaFlag">
<ValueList>
<Value>true</Value>
</ValueList>
</Slot>
</pre>

===elgaHash===
Der elgaHash dient als Prüfkennzeichen für die Integrität und Authentizität eines XDS-Metadatensatzes. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ZGF. Dabei wird bei zulässiger Autorisierung von der ZGF ein Hashwert über ausgewählte XDS Metadaten gebildet und im Slot "ELGA-Hash" gespeichert.

Die Reihenfolge sowie der Hash-Algorithmus wird vom Hersteller des ELGA-Berechtigungssystems (BeS) bestimmt und wird nicht publiziert, da ausschließlich das ELGA-Berechtigungssystem zur Erzeugung und Prüfung des Hashwertes befugt ist.

====Spezifikation====
<pre class="ilfbox_code">
<rim:Slot name="urn:elga-bes:elgaHash">
<rim:ValueList>
<rim:Value>3b63bf50f6fe0f44ff7c2ea1a0d0e184</rim:Value>
</rim:ValueList>
</rim:Slot>
</pre>

=XDS Metadaten für CDA Dokumente=
Die folgenden Kapitel spezifizieren die XDS-Metadaten von HL7 CDA-Dokumenten für deren Verwendung in ELGA. Nicht angegebene Metadaten sind nicht weiter eingeschränkt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, Vol. 3 "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.<ref name="ITITF3"/>

==XDS Metadaten 1: aus dem CDA-Inhalt abgeleitet==

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. Dieses Attribut enthält die Subattribute: authorInstitution, authorPerson, authorRole, authorSpecialty (und authorTelecommunication).

CDA-Dokumente erlauben mehrere Author-Elemente. Sollten mehrere Author-Elemente vorhanden sein, ist '''nur das jeweils erste Author-Element''' zu mappen.

====authorInstitution====
Das ''authorInstitution'' Element beschreibt die Organisation (GDA), in dessen Gültigkeitsbereich das Dokument erstellt wurde.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Laut Festlegung in den ELGA Gesundheitsdaten wird die Organisation, der der Autor des Dokuments angehört, grundsätzlich in folgendem Element abgelegt:
##ClinicalDocument/author/assignedAuthor/representedOrganization
#Ein Organisationselement in CDA beinhaltet unter anderem die folgenden Unterelemente:
##'''id'''[1] … ID der Organisation mit den folgenden Attributen:
###@root … Root OID des ID Pools, oder direkte die OID der Organisation (ohne @extension-Attribut)
###@extension … Eigentliche ID des Elements aus dem gegebenen ID Pool (falls die @root nicht direkt die Organisation identifiziert)
##'''name''' … Name der Organisation als String Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element einer möglichst eindeutigen '''Kurzbezeichnung der Organisation''' entsprechen (im GDA-I im Tag ''"descriptor"'' enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird. Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" → "Wien AKH" bzw "Wien AKH - Augenambulanz" Die offizielle Kurzbezeichnung eines GDA kann im GDA-I über die WSDL-Schnittstelle ausgelesen werden, dafür steht ab 2021-ER2 ein eigenes optionales Attribut "Shortname" im Response zur Verfügung.
#GDA, in deren Gültigkeitsbereich Dokumente erstellt werden können, sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da es vom ELGA Berechtigungssystem bei Registrierung geprüft wird. 
Die Herkunft von Dokumenten kann vom Anwender der Suchfunktion nur über das Name-Unterelement beurteilt werden, hier ist eine prägnante '''Kurzbezeichnung''' zu verwenden.
{{EndYellowBox}}

=====Spezifikation=====

'''authorInstitution''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$inst … ClinicalDocument/author/assignedAuthor/representedOrganization

*Fall 1: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist nicht vorhanden 

concat( 
$inst/name,"^^^^^^^^^", 
$inst/id[1]/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^^^^^1.2.3.4.5.6.7.8.9.1789.45&amp;ISO</Value>
</ValueList>
</Slot>
</Classification>
</pre>

*Fall 2: 

Element $inst/id[1] ist vorhanden 
Attribut $inst/id[1]/@root ist vorhanden 
Attribut $inst/id[1]/@extension ist vorhanden 

concat( 
$inst/name,"^^^^^&", 
$inst/id[1]/@root,"&ISO^^^^" 
$inst/id[1]/@extension 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorInstitution">
<ValueList>
<Value>Unfallkrankenhaus Neusiedl^^^^^&1.2.3.4.5.6.7.8.9.1789&amp;ISO^^^^45</Value>
</ValueList>
</Slot>
</Classification>
</pre>
Dies entspricht einer Transformation auf den HL7 v2 XON Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

====authorPerson====
Das Element ''authorPerson'' beschreibt die Identifikation und demographische Informationen der Person oder das Gerät/die Software, welche das Dokument inhaltlich erstellt hat (also nicht die Schreibkraft).

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit CDA Header Elementen:

#Laut Festlegung wird der Autor im Header-Element "author" abgelegt:
##ClinicalDocument/author/assignedAuthor
#Der Autor (Person)
##Ein Personenelement enthält unter anderem die folgenden Unterelemente:
###id … ID der Person mit den folgenden Attributen:
####@root … Root OID des ID Pools, oder direkte die OID der Person (ohne @extension-Attribut)
####@extension … Eigentliche ID aus dem gegebenen ID Pool (falls die @root nicht direkt die Person identifiziert)
###assignedPerson
####Enthält ein HL7 Personen-Element, welches das Namen-Element zur Person enthält
#####name
#Gerät oder Software als Autor
##Alternativ zu einer Person kann auch ein Gerät oder eine Software als Autor aufscheinen, dann sind die folgenden Unterelemente verfügbar:
###assignedAuthoringDevice
####Enthält ein Element mit dem Namen des Herstellers des Geräts oder der Software
#####manufacturerModelName
####Enthält ein Element mit dem Namen des Geräts oder der Software
#####softwareName

=====Spezifikation für Personen=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

 $person = ClinicalDocument/author/assignedAuthor

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>2323^Hummel^Frank^^^^^^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
{{BeginYellowBox}}
Ist clinicalDocument/author/assignedAuthor/id mit einem NullFlavor angegeben, sind die entsprechenden Felder für @extension und @root leer zu lassen.
{{EndYellowBox}}
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

=====Spezifikation für Software und Geräte=====

'''authorPerson''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

 $person = ClinicalDocument/author/assignedAuthor

concat( 
"^", 
 $person/assignedAuthoringDevice/manufacturerModelName,"^", 
 $person/assignedAuthoringDevice/softwareName 
) 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorPerson">
<ValueList>
<Value>^Good Health System^Best Health Software Application</Value>
</ValueList>
</Slot>
</Classification></pre>

Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß IHE ITI TF-3<ref name="ITITF3"/>.

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor des Dokuments zum Zeitpunkt der Dokumentation innehatte.

Beispiel:

*"Diensthabender Oberarzt"
*"Verantwortlicher diensthabender Arzt für die Dokumenterstellung"

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Laut Festlegung wird die "Rolle" der Person, welche das Dokument inhaltlich erstellt hat, im Element functionCode des Autors abgelegt:
##''ClinicalDocument/author/functionCode''
#Die Angabe einer Rolle des Autors ist in ELGA ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Rolle als Text im Attribut @displayName erwartet.

=====Spezifikation=====

'''authorRole''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/functionCode/@displayName 
<pre class="ilfbox_code"><Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorRole">
<ValueList>
<Value>Diensthabender Oberarzt</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

====authorSpeciality====
Das ''authorSpeciality Element'' beschreibt die Fachrichtung der Person, welche das Dokument verfasst hat.

Beispiel:

*"Facharzt für Gynäkologie"
*"Facharzt für interne Medizin"

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Laut Festlegung wird die "Fachrichtung" der Person, welche das Dokument inhaltlich erstellt hat, im Element code des Autors abgelegt:
##''ClinicalDocument/author/assignedAuthor/code''
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe einer Fachrichtung des Autors ein verpflichtendes Element, wenn vorhanden '''''[R]'''''.
#Wenn das Element angegeben ist, wird die Fachrichtung als Text im Attribut @displayName erwartet.

=====Spezifikation=====

'''authorSpeciality''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

ClinicalDocument/author/assignedAuthor/code/@displayName 
<pre class="ilfbox_code">
<Classification classificationScheme="urn:uuid:93606bcf-9494-43ec-9b4e-a7748d1a838d"
classifiedObject="urn:uuid:f0573b34-ea9a-4c6d-8556-5cffbe50f027"
id="urn:uuid:33adae7e-f1ed-4345-acab-73f59bc1d037" nodeRepresentation="">
<Slot name="authorSpeciality">
<ValueList>
<Value>Anästhesiologie und Intensivmedizin</Value>
</ValueList>
</Slot>
</Classification>
</pre>
{{BeginYellowBox}}
Im Fall von Geräten oder Software als Autor sowie in ODD bleibt das Element leer.
{{EndYellowBox}}

===classCode (und classCodeDisplayName)===
Das ''classCode'' Element beschreibt die Dokumentenklasse (grobe Granularität) der das Dokument angehört und ist relevant für das Berechtigungssystem.

Unterscheidung classCode/typeCode:
{| class="wikitable"
|- style="background:white"
|'''''classCode'''''
|'''''Dokumentenklasse in grober Granularität'''''
|- style="background:white"
|''typeCode''
|Dokumentenklasse in feiner Granularität. Siehe Kapitel [[ILF:XDS_Metadaten_(Version_3)#typeCode_.28und_typeCodeDisplayName.29_2|typeCode]]
|}

====Spezifikation====

'''classCode (und classCodeDisplayName)''' wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 

$code = ClinicalDocument/code/translation/@code 
$displayName = ClinicalDocument/code/translation/@displayName 
$codeSystem = ClinicalDocument/code/translation/@codeSystem 
<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: 

<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.
Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird dieser Zeitpunkt wie folgt abgelegt:
##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:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
CreationTime entfällt bei On-Demand Documents.
{{EndYellowBox}}

====Spezifikation====

'''creationTime''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt: 
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: 

Für jedes documentationOf Element 1..n: 

$code = ClinicalDocument/documentationOf[n]/serviceEvent/code/@code 
$displayName = ClinicalDocument/documentationOf[n]/serviceEvent/code/@displayName 
$codeSystem = ClinicalDocument/documentationOf[n]/serviceEvent/code/@codeSystem 
<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: 

 $person = ClinicalDocument/legalAuthenticator/assignedEntity

concat( 
 $person/id/@extension,"^", 
 $person/assignedPerson/name/family,"^", 
 $person/assignedPerson/name/given[1],"^", 
 $person/assignedPerson/name/given[2],"^", 
 $person/assignedPerson/name/suffix,"^", 
 $person/assignedPerson/name/prefix[@qualifier="AC"],"^^^&amp;", 
 $person/id/@root,"&amp;ISO" 
) 
<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) Achtung: Diese ID gelangt nicht in die Metadaten!

====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. 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:

 $code = ClinicalDocument/code/@code 
 $displayName = ClinicalDocument/code/@displayName 
 $codeSystem = ClinicalDocument/code/@codeSystem 
<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: 

Fall 1 
Attribut ClinicalDocument/id/@extension ist nicht vorhanden

$value = concat(ClinicalDocument/id/@root)

Fall 2 
Attribut ClinicalDocument/id/@extension ist vorhanden

$value = concat(
ClinicalDocument/id/@root, "^",
ClinicalDocument/id/@extension
)

<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..1])
#Verlinkung zwischen einer Aufenthaltszahl mit allen im Rahmen dieses Aufenthaltes erfassten medizinischen Informationen. Dies umfasst HL7 CDA oder Dicom KOS-Objekte für Bilddaten (encounterId, O [0..1]).

{{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. 
Therefore, Universal Id Type is always ISO. The required format is: IdNumber^^^&OIDofAA&ISO No other values/modifications in other components or subcomponents are allowed. Specifically, components 2 and 3 shall be empty as listed above. An explicit example is: 543797436^^^&1.2.840.113619.6.197&ISO Note that the '&' character must be properly encoded in the XML content.
|-
|'''CXi'''||HL7 V2 Identifier||This is an identifier of a reference object, distinct from the use of CX for Patient Identifiers. HL7 Identifier type CX consists of several components.

*CXi.1 shall be present and hold the identifier value.
*CXi4 (Assigning Authority) shall be present when the identifier in CXi.1 is not globally unique and holds the identifier of the "domain" over which the ID Number represents a unique entity. It is formatted just like CX.4 in the CX datatype above.
*CXi.5 (Identifier Type Code) shall be present and chosen from either a URN defined by IHE, or a locally defined value.
*When the homeCommunityId is known, CX.6 shall be present and holds the homeCommunityId encoded as ISO, see CX.4 in the CX datatype above.
*No other components shall be present.
|}

{{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 (dasjenige Element, das im Workflow zur Verknüpfung von Studie und Befund verwendet wird).

=====Spezifikation=====
Bei der Registrierung von KOS Objekten MUSS eine Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden.

Für Befunde der Bildgebenden Diagnostik (diagnostic image report) KANN die Accession Number in den XDS-I Metadaten in der ReferenceIdList angegeben werden, wenn eine Verlinkung gewünscht wird.
Der Wert eines Listelementes innerhalb einer referenceIdList hat dem HL7 Datentyp CXi zu folgen (siehe oben).
Accession Number wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = Accession Number z.B. 20201111

$root = OID des lokalen Namensraums der ID, z.B. 1.2.40.0.34.99.111.2.1

concat

(

$id, "^^^", "&amp;"

$root, "&amp;ISO", "^",

"<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"
 
====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.

 
=====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>

 

===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: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = ClinicalDocument/hl7at:formatCode/@displayName 
$codeSystem = 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:

$code = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@code

$displayName = ClinicalDocument/componentOf/encompassingEncounter/location/healthCareFacility/code/@displayName

$codeSystem = 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: 
CDA R2: '''text/xml''' 

<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:

$code = ClinicalDocument/hl7at:practiceSettingCode/@code 
$displayName = ClinicalDocument/hl7at:practiceSettingCode/@displayName 
$codeSystem = ClinicalDocument/hl7at:practiceSettingCode/@codeSystem 
<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"18. Ein XDS Source des ELGA-Bereiches sendet eine "XDS.b Provide and Register Transaktion [ITI-41]", eine "XDS.b Register Document Transaktion [ITI-42]" oder eine "XDS Update Document [ITI-57]" an die ELGA-Zugriffssteuerungsfassade (ZGF). Hierbei wird das Attribut "elgaFlag" entsprechend dem Ergebnis der Berechtigungsprüfung dieser Transaktionen gemäß individueller Zugriffsberechtigungen des Patienten von der ELGA-Zugriffssteuerungsfassade (ZGF) explizit gesetzt. "elgaFlag" kann folgende Werte annehmen:

*"true" oder
*"false"
18 Das ist für Registries notwendig, die sowohl für ELGA als auch für andere eHealth-Anwendungen verwendet werden. Hier können auch Dokumente auftreten, die NICHT für ELGA vorgesehen sind.
====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=

==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.