HL7 Austria MediaWiki - Benutzerbeiträge [de]

Geschlecht

2023-11-17T09:02:56Z

Sjencic:

==Hintergrund==
Der Verfassungsgerichtshof hat 2018 erkannt, dass es Personen möglich sein muss, ein alternatives Geschlecht zu „männlich“ und „weiblich“ zu wählen. Dazu existiert ein Erlass des BMI (Geschäftszahl: BMI-VA1300/0528-III/4/b/2018): Verwaltungsangelegenheiten - Sonstige; Personenstandswesen Erkenntnis des VfGH vom 15. Juni 2018, G 77/2017-9, zu § 2 Abs. 2 Z 3 PStG 2013 - Umsetzung zu Varianten der Geschlechtsentwicklung ("3. Geschlecht"). Durch die Entscheidung des Verfassungsgerichtshofes (VfGH) vom 15. Juni 2018 steht intersexuellen Menschen das Recht auf eine adäquate Bezeichnung im Personenstandsregister des Personenstandsgesetzes (PStG) zu. Weiters werden auch Anpassungen im MeldeG und in den Anlagen im Bereich des Meldewesens erforderlich.

In der Medizininformatik spricht man vom "administrativen Geschlecht", das getrennt von den biologischen Merkmalen der Person zu sehen ist. Das administrative Geschlecht wird in der Verwaltung (z.B. Meldewesen) und entsprechend für die Kommunikation zwischen IT-Systemen genutzt und muss durch ein ärztliches Gutachten bestätigt werden. Die nachfolgenden Value-Sets bilden explizit weder die vollständige biologisch-medizinische Realität noch das soziale Geschlecht ("Gender") ab.

Auf dieser Seite wird gegenübergestellt, wie diese Anforderungen mit unterschiedlichen Standards abgebildet werden können.

==Crossmapping==
{{BeginYellowBox}}
Diese Zuordnungen wurden im Ballot 2023-2 Administratives Geschlecht abgestimmt.
{{EndYellowBox}}
Crossmapping der Geschlechter zwischen den Standards.

{| class="wikitable"
! Gender
! [https://termgit.elga.gv.at/ValueSet/hl7-at-administrativegender-v2 HL7 V2.x]
! [https://termgit.elga.gv.at/ValueSet/elga-administrativegender HL7 V3 + CDA]
! [https://termgit.elga.gv.at/ValueSet/hl7-at-administrativegender-fhir-extension FHIR]
! DICOM
! Erklärung
|-
| Codesystem
| [http://terminology.hl7.org/CodeSystem/v2-0001 v2-administrativeSex]
| [http://terminology.hl7.org/CodeSystem/v3-AdministrativeGender v3-AdministrativeGender]
| [http://hl7.org/fhir/administrative-gender administrative-gender]
| [https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.2.3.html Patient's Sex]
|
|-
| Männlich
| M
| M
| male
| M
|
|-
| Weiblich
| F
| F
| female
| F
|
|-
| Nicht-binär
| X
| UN
| other
| O
|
|-
| "Divers" ''österreichische Erweiterung''
| D
| D
| D
| O
| Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Codesystem hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien. Die nationalen Value-Sets können am österreichischen Terminologiebrowser abgerufen werden: [https://termgit.elga.gv.at/ValueSet/hl7-at-administrativegender-v2 hl7-at-administrativegender-v2], [https://termgit.elga.gv.at/ValueSet/elga-administrativegender elga-administrativegender], [https://termgit.elga.gv.at/ValueSet/hl7-at-administrativegender-fhir-extension hl7-at-administrativegender-fhir-extension]
|-
| „Inter" ''österreichische Erweiterung''
| I
| I
| I
| O
| Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Codesystem hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien. Die nationalen Value-Sets können am österreichischen Terminologiebrowser abgerufen werden: [https://termgit.elga.gv.at/ValueSet/hl7-at-administrativegender-v2 hl7-at-administrativegender-v2], [https://termgit.elga.gv.at/ValueSet/elga-administrativegender elga-administrativegender], [https://termgit.elga.gv.at/ValueSet/hl7-at-administrativegender-fhir-extension hl7-at-administrativegender-fhir-extension]
|-
| „Offen" ''österreichische Erweiterung''
| O
| O
| O
| O
| Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Codesystem hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien. Die nationalen Value-Sets können am österreichischen Terminologiebrowser abgerufen werden: [https://termgit.elga.gv.at/ValueSet/hl7-at-administrativegender-v2 hl7-at-administrativegender-v2], [https://termgit.elga.gv.at/ValueSet/elga-administrativegender elga-administrativegender], [https://termgit.elga.gv.at/ValueSet/hl7-at-administrativegender-fhir-extension hl7-at-administrativegender-fhir-extension]
|-
| Unbekannt
| U
| nullFlavor="UNK"
| unknown
| leeres Feld
| Die Angabe "Unbekannt", welche die Ausprägung "Keine Angabe" einschließt, wird bei v3 mittels nullFlavor="UNK" abgebildet.
|}

=HL7 Gender Harmony Project=
https://confluence.hl7.org/display/VOC/The+Gender+Harmony+Project
https://confluence.hl7.org/display/VOC/Gender+Harmony+Terminology
https://confluence.hl7.org/display/VOC/Gender+Identity

Geschlecht

2023-11-17T08:22:07Z

Sjencic:

==Hintergrund==
Der Verfassungsgerichtshof hat 2018 erkannt, dass es Personen möglich sein muss, ein alternatives Geschlecht zu „männlich“ und „weiblich“ zu wählen. Dazu existiert ein Erlass des BMI (Geschäftszahl: BMI-VA1300/0528-III/4/b/2018): Verwaltungsangelegenheiten - Sonstige; Personenstandswesen Erkenntnis des VfGH vom 15. Juni 2018, G 77/2017-9, zu § 2 Abs. 2 Z 3 PStG 2013 - Umsetzung zu Varianten der Geschlechtsentwicklung ("3. Geschlecht"). Durch die Entscheidung des Verfassungsgerichtshofes (VfGH) vom 15. Juni 2018 steht intersexuellen Menschen das Recht auf eine adäquate Bezeichnung im Personenstandsregister des Personenstandsgesetzes (PStG) zu. Weiters werden auch Anpassungen im MeldeG und in den Anlagen im Bereich des Meldewesens erforderlich.

In der Medizininformatik spricht man vom "administrativen Geschlecht", das getrennt von den biologischen Merkmalen der Person zu sehen ist. Das administrative Geschlecht wird in der Verwaltung (z.B. Meldewesen) und entsprechend für die Kommunikation zwischen IT-Systemen genutzt und muss durch ein ärztliches Gutachten bestätigt werden. Die nachfolgenden Value-Sets bilden explizit weder die vollständige biologisch-medizinische Realität noch das soziale Geschlecht ("Gender") ab.

Auf dieser Seite wird gegenübergestellt, wie diese Anforderungen mit unterschiedlichen Standards abgebildet werden können.

==Crossmapping==
{{BeginYellowBox}}
Diese Zuordnungen wurden im Ballot 2023-2 Administratives Geschlecht abgestimmt.
{{EndYellowBox}}
Crossmapping der Geschlechter zwischen den Standards.

{| class="wikitable"
! Gender
! [https://termgit.elga.gv.at/ValueSet/hl7-at-administrativegender-v2 HL7 V2.x]
! [https://termgit.elga.gv.at/ValueSet/elga-administrativegender HL7 V3 + CDA]
! [https://termgit.elga.gv.at/ValueSet/hl7-at-administrativegender-fhir-extension FHIR]
! DICOM
! Erklärung
|-
| Codesystem
| [http://terminology.hl7.org/CodeSystem/v2-0001 v2-administrativeSex]
| [http://terminology.hl7.org/CodeSystem/v3-AdministrativeGender v3-AdministrativeGender]
| [http://hl7.org/fhir/administrative-gender administrative-gender]
| [https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.2.3.html Patient's Sex]
|
|-
| Männlich
| M
| M
| male
| M
|
|-
| Weiblich
| F
| F
| female
| F
|
|-
| Nicht-binär
| X
| UN
| other
| O
|
|-
| "Divers" ''österreichische Erweiterung''
| D
| D
| D
| O
|Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Value-Set hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| „Inter" ''österreichische Erweiterung''
| I
| I
| I
| O
| Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Value-Set hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| „Offen" ''österreichische Erweiterung''
| O
| O
| O
| O
| Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Value-Set hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| Unbekannt
| U
| nullFlavor="UNK"
| unknown
| leeres Feld
| Die Angabe "Unbekannt", welche die Ausprägung "Keine Angabe" einschließt, wird bei v3 mittels nullFlavor="UNK" abgebildet.
|}

=HL7 Gender Harmony Project=
https://confluence.hl7.org/display/VOC/The+Gender+Harmony+Project
https://confluence.hl7.org/display/VOC/Gender+Harmony+Terminology
https://confluence.hl7.org/display/VOC/Gender+Identity

Geschlecht

2023-11-17T08:15:09Z

Sjencic:

==Hintergrund==
Der Verfassungsgerichtshof hat 2018 erkannt, dass es Personen möglich sein muss, ein alternatives Geschlecht zu „männlich“ und „weiblich“ zu wählen. Dazu existiert ein Erlass des BMI (Geschäftszahl: BMI-VA1300/0528-III/4/b/2018): Verwaltungsangelegenheiten - Sonstige; Personenstandswesen Erkenntnis des VfGH vom 15. Juni 2018, G 77/2017-9, zu § 2 Abs. 2 Z 3 PStG 2013 - Umsetzung zu Varianten der Geschlechtsentwicklung ("3. Geschlecht"). Durch die Entscheidung des Verfassungsgerichtshofes (VfGH) vom 15. Juni 2018 steht intersexuellen Menschen das Recht auf eine adäquate Bezeichnung im Personenstandsregister des Personenstandsgesetzes (PStG) zu. Weiters werden auch Anpassungen im MeldeG und in den Anlagen im Bereich des Meldewesens erforderlich.

In der Medizininformatik spricht man vom "administrativen Geschlecht", das getrennt von den biologischen Merkmalen der Person zu sehen ist. Das administrative Geschlecht wird in der Verwaltung (z.B. Meldewesen) und entsprechend für die Kommunikation zwischen IT-Systemen genutzt und muss durch ein ärztliches Gutachten bestätigt werden. Die nachfolgenden Value-Sets bilden explizit weder die vollständige biologisch-medizinische Realität noch das soziale Geschlecht ("Gender") ab.

Auf dieser Seite wird gegenübergestellt, wie diese Anforderungen mit unterschiedlichen Standards abgebildet werden können.

==Crossmapping==
{{BeginYellowBox}}
Diese Zuordnungen wurden im Ballot 2023-2 Administratives Geschlecht abgestimmt.
{{EndYellowBox}}
Crossmapping der Geschlechter zwischen den Standards.

{| class="wikitable"
! Gender
! HL7 V2.x
! HL7 V3 + CDA
! FHIR
! DICOM
! Erklärung
|-
| Codesystem
| [http://terminology.hl7.org/CodeSystem/v2-0001 v2-administrativeSex]
| [http://terminology.hl7.org/CodeSystem/v3-AdministrativeGender v3-AdministrativeGender]
| [http://hl7.org/fhir/administrative-gender administrative-gender]
| [https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.2.3.html Patient's Sex]
|
|-
| Männlich
| M
| M
| male
| M
|
|-
| Weiblich
| F
| F
| female
| F
|
|-
| Nicht-binär
| X
| UN
| other
| O
|
|-
| "Divers" ''österreichische Erweiterung''
| D
| D
| D
| O
|Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Value-Set hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| „Inter" ''österreichische Erweiterung''
| I
| I
| I
| O
| Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Value-Set hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| „Offen" ''österreichische Erweiterung''
| O
| O
| O
| O
| Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Value-Set hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| Unbekannt
| U
| nullFlavor="UNK"
| unknown
| leeres Feld
| Die Angabe "Unbekannt", welche die Ausprägung "Keine Angabe" einschließt, wird bei v3 mittels nullFlavor="UNK" abgebildet.
|}

=HL7 Gender Harmony Project=
https://confluence.hl7.org/display/VOC/The+Gender+Harmony+Project
https://confluence.hl7.org/display/VOC/Gender+Harmony+Terminology
https://confluence.hl7.org/display/VOC/Gender+Identity

Geschlecht

2023-11-17T08:14:36Z

Sjencic:

==Hintergrund==
Der Verfassungsgerichtshof hat 2018 erkannt, dass es Personen möglich sein muss, ein alternatives Geschlecht zu „männlich“ und „weiblich“ zu wählen. Dazu existiert ein Erlass des BMI (Geschäftszahl: BMI-VA1300/0528-III/4/b/2018): Verwaltungsangelegenheiten - Sonstige; Personenstandswesen Erkenntnis des VfGH vom 15. Juni 2018, G 77/2017-9, zu § 2 Abs. 2 Z 3 PStG 2013 - Umsetzung zu Varianten der Geschlechtsentwicklung ("3. Geschlecht"). Durch die Entscheidung des Verfassungsgerichtshofes (VfGH) vom 15. Juni 2018 steht intersexuellen Menschen das Recht auf eine adäquate Bezeichnung im Personenstandsregister des Personenstandsgesetzes (PStG) zu. Weiters werden auch Anpassungen im MeldeG und in den Anlagen im Bereich des Meldewesens erforderlich.

In der Medizininformatik spricht man vom "administrativen Geschlecht", das getrennt von den biologischen Merkmalen der Person zu sehen ist. Das administrative Geschlecht wird in der Verwaltung (z.B. Meldewesen) und entsprechend für die Kommunikation zwischen IT-Systemen genutzt und muss durch ein ärztliches Gutachten bestätigt werden. Die nachfolgenden Value-Sets bilden explizit weder die vollständige biologisch-medizinische Realität noch das soziale Geschlecht ("Gender") ab.

Auf dieser Seite wird gegenübergestellt, wie diese Anforderungen mit unterschiedlichen Standards abgebildet werden können.

==Crossmapping==
{{BeginYellowBox}}
Diese Zuordnungen wurden im Ballot 2023-2 Administratives Geschlecht abgestimmt.
{{EndYellowBox}}
Crossmapping der Geschlechter zwischen den Standards.

{| class="wikitable"
! Gender
! [https://termgit.elga.gv.at/ValueSet/hl7-at-administrativegender-v2 HL7 V2.x]
! [https://termgit.elga.gv.at/ValueSet/elga-administrativegender HL7 V3 + CDA]
! [https://termgit.elga.gv.at/ValueSet/hl7-at-administrativegender-fhir-extension FHIR]
! DICOM
! Erklärung
|-
| Codesystem
| [http://terminology.hl7.org/CodeSystem/v2-0001 v2-administrativeSex]
| [http://terminology.hl7.org/CodeSystem/v3-AdministrativeGender v3-AdministrativeGender]
| [http://hl7.org/fhir/administrative-gender administrative-gender]
| [https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.2.3.html Patient's Sex]
|
|-
| Männlich
| M
| M
| male
| M
|
|-
| Weiblich
| F
| F
| female
| F
|
|-
| Nicht-binär
| X
| UN
| other
| O
|
|-
| "Divers" ''österreichische Erweiterung''
| D
| D
| D
| O
|Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Value-Set hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| „Inter" ''österreichische Erweiterung''
| I
| I
| I
| O
| Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Value-Set hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| „Offen" ''österreichische Erweiterung''
| O
| O
| O
| O
| Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Value-Set hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| Unbekannt
| U
| nullFlavor="UNK"
| unknown
| leeres Feld
| Die Angabe "Unbekannt", welche die Ausprägung "Keine Angabe" einschließt, wird bei v3 mittels nullFlavor="UNK" abgebildet.
|}

=HL7 Gender Harmony Project=
https://confluence.hl7.org/display/VOC/The+Gender+Harmony+Project
https://confluence.hl7.org/display/VOC/Gender+Harmony+Terminology
https://confluence.hl7.org/display/VOC/Gender+Identity

Geschlecht

2023-11-15T06:54:08Z

Sjencic:

==Hintergrund==
Der Verfassungsgerichtshof hat 2018 erkannt, dass es Personen möglich sein muss, ein alternatives Geschlecht zu „männlich“ und „weiblich“ zu wählen. Dazu existiert ein Erlass des BMI (Geschäftszahl: BMI-VA1300/0528-III/4/b/2018): Verwaltungsangelegenheiten - Sonstige; Personenstandswesen Erkenntnis des VfGH vom 15. Juni 2018, G 77/2017-9, zu § 2 Abs. 2 Z 3 PStG 2013 - Umsetzung zu Varianten der Geschlechtsentwicklung ("3. Geschlecht"). Durch die Entscheidung des Verfassungsgerichtshofes (VfGH) vom 15. Juni 2018 steht intersexuellen Menschen das Recht auf eine adäquate Bezeichnung im Personenstandsregister des Personenstandsgesetzes (PStG) zu. Weiters werden auch Anpassungen im MeldeG und in den Anlagen im Bereich des Meldewesens erforderlich.

In der Medizininformatik spricht man vom "administrativen Geschlecht", das getrennt von den biologischen Merkmalen der Person zu sehen ist. Das administrative Geschlecht wird in der Verwaltung (z.B. Meldewesen) und entsprechend für die Kommunikation zwischen IT-Systemen genutzt und muss durch ein ärztliches Gutachten bestätigt werden. Die nachfolgenden Value-Sets bilden explizit weder die vollständige biologisch-medizinische Realität noch das soziale Geschlecht ("Gender") ab.

Auf dieser Seite wird gegenübergestellt, wie diese Anforderungen mit unterschiedlichen Standards abgebildet werden können.

==Crossmapping==
{{BeginYellowBox}}
Diese Zuordnungen wurden im Ballot 2023-2 Administratives Geschlecht abgestimmt.
{{EndYellowBox}}
Crossmapping der Geschlechter zwischen den Standards.

{| class="wikitable"
! Gender
! HL7 V2.x
! HL7 V3 + CDA
! FHIR
! DICOM
! Erklärung
|-
| Codesystem
| [http://terminology.hl7.org/CodeSystem/v2-0001 v2-administrativeSex]
| [http://terminology.hl7.org/CodeSystem/v3-AdministrativeGender v3-AdministrativeGender]
| [http://hl7.org/fhir/administrative-gender administrative-gender]
| [https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.2.3.html Patient's Sex]
|
|-
| Männlich
| M
| M
| male
| M
|
|-
| Weiblich
| F
| F
| female
| F
|
|-
| Nicht-binär
| X
| UN
| other
| O
|
|-
| "Divers" ''österreichische Erweiterung''
| D
| D
| D
| O
|Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Value-Set hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| „Inter" ''österreichische Erweiterung''
| I
| I
| I
| O
| Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Value-Set hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| „Offen" ''österreichische Erweiterung''
| O
| O
| O
| O
| Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man das nationale Value-Set hl7-at-administrativegender-ergaenzung, welches die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| Unbekannt
| U
| nullFlavor="UNK"
| unknown
| leeres Feld
| Die Angabe "Unbekannt", welche die Ausprägung "Keine Angabe" einschließt, wird bei v3 mittels nullFlavor="UNK" abgebildet.
|}

=HL7 Gender Harmony Project=
https://confluence.hl7.org/display/VOC/The+Gender+Harmony+Project
https://confluence.hl7.org/display/VOC/Gender+Harmony+Terminology
https://confluence.hl7.org/display/VOC/Gender+Identity

Geschlecht

2023-11-15T06:52:35Z

Sjencic:

Geschlecht

2023-11-15T06:51:28Z

Sjencic:

Geschlecht

2023-11-15T06:39:55Z

Sjencic:

Geschlecht

2023-11-14T12:32:16Z

Sjencic:

Geschlecht

2023-11-13T15:59:56Z

Sjencic:

{{BeginYellowBox}}''Hinweis:'' Diese Seite wurde nach dem Ballot 2023-2 Administratives Geschlecht aktualisiert!{{EndYellowBox}}

==Hintergrund==
Der Verfassungsgerichtshof hat 2018 erkannt, dass es Personen möglich sein muss, ein alternatives Geschlecht zu „männlich“ und „weiblich“ zu wählen. Dazu existiert ein Erlass des BMI (Geschäftszahl: BMI-VA1300/0528-III/4/b/2018): Verwaltungsangelegenheiten - Sonstige; Personenstandswesen Erkenntnis des VfGH vom 15. Juni 2018, G 77/2017-9, zu § 2 Abs. 2 Z 3 PStG 2013 - Umsetzung zu Varianten der Geschlechtsentwicklung ("3. Geschlecht"). Durch die Entscheidung des Verfassungsgerichtshofes (VfGH) vom 15. Juni 2018 steht intersexuellen Menschen das Recht auf eine adäquate Bezeichnung im Personenstandsregister des Personenstandsgesetzes (PStG) zu. Weiters werden auch Anpassungen im MeldeG und in den Anlagen im Bereich des Meldewesens erforderlich.

In der Medizininformatik spricht man vom "administrativen Geschlecht", das getrennt von den biologischen Merkmalen der Person zu sehen ist. Das administrative Geschlecht wird in der Verwaltung (z.B. Meldewesen) und entsprechend für die Kommunikation zwischen IT-Systemen genutzt und muss durch ein ärztliches Gutachten bestätigt werden. Die nachfolgenden Value-Sets bilden explizit weder die vollständige biologisch-medizinische Realität noch das soziale Geschlecht ("Gender") ab.

Auf dieser Seite wird gegenübergestellt, wie diese Anforderungen mit unterschiedlichen Standards abgebildet werden können.

==Crossmapping==
{{BeginYellowBox}}
Diese Zuordnungen wurden im Ballot 2023-2 Administratives Geschlecht abgestimmt.
{{EndYellowBox}}
Crossmapping der Geschlechter zwischen den Standards.

{| class="wikitable"
! Gender
! HL7 V2.x
! HL7 V3 + CDA
! FHIR
! DICOM
! Erklärung
|-
| Codesystem
| [[HL7_Administrative_Sex| http://terminology.hl7.org/CodeSystem/v2-0001 ]]
| [[HL7_Administrative_Gender|http://terminology.hl7.org/CodeSystem/v3-AdministrativeGender]]
| [[FHIR_Administrative_Gender|http://hl7.org/fhir/administrative-gender]]
| [[DICOM_PatientsSex|https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.2.3.html]]
|
|-
| Männlich
| M
| M
| male
| M
| Männliche Geschlechtsidentität
|-
| Weiblich
| F
| F
| female
| F
| Weibliche Geschlechtsidentität
|-
| Nicht-binär
| X
| UN
| other
| O
| Menschen, die der herkömmlichen Zuordnung nach dem Geschlecht zu Mann oder Frau nicht entsprechen; mit einer Variante der Geschlechtsentwicklung (VdG), synonym zu „Intergeschlechtlichkeit“, „Intersexualität“ oder „Intersex“ und als Überbegriff für eine Vielzahl verschiedener Körperkompositionen.
|-
| "Divers" ''österreichische Erweiterung''
| D
| D
| D
| O
|Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man ein nationales Value-Set, welche die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| „Inter" ''österreichische Erweiterung''
| I
| I
| I
| O
| Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man ein nationales Value-Set, welche die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| „Offen" ''österreichische Erweiterung''
| O
| O
| O
| O
|Um die österreich-spezifischen Codes dokumentieren zu können, benötigt man ein nationales Value-Set, welche die Ausprägungen abbildet. Die Codes für Divers, Inter und Offen findet man daher nicht in den internationalen Terminologien.
|-
| "Unbekannt"
| U
| nullFlavor="UNK"
| unknown
| leeres Feld
| Die Angabe "Unbekannt", welche die Ausprägung "Keine Angabe" einschließt, wird bei v3 mittels nullFlavor="UNK" abgebildet.
|}

==Geschlecht in unterschiedlichen Systemen (Diskussion) ==
Das ZPV und der ZPI führen die Werte M, W und U.
Wenn eine Person in ZPV erfasst wird (von dort bekommt der ZPI den Großteil der Daten) und es ist kein Geschlecht angegeben und anhand des Namens ist es auch nicht eindeutig dann geben die Sachbearbeiter "UN" ein. Wo hingegen
bei VDAS bei nicht geklärten Geschlecht immer W angenommen wird damit die Person nicht schlechter gestellt wird. Der Leistungsumfang der SV ist nämlich bei W größer als bei M.

Das SZR, das im Zuge von eIDAS angebunden ist, führt offiziell nur die beiden Geschlechter Male und Female, das Geschlecht kann auch leer gelassen werden.
Somit gibt sich hier das Mapping mit ZPI: Male wird zu M, Female wird zu F und ein leeres Geschlecht wird auf U gemapped

===Durchführungsanleitung des BMI vom 9.9.2020===
''[…] „inter“, „divers“ oder „offen“ als Geschlechtsbezeichnung […] oder zum Geschlecht von jeglicher Angabe abzusehen […]. Zu beachten ist, dass die Ergänzung des Geschlechtseintrags im Zentralen Personenstandsregister nicht nur auf weiblich oder männlich, sondern auch auf „divers“, „inter“ oder „offen“ lauten kann oder ein bereits gemachter Eintrag zu löschen ist, sodass zum Geschlecht keine Angaben vorliegen. ''

=== Mehrere Attribute für das Geschlecht ===
Es wird aufgrund der rechtlichen Erkenntnis mehr als 2 Ausprägungen für das Geschlecht geben müssen.
Daher sollten für eine Person mehrere Attribute für das Geschlecht vorgesehen werden:
* Amtliches Geschlecht (Personenstandswesen in den behördlichen Registern)
* Sozialversicherungs-Geschlecht (ggf. abweichend vom Personenstandswesen für den Leistungsbezug der Krankenversicherung)
* (Krankenhaus-)Administratives Geschlecht (zB für Bettenbelegung)
* Medizinische Geschlechtsausprägungen (für Laborwerte, automatische Berechnungen, Checks und Warnungen)

=HL7 Gender Harmony Project=
https://confluence.hl7.org/display/VOC/The+Gender+Harmony+Project
https://confluence.hl7.org/display/VOC/Gender+Harmony+Terminology
https://confluence.hl7.org/display/VOC/Gender+Identity

EImpf Impfstoffe

2023-09-01T08:41:07Z

Sjencic: /* Attribute der eImpf_Impfstoffe Liste */

{{#customtitle:eImpf_Impfstoffe}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==eImpf_Impfstoffe (1.2.40.0.34.4.16.1)==
Liste der Impfungen gelistet nach PZN. Hinweis: In der Liste der Impfstoffe sind idente Impfstoff Bezeichnungen mit unterschiedlichen PZN enthalten. Diese Präparate unterscheiden sich in der Packungsgröße oder der Zulassungsnummer. Die Attribute können unter den Details der einzelnen Konzepte nachgelesen werden.

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für den e-Impfpass verwendbaren Impfstoffe. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der eImpf_Impfstoffe Liste. '''UNKLAR''' In der eImpf_Impfstoffe Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
ELGA GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH und ELGA GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen

====Attribute der eImpf_Impfstoffe Liste====
Die Attribute in der eImpf_Impfstoffe Liste werden aus der ASP-Liste herangezogen, jedoch gelten nicht dieselben Regeln wie in der e-Medikation. Alle Impfstoffe, die in der eImpf_Impfstoffe Liste vorhanden sind, dürfen im e-Impfpass ausgewählt werden. Die e-Med-Attribute werden nur mitgeführt, damit die Codeliste in Zukunft mit der ASP-Liste wieder vereinigt werden kann.

Wichtig für den e-Impfpass sind die Informationen zu den Impfindikationen! Diese Informationen werden nicht in der aktuellen ASP-Liste bereitgestellt und müssen manuell in diese Listen eingetragen werden.

* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - “Zulassungsname“
* '''DisplayName''' (Datenquelle APO-Verlag) - Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamen (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES)
* '''Zulassungsstatus''' - z.B. zugelassen; Text des zum Zeitpunkt des Exports aktuellen GA Status der ASP; hier ist kein Codesystem hinterlegt
* '''Zulassungsinhaber''' - Name der Organisation mit Rolle = Inhaber vom GA ASP; hier ist kein Codesystem hinterlegt
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Die Logik der "ELGA Gültigkeit" hat für den e-Impfpass keine Relevanz.
Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen). Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - Dieses Attribute wird beim Eintrag in den e-Impfpass nicht berücksichtigt. Es beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA ImpfungIndikation''' (Datenquelle ELGA) - Dieses Attribut stellt die Krankheit dar, gegen die die Impfung wirkt und dient als Verknüpfung zu den ImmunizationTargets. Je nach Impfung kann eine PZN mehrere Impfindikationen beinhalten (z.B. Kombinationsimpfungen). Bei den Kombinationsimpfungen werden die Attribute ELGA_ImpfungIndikation_K_code, ELGA_ImpfungIndikation_K_text mit dem entsprechenden ImmunizationTarget befüllt z.B.Diphtherie-Pertussis-Tetanus Impfstoffkombination und danach werden die einzelnen Impfstoffe in die ELGA_ImpfungIndikation_01_code, ELGA_ImpfungIndikation_01_text usw. eingefüllt.
** Code z.B. 2.16.840.1.113883.6.96:836377006 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
** Text z.B. "Influenza Impfstoff"
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA Packaging''' (Datenquelle AGES) - Primärverpackung
**Code z.B. 1.2.40.0.34.5.219:100000073496 (OID des Codesystems "Medikation_Packaging":Code)
**Text z.B. "Blisterpackung"
* '''ELGA PartName''' (Datenquelle AGES) - beinhaltet den Prüfnamen der ASP
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
**Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''Active Ingredient''' (Datenquelle AGES) - in englisch ausgegeben.
**Code z.B. 1.2.40.0.34.5.221:100000091410 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. MELPHALAN
* '''Ingredient Role''' (Datenquelle AGES) - Fixwert "active"
* '''Ingredient low strength''' (Datenquelle AGES) - Menge. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Ingredient low strength unit''' (Datenquelle AGES) - Einheit. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Reference Ingredient''' (in Englisch, Datenquelle AGES) - falls keine Referenzsubstanz gepflegt ist, wird Name wenn vorhanden in Englisch, Menge und Einheit der dazugehörigen Substanz angezeigt
**Code z.B. 1.2.40.0.34.5.221:100000089278 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. CLOSTRIDIUM TETANI
* '''Reference low strength''' (Datenquelle AGES) - Menge
* '''Reference low strength unit''' (Datenquelle AGES) - Einheit
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft

Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant
* '''Status''' (Datenquelle ELGA) - '''UNKLAR'''noch nicht durchgedacht - hier sollten die aktiven und inaktiven Codes von einander unterschieden werden

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

Aktuell befinden sich leere Attribute (Barcode1-5) im Codesystem, die nicht zu beachten sind.

===Releasezyklus===
Die ASP-Liste wird monatlich aktualisiert, aber die Impfstoffe ändern sich nicht im selben Rhythmus. Daher muss monatlich eine Kontrolle durchgeführt und bei Bedarf die Liste (inkl. eImpf_Impfstoffe_VS) angepasst werden

[[Kategorie:Terminologieserver]]

EImpf Impfstoffe

2023-09-01T08:40:33Z

Sjencic: /* Attribute der eImpf_Impfstoffe Liste */

{{#customtitle:eImpf_Impfstoffe}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==eImpf_Impfstoffe (1.2.40.0.34.4.16.1)==
Liste der Impfungen gelistet nach PZN. Hinweis: In der Liste der Impfstoffe sind idente Impfstoff Bezeichnungen mit unterschiedlichen PZN enthalten. Diese Präparate unterscheiden sich in der Packungsgröße oder der Zulassungsnummer. Die Attribute können unter den Details der einzelnen Konzepte nachgelesen werden.

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für den e-Impfpass verwendbaren Impfstoffe. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der eImpf_Impfstoffe Liste. '''UNKLAR''' In der eImpf_Impfstoffe Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
ELGA GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH und ELGA GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen

====Attribute der eImpf_Impfstoffe Liste====
Die Attribute in der eImpf_Impfstoffe Liste werden aus der ASP-Liste herangezogen, jedoch gelten nicht dieselben Regeln wie in der e-Medikation. Alle Impfstoffe, die in der eImpf_Impfstoffe Liste vorhanden sind, dürfen im e-Impfpass ausgewählt werden. Die e-Med-Attribute werden nur mitgeführt, damit die Codeliste in Zukunft mit der ASP-Liste wieder vereinigt werden kann.

Wichtig für den e-Impfpass sind die Informationen zu den Impfindikationen! Diese Informationen werden nicht in der aktuellen ASP-Liste bereitgestellt und müssen manuell in diese Listen eingetragen werden.

* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - “Zulassungsname“
* '''DisplayName''' (Datenquelle APO-Verlag) - Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamen (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES)
* '''Zulassungsstatus''' - z.B. zugelassen; Text des zum Zeitpunkt des Exports aktuellen GA Status der ASP; hier ist kein Codesystem hinterlegt
* '''Zulassungsinhaber''' - Name der Organisation mit Rolle = Inhaber vom GA ASP; hier ist kein Codesystem hinterlegt
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Die Logik der "ELGA Gültigkeit" hat für den e-Impfpass keine Relevanz.
Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen). Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - Dieses Attribute wird beim Eintrag in den e-Impfpass nicht berücksichtigt. Es beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA ImpfungIndikation''' (Datenquelle ELGA) - Dieses Attribut stellt die Krankheit dar, gegen die die Impfung wirkt und dient als Verknüpfung zu den ImmunizationTargets. Je nach Impfung kann eine PZN mehrere Impfindikationen beinhalten (z.B. Kombinationsimpfungen). Bei den Kombinationsimpfungen werden die Attribute ELGA_ImpfungIndikation_K_code, ELGA_ImpfungIndikation_K_text mit dem entsprechenden ImmunizationTarget befüllt z.B.Diphtherie-Pertussis-Tetanus Impfstoffkombination und danach werden die einzelnen Impfstoffe in die ELGA_ImpfungIndikation_01_code, ELGA_ImpfungIndikation_01_text usw. eingefüllt.
** Code z.B. 2.16.840.1.113883.6.96:836377006 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
** Text z.B. "Influenza Impfstoff"
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA Packaging''' (Datenquelle AGES) - Primärverpackung
**Code z.B. 1.2.40.0.34.5.219:100000073496 (OID des Codesystems "Medikation_Packaging":Code)
***Text z.B. "Blisterpackung"
* '''ELGA PartName''' (Datenquelle AGES) - beinhaltet den Prüfnamen der ASP
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
** Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''Active Ingredient''' (Datenquelle AGES) - in englisch ausgegeben.
**Code z.B. 1.2.40.0.34.5.221:100000091410 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. MELPHALAN
* '''Ingredient Role''' (Datenquelle AGES) - Fixwert "active"
* '''Ingredient low strength''' (Datenquelle AGES) - Menge. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Ingredient low strength unit''' (Datenquelle AGES) - Einheit. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Reference Ingredient''' (in Englisch, Datenquelle AGES) - falls keine Referenzsubstanz gepflegt ist, wird Name wenn vorhanden in Englisch, Menge und Einheit der dazugehörigen Substanz angezeigt
**Code z.B. 1.2.40.0.34.5.221:100000089278 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. CLOSTRIDIUM TETANI
* '''Reference low strength''' (Datenquelle AGES) - Menge
* '''Reference low strength unit''' (Datenquelle AGES) - Einheit
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft

Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant
* '''Status''' (Datenquelle ELGA) - '''UNKLAR'''noch nicht durchgedacht - hier sollten die aktiven und inaktiven Codes von einander unterschieden werden

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

Aktuell befinden sich leere Attribute (Barcode1-5) im Codesystem, die nicht zu beachten sind.

===Releasezyklus===
Die ASP-Liste wird monatlich aktualisiert, aber die Impfstoffe ändern sich nicht im selben Rhythmus. Daher muss monatlich eine Kontrolle durchgeführt und bei Bedarf die Liste (inkl. eImpf_Impfstoffe_VS) angepasst werden

[[Kategorie:Terminologieserver]]

EImpf Impfstoffe

2023-09-01T08:39:34Z

Sjencic: /* Attribute der eImpf_Impfstoffe Liste */

{{#customtitle:eImpf_Impfstoffe}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==eImpf_Impfstoffe (1.2.40.0.34.4.16.1)==
Liste der Impfungen gelistet nach PZN. Hinweis: In der Liste der Impfstoffe sind idente Impfstoff Bezeichnungen mit unterschiedlichen PZN enthalten. Diese Präparate unterscheiden sich in der Packungsgröße oder der Zulassungsnummer. Die Attribute können unter den Details der einzelnen Konzepte nachgelesen werden.

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für den e-Impfpass verwendbaren Impfstoffe. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der eImpf_Impfstoffe Liste. '''UNKLAR''' In der eImpf_Impfstoffe Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
ELGA GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH und ELGA GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen

====Attribute der eImpf_Impfstoffe Liste====
Die Attribute in der eImpf_Impfstoffe Liste werden aus der ASP-Liste herangezogen, jedoch gelten nicht dieselben Regeln wie in der e-Medikation. Alle Impfstoffe, die in der eImpf_Impfstoffe Liste vorhanden sind, dürfen im e-Impfpass ausgewählt werden. Die e-Med-Attribute werden nur mitgeführt, damit die Codeliste in Zukunft mit der ASP-Liste wieder vereinigt werden kann.

Wichtig für den e-Impfpass sind die Informationen zu den Impfindikationen! Diese Informationen werden nicht in der aktuellen ASP-Liste bereitgestellt und müssen manuell in diese Listen eingetragen werden.

* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - “Zulassungsname“
* '''DisplayName''' (Datenquelle APO-Verlag) - Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamen (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES)
* '''Zulassungsstatus''' - z.B. zugelassen; Text des zum Zeitpunkt des Exports aktuellen GA Status der ASP; hier ist kein Codesystem hinterlegt
* '''Zulassungsinhaber''' - Name der Organisation mit Rolle = Inhaber vom GA ASP; hier ist kein Codesystem hinterlegt
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Die Logik der "ELGA Gültigkeit" hat für den e-Impfpass keine Relevanz.
Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen). Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - Dieses Attribute wird beim Eintrag in den e-Impfpass nicht berücksichtigt. Es beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA ImpfungIndikation''' (Datenquelle ELGA) - Dieses Attribut stellt die Krankheit dar, gegen die die Impfung wirkt und dient als Verknüpfung zu den ImmunizationTargets. Je nach Impfung kann eine PZN mehrere Impfindikationen beinhalten (z.B. Kombinationsimpfungen). Bei den Kombinationsimpfungen werden die Attribute ELGA_ImpfungIndikation_K_code, ELGA_ImpfungIndikation_K_text mit dem entsprechenden ImmunizationTarget befüllt z.B.Diphtherie-Pertussis-Tetanus Impfstoffkombination und danach werden die einzelnen Impfstoffe in die ELGA_ImpfungIndikation_01_code, ELGA_ImpfungIndikation_01_text usw. eingefüllt.
** Code z.B. 2.16.840.1.113883.6.96:836377006 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
** Text z.B. "Influenza Impfstoff"
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA Packaging''' (Datenquelle AGES) - Primärverpackung
**Code z.B. 1.2.40.0.34.5.219:100000073496 (OID des Codesystems "Medikation_Packaging":Code)
* '''ELGA PartName''' (Datenquelle AGES) - beinhaltet den Prüfnamen der ASP
***Text z.B. "Blisterpackung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
** Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''Active Ingredient''' (Datenquelle AGES) - in englisch ausgegeben.
**Code z.B. 1.2.40.0.34.5.221:100000091410 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. MELPHALAN
* '''Ingredient Role''' (Datenquelle AGES) - Fixwert "active"
* '''Ingredient low strength''' (Datenquelle AGES) - Menge. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Ingredient low strength unit''' (Datenquelle AGES) - Einheit. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Reference Ingredient''' (in Englisch, Datenquelle AGES) - falls keine Referenzsubstanz gepflegt ist, wird Name wenn vorhanden in Englisch, Menge und Einheit der dazugehörigen Substanz angezeigt
**Code z.B. 1.2.40.0.34.5.221:100000089278 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. CLOSTRIDIUM TETANI
* '''Reference low strength''' (Datenquelle AGES) - Menge
* '''Reference low strength unit''' (Datenquelle AGES) - Einheit
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft

Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant
* '''Status''' (Datenquelle ELGA) - '''UNKLAR'''noch nicht durchgedacht - hier sollten die aktiven und inaktiven Codes von einander unterschieden werden

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

Aktuell befinden sich leere Attribute (Barcode1-5) im Codesystem, die nicht zu beachten sind.

===Releasezyklus===
Die ASP-Liste wird monatlich aktualisiert, aber die Impfstoffe ändern sich nicht im selben Rhythmus. Daher muss monatlich eine Kontrolle durchgeführt und bei Bedarf die Liste (inkl. eImpf_Impfstoffe_VS) angepasst werden

[[Kategorie:Terminologieserver]]

ASP Liste

2023-08-25T06:02:42Z

Sjencic: /* Attribute der ASP-Liste */

{{#customtitle:ASP Liste}}

==ASP Liste (1.2.40.0.34.4.16)==
Liste der humanen Arzneispezialitäten gelistet nach PZN

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für die e-Medikation verwendbaren Medikamente bzw. Arzneimittelspezialitäten. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der ASP-Liste. In der ASP-Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

Anmerkung: Magistrale Zubereitungen werden als Freitextfeld zu Informationszwecken in e-Medikation übernommen und können optional mit [[ATC_deutsch_(WIdO)|ATC-Code]] versehen werden.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
AGES GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen
====Attribute der ASP-Liste====
Die AGES liefert dem e-Medikation System eine Liste der Arzneispezialitäten (ASP-Liste) zu. In dieser Datenbasis MÜSSEN (ausgenommen ATC-Code) folgende Datenfelder vorhanden sein:
* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - "Zulassungsname"
* '''DisplayName''' (Datenquelle APO-Verlag) - "Handelsname" Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamens (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES) - Seit dem Juni-Release 6.1.0 2021 wird bei EU-Zulassungsnummern nur der Teil bis inkl. Stärke verwendet, der Rest (dh. der Teil ab dem 4. Schrägstrich) wird abgeschnitten. Bsp: Gardasil Zulassungsnummer EU/1/06/357/003-017,019-021 → EU/1/06/357
* '''Zulassungsstatus''' - z.B. zugelassen; Text des zum Zeitpunkt des Exports aktuellen GA Status der ASP; hier ist kein Codesystem hinterlegt
* '''Zulassungsinhaber''' - Name der Organisation mit Rolle = Inhaber vom GA ASP; hier ist kein Codesystem hinterlegt
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Für die e-Medikation werden nur Arzneimittel akzeptiert die den Wert "TRUE" tragen. Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen).
**Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar. Dieses Attribute wird beim Eintrag in die e-Medikation nicht berücksichtigt.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA Packaging''' (Datenquelle AGES) - Primärverpackung
**Code z.B. 1.2.40.0.34.5.219:100000073496 (OID des Codesystems "Medikation_Packaging":Code)
***Text z.B. "Blisterpackung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
**Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''Active Ingredient''' (Datenquelle AGES) - in englisch ausgegeben.
**Code z.B. 1.2.40.0.34.5.221:100000091410 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. MELPHALAN
* '''Ingredient Role''' (Datenquelle AGES) - Fixwert "active"
* '''Ingredient low strength''' (Datenquelle AGES) - Menge. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Ingredient low strength unit''' (Datenquelle AGES) - Einheit. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Reference Ingredient''' (in Englisch, Datenquelle AGES) - falls keine Referenzsubstanz gepflegt ist, wird Name wenn vorhanden in Englisch, Menge und Einheit der dazugehörigen Substanz angezeigt
**Code z.B. 1.2.40.0.34.5.221:100000089278 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. CLOSTRIDIUM TETANI
* '''Reference low strength''' (Datenquelle AGES) - Menge
* '''Reference low strength unit''' (Datenquelle AGES) - Einheit
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft
Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

====Weitere Codesysteme der AGES====

Die ASP-Liste steht in direktem Zusammenhang mit einer Reihe an Terminologien. Diese Terminologien werden (wie oben beschrieben) als code/text-Attributpaar in der ASP-Liste referenziert:
* ATC
* Medikation_AGES_Wirkstoffe 1.2.40.0.34.5.156
** Liste an aktiven Wirkstoffen
** Quelle: EMA (European Medical Agency) /EUTCT (European Union Telematics Controlled Terms)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingungen EUTCT: The information concerning this list is reproduced from the EUTCT repository with permission of the EMA (European Medicines Agency).
* MedikationArtAnwendung 1.2.40.0.10.1.4.3.4.3.4
** Arten der Anwendung eines Medikaments, etwa „intramuskuläre Anwendung“ oder „Anwendung am Ohr“
** Quelle: EDQM (Europäisches Direktorat für die Qualität von Arzneimitteln)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingung EDQM: It is clearly stated that the data is from the EDQM Standard Terms database (http://standardterms.edqm.eu), and that it is reproduced with the permission of the European Directorate for the Quality of Medicines & HealthCare, Council of Europe (EDQM). The Standard Terms data is not modified, and no other data is represented as being part of Standard Terms. If any additional data is presented alongside, it must be clear that it does not originate from Standard Terms. The date on which the data was retrieved from the Standard Terms database is clearly stated, with a notice that the EDQM Standard Terms database is not a static list and content can change over time.
* MedikationDarreichungsform 1.2.40.0.10.1.4.3.4.3.5
** Darreichungsform des Medikaments, etwa „Filmtablette“ oder „Sirup“
** Quelle: EDQM (Europäisches Direktorat für die Qualität von Arzneimitteln)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingung EDQM: It is clearly stated that the data is from the EDQM Standard Terms database (http://standardterms.edqm.eu), and that it is reproduced with the permission of the European Directorate for the Quality of Medicines & HealthCare, Council of Europe (EDQM). The Standard Terms data is not modified, and no other data is represented as being part of Standard Terms. If any additional data is presented alongside, it must be clear that it does not originate from Standard Terms. The date on which the data was retrieved from the Standard Terms database is clearly stated, with a notice that the EDQM Standard Terms database is not a static list and content can change over time.

Weitere e-Medikation Codelisten
* MedikationsRezeptart 1.2.40.0.10.1.4.3.4.3.3
** Unterscheidung zwischen Kassen-, Privat- und Substitutionsrezept
** Nicht als Attribut in der ASP-Liste
** Quelle: Codes definiert im e-Medikationsprojekt
** Keine laufenden Änderungen vorgesehen
* MedikationRezeptpflichtstatus 1.2.40.0.10.1.4.3.4.3.7
** Unterscheidung zwischen „Arzneimittel zur Abgabe ohne aerztliche Verschreibung“ und „Arzneimittel zur Abgabe gegen aerztliche Verschreibung“
** Quelle: EMA (European Medical Agency) /EUTCT (European Union Telematics Controlled Terms)
** Bereitstellung durch AGES
** Nutzungsbedingungen: The information concerning this list is reproduced from the EUTCT repository with permission of the EMA (European Medicines Agency).
* MedikationTherapieart 1.2.40.0.10.1.4.3.4.3.6
** Unterscheidung zwischen Einzel, und Nicht-Einzelverordnung
** Nicht als Attribut in der ASP-Liste
** Quelle: Codes definiert im e-Medikationsprojekt
** Keine laufenden Änderungen vorgesehen

===Releasezyklus===
Die referenzierten Codesysteme werden von der AGES gepflegt und bei Änderungen werden diese mit dem monatlichen Import mitgeliefert.

[[Kategorie:Terminologieserver]]

EImpf Impfstoffe

2023-08-25T06:02:38Z

Sjencic: /* Attribute der eImpf_Impfstoffe Liste */

{{#customtitle:eImpf_Impfstoffe}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==eImpf_Impfstoffe (1.2.40.0.34.4.16.1)==
Liste der Impfungen gelistet nach PZN. Hinweis: In der Liste der Impfstoffe sind idente Impfstoff Bezeichnungen mit unterschiedlichen PZN enthalten. Diese Präparate unterscheiden sich in der Packungsgröße oder der Zulassungsnummer. Die Attribute können unter den Details der einzelnen Konzepte nachgelesen werden.

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für den e-Impfpass verwendbaren Impfstoffe. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der eImpf_Impfstoffe Liste. '''UNKLAR''' In der eImpf_Impfstoffe Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
ELGA GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH und ELGA GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen

====Attribute der eImpf_Impfstoffe Liste====
Die Attribute in der eImpf_Impfstoffe Liste werden aus der ASP-Liste herangezogen, jedoch gelten nicht dieselben Regeln wie in der e-Medikation. Alle Impfstoffe, die in der eImpf_Impfstoffe Liste vorhanden sind, dürfen im e-Impfpass ausgewählt werden. Die e-Med-Attribute werden nur mitgeführt, damit die Codeliste in Zukunft mit der ASP-Liste wieder vereinigt werden kann.

Wichtig für den e-Impfpass sind die Informationen zu den Impfindikationen! Diese Informationen werden nicht in der aktuellen ASP-Liste bereitgestellt und müssen manuell in diese Listen eingetragen werden.

* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - “Zulassungsname“
* '''DisplayName''' (Datenquelle APO-Verlag) - Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamen (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES)
* '''Zulassungsstatus''' - z.B. zugelassen; Text des zum Zeitpunkt des Exports aktuellen GA Status der ASP; hier ist kein Codesystem hinterlegt
* '''Zulassungsinhaber''' - Name der Organisation mit Rolle = Inhaber vom GA ASP; hier ist kein Codesystem hinterlegt
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Die Logik der "ELGA Gültigkeit" hat für den e-Impfpass keine Relevanz.
Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen). Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - Dieses Attribute wird beim Eintrag in den e-Impfpass nicht berücksichtigt. Es beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA ImpfungIndikation''' (Datenquelle ELGA) - Dieses Attribut stellt die Krankheit dar, gegen die die Impfung wirkt und dient als Verknüpfung zu den ImmunizationTargets. Je nach Impfung kann eine PZN mehrere Impfindikationen beinhalten (z.B. Kombinationsimpfungen). Bei den Kombinationsimpfungen werden die Attribute ELGA_ImpfungIndikation_K_code, ELGA_ImpfungIndikation_K_text mit dem entsprechenden ImmunizationTarget befüllt z.B.Diphtherie-Pertussis-Tetanus Impfstoffkombination und danach werden die einzelnen Impfstoffe in die ELGA_ImpfungIndikation_01_code, ELGA_ImpfungIndikation_01_text usw. eingefüllt.
** Code z.B. 2.16.840.1.113883.6.96:836377006 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
** Text z.B. "Influenza Impfstoff"
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA Packaging''' (Datenquelle AGES) - Primärverpackung
**Code z.B. 1.2.40.0.34.5.219:100000073496 (OID des Codesystems "Medikation_Packaging":Code)
***Text z.B. "Blisterpackung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
** Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''Active Ingredient''' (Datenquelle AGES) - in englisch ausgegeben.
**Code z.B. 1.2.40.0.34.5.221:100000091410 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. MELPHALAN
* '''Ingredient Role''' (Datenquelle AGES) - Fixwert "active"
* '''Ingredient low strength''' (Datenquelle AGES) - Menge. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Ingredient low strength unit''' (Datenquelle AGES) - Einheit. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Reference Ingredient''' (in Englisch, Datenquelle AGES) - falls keine Referenzsubstanz gepflegt ist, wird Name wenn vorhanden in Englisch, Menge und Einheit der dazugehörigen Substanz angezeigt
**Code z.B. 1.2.40.0.34.5.221:100000089278 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. CLOSTRIDIUM TETANI
* '''Reference low strength''' (Datenquelle AGES) - Menge
* '''Reference low strength unit''' (Datenquelle AGES) - Einheit
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft

Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant
* '''Status''' (Datenquelle ELGA) - '''UNKLAR'''noch nicht durchgedacht - hier sollten die aktiven und inaktiven Codes von einander unterschieden werden

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

Aktuell befinden sich leere Attribute (Barcode1-5) im Codesystem, die nicht zu beachten sind.

===Releasezyklus===
Die ASP-Liste wird monatlich aktualisiert, aber die Impfstoffe ändern sich nicht im selben Rhythmus. Daher muss monatlich eine Kontrolle durchgeführt und bei Bedarf die Liste (inkl. eImpf_Impfstoffe_VS) angepasst werden

[[Kategorie:Terminologieserver]]

EImpf Impfstoffe

2023-08-24T14:25:16Z

Sjencic: /* Attribute der eImpf_Impfstoffe Liste */

{{#customtitle:eImpf_Impfstoffe}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==eImpf_Impfstoffe (1.2.40.0.34.4.16.1)==
Liste der Impfungen gelistet nach PZN. Hinweis: In der Liste der Impfstoffe sind idente Impfstoff Bezeichnungen mit unterschiedlichen PZN enthalten. Diese Präparate unterscheiden sich in der Packungsgröße oder der Zulassungsnummer. Die Attribute können unter den Details der einzelnen Konzepte nachgelesen werden.

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für den e-Impfpass verwendbaren Impfstoffe. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der eImpf_Impfstoffe Liste. '''UNKLAR''' In der eImpf_Impfstoffe Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
ELGA GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH und ELGA GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen

====Attribute der eImpf_Impfstoffe Liste====
Die Attribute in der eImpf_Impfstoffe Liste werden aus der ASP-Liste herangezogen, jedoch gelten nicht dieselben Regeln wie in der e-Medikation. Alle Impfstoffe, die in der eImpf_Impfstoffe Liste vorhanden sind, dürfen im e-Impfpass ausgewählt werden. Die e-Med-Attribute werden nur mitgeführt, damit die Codeliste in Zukunft mit der ASP-Liste wieder vereinigt werden kann.

Wichtig für den e-Impfpass sind die Informationen zu den Impfindikationen! Diese Informationen werden nicht in der aktuellen ASP-Liste bereitgestellt und müssen manuell in diese Listen eingetragen werden.

* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - “Zulassungsname“
* '''DisplayName''' (Datenquelle APO-Verlag) - Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamen (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES)
* '''Zulassungsstatus''' - z.B. zugelassen; Text des zum Zeitpunkt des Exports aktuellen GA Status der ASP; hier ist kein Codesystem hinterlegt
* '''Zulassungsinhaber''' - Name der Organisation mit Rolle = Inhaber vom GA ASP; hier ist kein Codesystem hinterlegt
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Die Logik der "ELGA Gültigkeit" hat für den e-Impfpass keine Relevanz.
Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen). Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - Dieses Attribute wird beim Eintrag in den e-Impfpass nicht berücksichtigt. Es beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA ImpfungIndikation''' (Datenquelle ELGA) - Dieses Attribut stellt die Krankheit dar, gegen die die Impfung wirkt und dient als Verknüpfung zu den ImmunizationTargets. Je nach Impfung kann eine PZN mehrere Impfindikationen beinhalten (z.B. Kombinationsimpfungen). Bei den Kombinationsimpfungen werden die Attribute ELGA_ImpfungIndikation_K_code, ELGA_ImpfungIndikation_K_text mit dem entsprechenden ImmunizationTarget befüllt z.B.Diphtherie-Pertussis-Tetanus Impfstoffkombination und danach werden die einzelnen Impfstoffe in die ELGA_ImpfungIndikation_01_code, ELGA_ImpfungIndikation_01_text usw. eingefüllt.
** Code z.B. 2.16.840.1.113883.6.96:836377006 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
** Text z.B. "Influenza Impfstoff"
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA Packaging''' (Datenquelle AGES) - Primärverpackung
**Code z.B. 1.2.40.0.34.5.219:100000073496 (OID des Codesystems "Medikation_Packaging":Code)
***Text z.B. "Blisterpackung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
** Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''Active Ingredient''' (Datenquelle AGES) - in englisch ausgegeben.
**Code z.B. 1.2.40.0.34.5.221:100000091410 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. MELPHALAN
* '''Ingredient Role''' (Datenquelle AGES) - Fixwert "active"
* '''Ingredient low strength''' (Datenquelle AGES) - Menge. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Ingredient low strength unit''' (Datenquelle AGES) - Einheit. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft

Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant
* '''Status''' (Datenquelle ELGA) - '''UNKLAR'''noch nicht durchgedacht - hier sollten die aktiven und inaktiven Codes von einander unterschieden werden

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

Aktuell befinden sich leere Attribute (Barcode1-5) im Codesystem, die nicht zu beachten sind.

===Releasezyklus===
Die ASP-Liste wird monatlich aktualisiert, aber die Impfstoffe ändern sich nicht im selben Rhythmus. Daher muss monatlich eine Kontrolle durchgeführt und bei Bedarf die Liste (inkl. eImpf_Impfstoffe_VS) angepasst werden

[[Kategorie:Terminologieserver]]

ASP Liste

2023-07-18T11:47:35Z

Sjencic: /* Weitere Codesysteme der AGES */

{{#customtitle:ASP Liste}}

==ASP Liste (1.2.40.0.34.4.16)==
Liste der humanen Arzneispezialitäten gelistet nach PZN

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für die e-Medikation verwendbaren Medikamente bzw. Arzneimittelspezialitäten. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der ASP-Liste. In der ASP-Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

Anmerkung: Magistrale Zubereitungen werden als Freitextfeld zu Informationszwecken in e-Medikation übernommen und können optional mit [[ATC_deutsch_(WIdO)|ATC-Code]] versehen werden.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
AGES GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen
====Attribute der ASP-Liste====
Die AGES liefert dem e-Medikation System eine Liste der Arzneispezialitäten (ASP-Liste) zu. In dieser Datenbasis MÜSSEN (ausgenommen ATC-Code) folgende Datenfelder vorhanden sein:
* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - "Zulassungsname"
* '''DisplayName''' (Datenquelle APO-Verlag) - "Handelsname" Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamens (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES) - Seit dem Juni-Release 6.1.0 2021 wird bei EU-Zulassungsnummern nur der Teil bis inkl. Stärke verwendet, der Rest (dh. der Teil ab dem 4. Schrägstrich) wird abgeschnitten. Bsp: Gardasil Zulassungsnummer EU/1/06/357/003-017,019-021 → EU/1/06/357
* '''Zulassungsstatus''' - z.B. zugelassen; Text des zum Zeitpunkt des Exports aktuellen GA Status der ASP; hier ist kein Codesystem hinterlegt
* '''Zulassungsinhaber''' - Name der Organisation mit Rolle = Inhaber vom GA ASP; hier ist kein Codesystem hinterlegt
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Für die e-Medikation werden nur Arzneimittel akzeptiert die den Wert "TRUE" tragen. Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen).
**Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar. Dieses Attribute wird beim Eintrag in die e-Medikation nicht berücksichtigt.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA Packaging''' (Datenquelle AGES) - Primärverpackung
**Code z.B. 1.2.40.0.34.5.219:100000073496 (OID des Codesystems "Medikation_Packaging":Code)
***Text z.B. "Blisterpackung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
**Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''Active Ingredient''' (Datenquelle AGES) - in englisch ausgegeben.
**Code z.B. 1.2.40.0.34.5.221:100000091410 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. MELPHALAN
* '''Ingredient Role''' (Datenquelle AGES) - Fixwert "active"
* '''Ingredient low strength''' (Datenquelle AGES) - Menge. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Ingredient low strength unit''' (Datenquelle AGES) - Einheit. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft
Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

====Weitere Codesysteme der AGES====

Die ASP-Liste steht in direktem Zusammenhang mit einer Reihe an Terminologien. Diese Terminologien werden (wie oben beschrieben) als code/text-Attributpaar in der ASP-Liste referenziert:
* ATC
* Medikation_AGES_Wirkstoffe 1.2.40.0.34.5.156
** Liste an aktiven Wirkstoffen
** Quelle: EMA (European Medical Agency) /EUTCT (European Union Telematics Controlled Terms)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingungen EUTCT: The information concerning this list is reproduced from the EUTCT repository with permission of the EMA (European Medicines Agency).
* MedikationArtAnwendung 1.2.40.0.10.1.4.3.4.3.4
** Arten der Anwendung eines Medikaments, etwa „intramuskuläre Anwendung“ oder „Anwendung am Ohr“
** Quelle: EDQM (Europäisches Direktorat für die Qualität von Arzneimitteln)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingung EDQM: It is clearly stated that the data is from the EDQM Standard Terms database (http://standardterms.edqm.eu), and that it is reproduced with the permission of the European Directorate for the Quality of Medicines & HealthCare, Council of Europe (EDQM). The Standard Terms data is not modified, and no other data is represented as being part of Standard Terms. If any additional data is presented alongside, it must be clear that it does not originate from Standard Terms. The date on which the data was retrieved from the Standard Terms database is clearly stated, with a notice that the EDQM Standard Terms database is not a static list and content can change over time.
* MedikationDarreichungsform 1.2.40.0.10.1.4.3.4.3.5
** Darreichungsform des Medikaments, etwa „Filmtablette“ oder „Sirup“
** Quelle: EDQM (Europäisches Direktorat für die Qualität von Arzneimitteln)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingung EDQM: It is clearly stated that the data is from the EDQM Standard Terms database (http://standardterms.edqm.eu), and that it is reproduced with the permission of the European Directorate for the Quality of Medicines & HealthCare, Council of Europe (EDQM). The Standard Terms data is not modified, and no other data is represented as being part of Standard Terms. If any additional data is presented alongside, it must be clear that it does not originate from Standard Terms. The date on which the data was retrieved from the Standard Terms database is clearly stated, with a notice that the EDQM Standard Terms database is not a static list and content can change over time.

Weitere e-Medikation Codelisten
* MedikationsRezeptart 1.2.40.0.10.1.4.3.4.3.3
** Unterscheidung zwischen Kassen-, Privat- und Substitutionsrezept
** Nicht als Attribut in der ASP-Liste
** Quelle: Codes definiert im e-Medikationsprojekt
** Keine laufenden Änderungen vorgesehen
* MedikationRezeptpflichtstatus 1.2.40.0.10.1.4.3.4.3.7
** Unterscheidung zwischen „Arzneimittel zur Abgabe ohne aerztliche Verschreibung“ und „Arzneimittel zur Abgabe gegen aerztliche Verschreibung“
** Quelle: EMA (European Medical Agency) /EUTCT (European Union Telematics Controlled Terms)
** Bereitstellung durch AGES
** Nutzungsbedingungen: The information concerning this list is reproduced from the EUTCT repository with permission of the EMA (European Medicines Agency).
* MedikationTherapieart 1.2.40.0.10.1.4.3.4.3.6
** Unterscheidung zwischen Einzel, und Nicht-Einzelverordnung
** Nicht als Attribut in der ASP-Liste
** Quelle: Codes definiert im e-Medikationsprojekt
** Keine laufenden Änderungen vorgesehen

===Releasezyklus===
Die referenzierten Codesysteme werden von der AGES gepflegt und bei Änderungen werden diese mit dem monatlichen Import mitgeliefert.

[[Kategorie:Terminologieserver]]

ASP Liste

2023-07-18T11:47:02Z

Sjencic: /* Weitere Codesysteme der AGES */

{{#customtitle:ASP Liste}}

==ASP Liste (1.2.40.0.34.4.16)==
Liste der humanen Arzneispezialitäten gelistet nach PZN

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für die e-Medikation verwendbaren Medikamente bzw. Arzneimittelspezialitäten. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der ASP-Liste. In der ASP-Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

Anmerkung: Magistrale Zubereitungen werden als Freitextfeld zu Informationszwecken in e-Medikation übernommen und können optional mit [[ATC_deutsch_(WIdO)|ATC-Code]] versehen werden.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
AGES GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen
====Attribute der ASP-Liste====
Die AGES liefert dem e-Medikation System eine Liste der Arzneispezialitäten (ASP-Liste) zu. In dieser Datenbasis MÜSSEN (ausgenommen ATC-Code) folgende Datenfelder vorhanden sein:
* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - "Zulassungsname"
* '''DisplayName''' (Datenquelle APO-Verlag) - "Handelsname" Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamens (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES) - Seit dem Juni-Release 6.1.0 2021 wird bei EU-Zulassungsnummern nur der Teil bis inkl. Stärke verwendet, der Rest (dh. der Teil ab dem 4. Schrägstrich) wird abgeschnitten. Bsp: Gardasil Zulassungsnummer EU/1/06/357/003-017,019-021 → EU/1/06/357
* '''Zulassungsstatus''' - z.B. zugelassen; Text des zum Zeitpunkt des Exports aktuellen GA Status der ASP; hier ist kein Codesystem hinterlegt
* '''Zulassungsinhaber''' - Name der Organisation mit Rolle = Inhaber vom GA ASP; hier ist kein Codesystem hinterlegt
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Für die e-Medikation werden nur Arzneimittel akzeptiert die den Wert "TRUE" tragen. Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen).
**Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar. Dieses Attribute wird beim Eintrag in die e-Medikation nicht berücksichtigt.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA Packaging''' (Datenquelle AGES) - Primärverpackung
**Code z.B. 1.2.40.0.34.5.219:100000073496 (OID des Codesystems "Medikation_Packaging":Code)
***Text z.B. "Blisterpackung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
**Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''Active Ingredient''' (Datenquelle AGES) - in englisch ausgegeben.
**Code z.B. 1.2.40.0.34.5.221:100000091410 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. MELPHALAN
* '''Ingredient Role''' (Datenquelle AGES) - Fixwert "active"
* '''Ingredient low strength''' (Datenquelle AGES) - Menge. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Ingredient low strength unit''' (Datenquelle AGES) - Einheit. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft
Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

====Weitere Codesysteme der AGES====

Die ASP-Liste steht in direktem Zusammenhang mit einer Reihe an Terminologien. Diese Terminologien werden (wie oben beschrieben) als code/text-Attributpaar in der ASP-Liste referenziert:
* ATC
* Medikation_AGES_Wirkstoffe 1.2.40.0.34.5.156
** Liste an aktiven Wirkstoffen
** Quelle: EMA (European Medical Agency) /EUTCT (European Union Telematics Controlled Terms)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingungen EUTCT: The information concerning this list is reproduced from the EUTCT repository with permission of the EMA (European Medicines Agency).
* MedikationArtAnwendung 1.2.40.0.10.1.4.3.4.3.4
** Arten der Anwendung eines Medikaments, etwa „intramuskuläre Anwendung“ oder „Anwendung am Ohr“
** Quelle: EDQM (Europäisches Direktorat für die Qualität von Arzneimitteln)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingung EDQM: It is clearly stated that the data is from the EDQM Standard Terms database (http://standardterms.edqm.eu), and that it is reproduced with the permission of the European Directorate for the Quality of Medicines & HealthCare, Council of Europe (EDQM). The Standard Terms data is not modified, and no other data is represented as being part of Standard Terms. If any additional data is presented alongside, it must be clear that it does not originate from Standard Terms. The date on which the data was retrieved from the Standard Terms database is clearly stated, with a notice that the EDQM Standard Terms database is not a static list and content can change over time.
* MedikationDarreichungsform 1.2.40.0.10.1.4.3.4.3.5
** Darreichungsform des Medikaments, etwa „Filmtablette“ oder „Sirup“
** Quelle: EDQM (Europäisches Direktorat für die Qualität von Arzneimitteln)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingung EDQM: It is clearly stated that the data is from the EDQM Standard Terms database (http://standardterms.edqm.eu), and that it is reproduced with the permission of the European Directorate for the Quality of Medicines & HealthCare, Council of Europe (EDQM). The Standard Terms data is not modified, and no other data is represented as being part of Standard Terms. If any additional data is presented alongside, it must be clear that it does not originate from Standard Terms. The date on which the data was retrieved from the Standard Terms database is clearly stated, with a notice that the EDQM Standard Terms database is not a static list and content can change over time.

Weitere e-Medikation Codelisten
* MedikationsRezeptart 1.2.40.0.10.1.4.3.4.3.3
** Unterscheidung zwischen Kassen-, Privat- und Substitutionsrezept
** Nicht als Attribut in der ASP-Liste
** Quelle: Codes definiert im e-Medikationsprojekt
** Keine laufenden Änderungen vorgesehen
* MedikationRezeptpflichtstatus 1.2.40.0.10.1.4.3.4.3.7
** Unterscheidung zwischen „Arzneimittel zur Abgabe ohne aerztliche Verschreibung“ und „Arzneimittel zur Abgabe gegen aerztliche Verschreibung“
** Quelle: EMA (European Medical Agency) /EUTCT (European Union Telematics Controlled Terms)
** Bereitstellung durch AGES, keine laufenden Änderungen vorgesehen
** Nutzungsbedingungen: The information concerning this list is reproduced from the EUTCT repository with permission of the EMA (European Medicines Agency).
* MedikationTherapieart 1.2.40.0.10.1.4.3.4.3.6
** Unterscheidung zwischen Einzel, und Nicht-Einzelverordnung
** Nicht als Attribut in der ASP-Liste
** Quelle: Codes definiert im e-Medikationsprojekt
** Keine laufenden Änderungen vorgesehen

===Releasezyklus===
Die referenzierten Codesysteme werden von der AGES gepflegt und bei Änderungen werden diese mit dem monatlichen Import mitgeliefert.

[[Kategorie:Terminologieserver]]

ASP Liste

2023-07-13T07:59:54Z

Sjencic: /* ASP Liste (1.2.40.0.34.4.16) */

{{#customtitle:ASP Liste}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==ASP Liste (1.2.40.0.34.4.16)==
Liste der humanen Arzneispezialitäten gelistet nach PZN

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für die e-Medikation verwendbaren Medikamente bzw. Arzneimittelspezialitäten. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der ASP-Liste. In der ASP-Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

Anmerkung: Magistrale Zubereitungen werden als Freitextfeld zu Informationszwecken in e-Medikation übernommen und können optional mit [[ATC_deutsch_(WIdO)|ATC-Code]] versehen werden.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
AGES GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen
====Attribute der ASP-Liste====
Die AGES liefert dem e-Medikation System eine Liste der Arzneispezialitäten (ASP-Liste) zu. In dieser Datenbasis MÜSSEN (ausgenommen ATC-Code) folgende Datenfelder vorhanden sein:
* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - "Zulassungsname"
* '''DisplayName''' (Datenquelle APO-Verlag) - "Handelsname" Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamens (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES) - Seit dem Juni-Release 6.1.0 2021 wird bei EU-Zulassungsnummern nur der Teil bis inkl. Stärke verwendet, der Rest (dh. der Teil ab dem 4. Schrägstrich) wird abgeschnitten. Bsp: Gardasil Zulassungsnummer EU/1/06/357/003-017,019-021 → EU/1/06/357
* '''Zulassungsstatus''' - z.B. zugelassen; Text des zum Zeitpunkt des Exports aktuellen GA Status der ASP; hier ist kein Codesystem hinterlegt
* '''Zulassungsinhaber''' - Name der Organisation mit Rolle = Inhaber vom GA ASP; hier ist kein Codesystem hinterlegt
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Für die e-Medikation werden nur Arzneimittel akzeptiert die den Wert "TRUE" tragen. Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen).
**Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar. Dieses Attribute wird beim Eintrag in die e-Medikation nicht berücksichtigt.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA Packaging''' (Datenquelle AGES) - Primärverpackung
**Code z.B. 1.2.40.0.34.5.219:100000073496 (OID des Codesystems "Medikation_Packaging":Code)
***Text z.B. "Blisterpackung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
**Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''Active Ingredient''' (Datenquelle AGES) - in englisch ausgegeben.
**Code z.B. 1.2.40.0.34.5.221:100000091410 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. MELPHALAN
* '''Ingredient Role''' (Datenquelle AGES) - Fixwert "active"
* '''Ingredient low strength''' (Datenquelle AGES) - Menge. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''Ingredient low strength unit''' (Datenquelle AGES) - Einheit. Wenn Menge, Einheit nicht verfügbar sind, werden die Meta-Attribute nur mit Anführungszeichen exportiert.
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft
Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

====Weitere Codesysteme der AGES====

Die ASP-Liste steht in direktem Zusammenhang mit einer Reihe an Terminologien. Diese Terminologien werden (wie oben beschrieben) als code/text-Attributpaar in der ASP-Liste referenziert:
* ATC
* Medikation_AGES_Wirkstoffe 1.2.40.0.34.5.156
** Liste an aktiven Wirkstoffen
** Quelle: EMA (European Medical Agency) /EUTCT (European Union Telematics Controlled Terms)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingungen EUTCT: The information concerning this list is reproduced from the EUTCT repository with permission of the EMA (European Medicines Agency).
* MedikationArtAnwendung 1.2.40.0.10.1.4.3.4.3.4
** Arten der Anwendung eines Medikaments, etwa „intramuskuläre Anwendung“ oder „Anwendung am Ohr“
** Quelle: EDQM (Europäisches Direktorat für die Qualität von Arzneimitteln)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingung EDQM: It is clearly stated that the data is from the EDQM Standard Terms database (http://standardterms.edqm.eu), and that it is reproduced with the permission of the European Directorate for the Quality of Medicines & HealthCare, Council of Europe (EDQM). The Standard Terms data is not modified, and no other data is represented as being part of Standard Terms. If any additional data is presented alongside, it must be clear that it does not originate from Standard Terms. The date on which the data was retrieved from the Standard Terms database is clearly stated, with a notice that the EDQM Standard Terms database is not a static list and content can change over time.
* MedikationDarreichungsform 1.2.40.0.10.1.4.3.4.3.5
** Darreichungsform des Medikaments, etwa „Filmtablette“ oder „Sirup“
** Quelle: EDQM (Europäisches Direktorat für die Qualität von Arzneimitteln)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingung EDQM: It is clearly stated that the data is from the EDQM Standard Terms database (http://standardterms.edqm.eu), and that it is reproduced with the permission of the European Directorate for the Quality of Medicines & HealthCare, Council of Europe (EDQM). The Standard Terms data is not modified, and no other data is represented as being part of Standard Terms. If any additional data is presented alongside, it must be clear that it does not originate from Standard Terms. The date on which the data was retrieved from the Standard Terms database is clearly stated, with a notice that the EDQM Standard Terms database is not a static list and content can change over time.

Weitere e-Medikation Codelisten
* MedikationsRezeptart 1.2.40.0.10.1.4.3.4.3.3
** Unterscheidung zwischen Kassen-, Privat- und Substitutionsrezept
** Nicht als Attribut in der ASP-Liste
** Quelle: Codes definiert im e-Medikationsprojekt
** Keine laufenden Änderungen vorgesehen
* MedikationRezeptpflichtstatus 1.2.40.0.10.1.4.3.4.3.7
** Unterscheidung zwischen „Arzneimittel zur Abgabe ohne aerztliche Verschreibung“ und „Arzneimittel zur Abgabe gegen aerztliche Verschreibung“
** Nicht als Attribut in der ASP-Liste
** Quelle: EMA (European Medical Agency) /EUTCT (European Union Telematics Controlled Terms)
** Bereitstellung durch AGES, keine laufenden Änderungen vorgesehen
** Nutzungsbedingungen: The information concerning this list is reproduced from the EUTCT repository with permission of the EMA (European Medicines Agency).
* MedikationTherapieart 1.2.40.0.10.1.4.3.4.3.6
** Unterscheidung zwischen Einzel, und Nicht-Einzelverordnung
** Nicht als Attribut in der ASP-Liste
** Quelle: Codes definiert im e-Medikationsprojekt
** Keine laufenden Änderungen vorgesehen

===Releasezyklus===
Die referenzierten Codesysteme werden von der AGES gepflegt und bei Änderungen werden diese mit dem monatlichen Import mitgeliefert.

[[Kategorie:Terminologieserver]]

ASP Liste

2023-07-13T07:22:12Z

Sjencic: /* ASP Liste (1.2.40.0.34.4.16) */

{{#customtitle:ASP Liste}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==ASP Liste (1.2.40.0.34.4.16)==
Liste der humanen Arzneispezialitäten gelistet nach PZN

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für die e-Medikation verwendbaren Medikamente bzw. Arzneimittelspezialitäten. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der ASP-Liste. In der ASP-Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

Anmerkung: Magistrale Zubereitungen werden als Freitextfeld zu Informationszwecken in e-Medikation übernommen und können optional mit [[ATC_deutsch_(WIdO)|ATC-Code]] versehen werden.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
AGES GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen
====Attribute der ASP-Liste====
Die AGES liefert dem e-Medikation System eine Liste der Arzneispezialitäten (ASP-Liste) zu. In dieser Datenbasis MÜSSEN (ausgenommen ATC-Code) folgende Datenfelder vorhanden sein:
* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - "Zulassungsname"
* '''DisplayName''' (Datenquelle APO-Verlag) - "Handelsname" Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamens (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES) - Seit dem Juni-Release 6.1.0 2021 wird bei EU-Zulassungsnummern nur der Teil bis inkl. Stärke verwendet, der Rest (dh. der Teil ab dem 4. Schrägstrich) wird abgeschnitten. Bsp: Gardasil Zulassungsnummer EU/1/06/357/003-017,019-021 → EU/1/06/357
* '''Zulassungsstatus''' - z.B. zugelassen; Text des zum Zeitpunkt des Exports aktuellen GA Status der ASP; hier ist kein Codesystem hinterlegt
* '''Zulassungsinhaber''' - Name der Organisation mit Rolle = Inhaber vom GA ASP; hier ist kein Codesystem hinterlegt
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Für die e-Medikation werden nur Arzneimittel akzeptiert die den Wert "TRUE" tragen. Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen).
**Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar. Dieses Attribute wird beim Eintrag in die e-Medikation nicht berücksichtigt.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA Packaging''' (Datenquelle AGES) - Primärverpackung
**Code z.B. 1.2.40.0.34.5.219:100000073496 (OID des Codesystems "Medikation_Packaging":Code)
***Text z.B. "Blisterpackung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
**Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''Active Ingredient''' (Datenquelle AGES) - in englisch ausgegeben.
**Code z.B. 1.2.40.0.34.5.221:100000091410 (OID des Codesystems "ELGA_ActiveIngredient":Code)
**Text z.B. MELPHALAN
* '''Ingredient Role''' (Datenquelle AGES) - Fixwert "active"
* '''Ingredient low strength'''
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft
Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

====Weitere Codesysteme der AGES====

Die ASP-Liste steht in direktem Zusammenhang mit einer Reihe an Terminologien. Diese Terminologien werden (wie oben beschrieben) als code/text-Attributpaar in der ASP-Liste referenziert:
* ATC
* Medikation_AGES_Wirkstoffe 1.2.40.0.34.5.156
** Liste an aktiven Wirkstoffen
** Quelle: EMA (European Medical Agency) /EUTCT (European Union Telematics Controlled Terms)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingungen EUTCT: The information concerning this list is reproduced from the EUTCT repository with permission of the EMA (European Medicines Agency).
* MedikationArtAnwendung 1.2.40.0.10.1.4.3.4.3.4
** Arten der Anwendung eines Medikaments, etwa „intramuskuläre Anwendung“ oder „Anwendung am Ohr“
** Quelle: EDQM (Europäisches Direktorat für die Qualität von Arzneimitteln)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingung EDQM: It is clearly stated that the data is from the EDQM Standard Terms database (http://standardterms.edqm.eu), and that it is reproduced with the permission of the European Directorate for the Quality of Medicines & HealthCare, Council of Europe (EDQM). The Standard Terms data is not modified, and no other data is represented as being part of Standard Terms. If any additional data is presented alongside, it must be clear that it does not originate from Standard Terms. The date on which the data was retrieved from the Standard Terms database is clearly stated, with a notice that the EDQM Standard Terms database is not a static list and content can change over time.
* MedikationDarreichungsform 1.2.40.0.10.1.4.3.4.3.5
** Darreichungsform des Medikaments, etwa „Filmtablette“ oder „Sirup“
** Quelle: EDQM (Europäisches Direktorat für die Qualität von Arzneimitteln)
** Wartung und Bereitstellung durch AGES GmbH
** Nutzungsbedingung EDQM: It is clearly stated that the data is from the EDQM Standard Terms database (http://standardterms.edqm.eu), and that it is reproduced with the permission of the European Directorate for the Quality of Medicines & HealthCare, Council of Europe (EDQM). The Standard Terms data is not modified, and no other data is represented as being part of Standard Terms. If any additional data is presented alongside, it must be clear that it does not originate from Standard Terms. The date on which the data was retrieved from the Standard Terms database is clearly stated, with a notice that the EDQM Standard Terms database is not a static list and content can change over time.

Weitere e-Medikation Codelisten
* MedikationsRezeptart 1.2.40.0.10.1.4.3.4.3.3
** Unterscheidung zwischen Kassen-, Privat- und Substitutionsrezept
** Nicht als Attribut in der ASP-Liste
** Quelle: Codes definiert im e-Medikationsprojekt
** Keine laufenden Änderungen vorgesehen
* MedikationRezeptpflichtstatus 1.2.40.0.10.1.4.3.4.3.7
** Unterscheidung zwischen „Arzneimittel zur Abgabe ohne aerztliche Verschreibung“ und „Arzneimittel zur Abgabe gegen aerztliche Verschreibung“
** Nicht als Attribut in der ASP-Liste
** Quelle: EMA (European Medical Agency) /EUTCT (European Union Telematics Controlled Terms)
** Bereitstellung durch AGES, keine laufenden Änderungen vorgesehen
** Nutzungsbedingungen: The information concerning this list is reproduced from the EUTCT repository with permission of the EMA (European Medicines Agency).
* MedikationTherapieart 1.2.40.0.10.1.4.3.4.3.6
** Unterscheidung zwischen Einzel, und Nicht-Einzelverordnung
** Nicht als Attribut in der ASP-Liste
** Quelle: Codes definiert im e-Medikationsprojekt
** Keine laufenden Änderungen vorgesehen

===Releasezyklus===
Die referenzierten Codesysteme werden von der AGES gepflegt und bei Änderungen werden diese mit dem monatlichen Import mitgeliefert.

[[Kategorie:Terminologieserver]]

ICD-O-3

2021-06-04T08:10:02Z

Sjencic:

{{#customtitle:ICD-O-3}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==ICD-O-3 (2.16.840.1.113883.6.43.1)==
Die International Classification of Diseases for Oncology (ICD-O) ist eine medizinische Klassifikation. Sie stellt eine Erweiterung der ICD-10 für die Onkologie dar und wird wie diese durch die Weltgesundheitsorganisation (WHO) gepflegt und weiterentwickelt. Die aktuelle Version ist die ICD-O-3 zweite Revision von 2019 (Deutsche Übersetzung Dezember 2020). Die deutsche Übersetzung der ICD-O wird wie die der ICD durch das Deutsche Institut für medizinische Dokumentation und Information (DIMDI) bereitgestellt.

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Kurzbeschreibung===
Das „Kapitel II Neubildungen“ der ICD-10 ist für die Klassierung von Tumorerkrankungen zum Beispiel in Krebsregistern nicht ausreichend genau, da sie zum Beispiel im Allgemeinen keine Aussage über den histologischen Typ einer Erkrankung erlaubt.

Deshalb wurde ein zweiachsiges System entwickelt. Die eine Achse bezeichnet den Sitz des Tumors (Topographieachse, im deutschen der Lokalisationsschlüssel), die andere das histologische Aussehen des Tumors (Morphologieachse, Histologieschlüssel).

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Terminologie Provider ===
Internationale Ausgabe: WHO
Deutsche Übersetzung: BfArM

===Inhaltsverwalter am österreichischen e-Health Terminologieserver===
ELGA GmbH

===Struktur===
Die Codes der Topographieachse entsprechen im Wesentlichen den Codes des Kapitels "Bösartige Neubildungen" der ICD.

Beispiele:

* ..
* C18.2 Colon ascendens
* C18.3 Flexura hepatica
* C18.4 Colon transversum
** C18.41 Colon transversum, rechtes Drittel (deutsche Erweiterung des Topographieteils)
** C18.42 Colon transversum, mittleres Drittel
** ...
* ..
Die Codes der Morphologieachse sind auch im Morphologieteil des SNOMED enthalten und folgendermaßen aufgebaut:

_ _ _ _ / _ : Grundform des Tumors/Dignität (Bösartigkeit)

Beispiele:

* 8140/0 Adenom o.n.A. (gutartiger Tumor)
* 8140/1 Atypisches Adenom (unsicheres Verhalten, also weder vollständig gutartig noch vollständig bösartig)
* 8140/2 Adenocarcinoma in situ o.n.A. (oberflächlicher, noch nicht infiltrierender Tumor)
* 8140/3 Adenokarzinom o.n.A. (infiltrierender Tumor)
* 8140/6 Adenokarzinommetastase
* 8140/9 Unsicher, ob primäres Adenokarzinom oder Adenokarzinommetastase

Aus Lokalisations- und Histologieschlüssel kann meistens der ICD-10-Code gebildet werden.

Beispiele:

{| class="wikitable"
!Lokalisation
!Histologie
!ICD-10
|-
|C18.2
|8140/0
|D12.2
|-
|C18.2
|8140/1
|D37.4
|-
|C18.2
|8140/2
|D01.0
|-
|C18.2
|8140/3
|C18.2
|}

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Releasezyklus===
Bei Neuerscheinung einer aktualisierten deutschen Übersetzung

[[Kategorie:Terminologieserver]]

ICF

2021-06-04T08:09:43Z

Sjencic:

{{#customtitle:ICF}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==ICF (2.16.840.1.113883.6.254-2005)==
Die International Classification of Functioning, Disability and Health (ICF) ist eine Klassifikation von der Weltgesundheitsorganisation, die erstmals 2001 erstellt und herausgegeben wurde. In deutscher Übersetzung liegt sie unter dem Titel „Internationale Klassifikation der Funktionsfähigkeit, Behinderung und Gesundheit“ vor.

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

===Kurzbeschreibung===
Mit Hilfe der ICF kann die aktuelle Funktionsfähigkeit jedes Menschen (oder ihre Beeinträchtigung) beschrieben und klassifiziert werden. Beschrieben wird der Gesundheitszustand und die mit dem Gesundheitszustand verbundenen Zustände. Die ICF „klassifiziert nicht Personen“; die Beschreibung einer Behinderung bezieht sich explizit sowohl auf den Körper einer Person als auch auf die spezifische Situation, z. B. einen bestimmten Arbeitsplatz, den aktuellen Wohnort oder die häusliche Umgebung, wo die funktionalen Behinderungen einer Person sichtbar werden.

Entgegen einem weitverbreiteten Missverständnis ist die ICF nicht nur auf Menschen mit Behinderung anwendbar. Sie kann vielmehr auf jede Person angewendet werden. Die ICF deckt jedoch keine Umstände ab, die nicht mit der Gesundheit in Verbindung stehen. Besteht eine Beeinträchtigung der Partizipation (Teilhabe) aus anderen Gründen, z. B. der Geschlechtszugehörigkeit, sozioökonomischen oder ethnischen Gründen, ist die ICF nicht anwendbar.

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

===Terminologie Provider ===
Internationale Ausgabe: WHO
Deutsche Übersetzung: BfArM

===Inhaltsverwalter am österreichischen e-Health Terminologieserver===
ELGA GmbH

===Struktur===
Die ICF ist in zwei Teile gegliedert, von denen jeder wiederum zwei Komponenten hat:

====Funktionsfähigkeit und Behinderung====
Beschrieben wird die Funktionsfähigkeit oder Behinderung in folgenden Bereichen:

'''Körper'''

Dieser Bereich bezieht sich auf den menschlichen Organismus als Ganzes, also auch auf das Gehirn und seine (geistigen und seelischen) Funktionen. Es wird unterschieden zwischen:

* ''Körperfunktionen'', d. h. die physiologischen Funktionen von Körpersystemen (einschließlich psychologischer Funktionen). Beschrieben wird die Veränderung physiologischer Strukturen (z. B. der Sehfähigkeit).
* ''Körperstrukturen'', d. h. anatomische Teile des Körpers, wie Organe, Gliedmaßen und ihre Bestandteile. Beschrieben wird die Veränderung anatomischer Strukturen (z. B. am Auge).
Es kann jeweils eine funktionale und strukturelle Integrität oder eine Schädigung (Beeinträchtigung einer Körperfunktion oder -struktur, wie z. B. eine wesentliche Abweichung oder ein Verlust) beschrieben werden. Die Schädigungen werden hinsichtlich ihrer Abweichung von der Populationsnorm beschrieben (fünfstufige Skala von "nicht vorhanden" bis "voll ausgeprägt"). Eine Schädigung bezeichnet nicht notwendigerweise eine Krankheit, d. h. der Begriff ist weiter gefasst. Auch Ursache und Entwicklung der Schädigung wird hier nicht berücksichtigt.

'''Aktivitäten und Partizipation (Teilhabe)'''

Hier geht es um Aspekte der Funktionsfähigkeit (Leistungsfähigkeit) aus individueller und gesellschaftlicher Perspektive. Beschrieben wird das Vorhandensein oder die Abwesenheit von Beeinträchtigungen, die bei der Durchführung einer Aufgabe oder Handlung (Aktivität) oder dem Eingebundensein in eine Lebenssituation (Partizipation bzw. Teilhabe) erlebt werden. In der ICF werden folgende Bereiche beschrieben:

* Lernen und Wissensanwendung
* Allgemeine Aufgaben und Anforderungen
* Kommunikation
* Mobilität
* Selbstversorgung
* Häusliches Leben
* Interpersonelle Interaktion und Beziehungen
* Bedeutende Lebensbereiche (Erziehung, Arbeit und Beschäftigung, Wirtschaftliches Leben)
* Gemeinschafts-, soziales und staatsbürgerliches Leben

Für jeden Bereich wurden Beurteilungsmerkmale festgelegt, die jeweils hinsichtlich der Konstrukte Leistung (Durchführung von Aufgaben in der gegenwärtigen, tatsächlichen Welt) und Leistungsfähigkeit (Kapazität, höchstmögliches Funktionsniveau in einer standardisierten Umwelt, z. B. Test) auf einer fünfstufigen Skala eingeschätzt werden ("Problem nicht vorhanden" bis "Problem voll ausgeprägt"). Eine Diskrepanz ist Anhaltspunkt für den Einfluss von Umweltfaktoren (z. B. wenn ein HIV-Kranker aufgrund der sozialen Stigmatisierung nicht arbeiten kann, obwohl er keine Schädigung aufweist und voll leistungsfähig ist).

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

====Kontextfaktoren====
'''Umweltfaktoren'''

Beschrieben werden hier äußere Einflüsse auf Funktionsfähigkeit und Behinderung. Das ICF liefert eine umfassende Liste von Umweltfaktoren, die nach Bereichen gegliedert und jeweils nach der Nähe zum Individuum (unmittelbare Umwelt bis entferntere Umwelt) geordnet sind. Die in der ICF klassifizierten Bereiche sind:

* Produkte und Technologien
* Natürliche und vom Menschen veränderte Umwelt
* Unterstützung und Beziehungen
* Einstellungen
* Dienste, Systeme und Handlungsgrundsätze
Für jeden Umweltfaktor soll (auf einer fünfstufigen Skala von "nicht vorhanden" bis "voll ausgeprägt") angegeben werden, inwieweit er eine Barriere oder ein Förderfaktor aus Sicht des Individuums ist.

'''Personbezogene Faktoren'''

Hier sollen "innere" Einflüsse auf Funktionsfähigkeit und Behinderung beschrieben werden, d. h. Einflüsse von Merkmalen der Person, die selbst nicht Teil des Gesundheitsproblems oder -zustands sind (z. B. Geschlecht, ethnische Zugehörigkeit, Alter, andere Gesundheitsprobleme, Fitness, Lebensstil, Gewohnheiten, Erziehung, Bewältigungsstile, sozialer Hintergrund, Bildung und Ausbildung, Beruf sowie vergangene oder gegenwärtige Erfahrungen/Ereignisse, allgemeine Verhaltensmuster und Charakter, individuelles psychisches Leistungsvermögen).

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

===Releasezyklus===
Bei Neuerscheinung einer aktualisierten deutschen Übersetzung

[[Kategorie:Terminologieserver]]

ICD-O-3

2021-06-04T08:07:37Z

Sjencic:

{{#customtitle:ICD-O-3}}

==ICD-O-3 (2.16.840.1.113883.6.43.1)==
Die International Classification of Diseases for Oncology (ICD-O) ist eine medizinische Klassifikation. Sie stellt eine Erweiterung der ICD-10 für die Onkologie dar und wird wie diese durch die Weltgesundheitsorganisation (WHO) gepflegt und weiterentwickelt. Die aktuelle Version ist die ICD-O-3 zweite Revision von 2019 (Deutsche Übersetzung Dezember 2020). Die deutsche Übersetzung der ICD-O wird wie die der ICD durch das Deutsche Institut für medizinische Dokumentation und Information (DIMDI) bereitgestellt.

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Kurzbeschreibung===
Das „Kapitel II Neubildungen“ der ICD-10 ist für die Klassierung von Tumorerkrankungen zum Beispiel in Krebsregistern nicht ausreichend genau, da sie zum Beispiel im Allgemeinen keine Aussage über den histologischen Typ einer Erkrankung erlaubt.

Deshalb wurde ein zweiachsiges System entwickelt. Die eine Achse bezeichnet den Sitz des Tumors (Topographieachse, im deutschen der Lokalisationsschlüssel), die andere das histologische Aussehen des Tumors (Morphologieachse, Histologieschlüssel).

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Terminologie Provider ===
Internationale Ausgabe: WHO
Deutsche Übersetzung: BfArM

===Inhaltsverwalter am österreichischen e-Health Terminologieserver===
ELGA GmbH

===Struktur===
Die Codes der Topographieachse entsprechen im Wesentlichen den Codes des Kapitels "Bösartige Neubildungen" der ICD.

Beispiele:

* ..
* C18.2 Colon ascendens
* C18.3 Flexura hepatica
* C18.4 Colon transversum
** C18.41 Colon transversum, rechtes Drittel (deutsche Erweiterung des Topographieteils)
** C18.42 Colon transversum, mittleres Drittel
** ...
* ..
Die Codes der Morphologieachse sind auch im Morphologieteil des SNOMED enthalten und folgendermaßen aufgebaut:

_ _ _ _ / _ : Grundform des Tumors/Dignität (Bösartigkeit)

Beispiele:

* 8140/0 Adenom o.n.A. (gutartiger Tumor)
* 8140/1 Atypisches Adenom (unsicheres Verhalten, also weder vollständig gutartig noch vollständig bösartig)
* 8140/2 Adenocarcinoma in situ o.n.A. (oberflächlicher, noch nicht infiltrierender Tumor)
* 8140/3 Adenokarzinom o.n.A. (infiltrierender Tumor)
* 8140/6 Adenokarzinommetastase
* 8140/9 Unsicher, ob primäres Adenokarzinom oder Adenokarzinommetastase

Aus Lokalisations- und Histologieschlüssel kann meistens der ICD-10-Code gebildet werden.

Beispiele:

{| class="wikitable"
!Lokalisation
!Histologie
!ICD-10
|-
|C18.2
|8140/0
|D12.2
|-
|C18.2
|8140/1
|D37.4
|-
|C18.2
|8140/2
|D01.0
|-
|C18.2
|8140/3
|C18.2
|}

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Releasezyklus===
Bei Neuerscheinung einer aktualisierten deutschen Übersetzung

[[Kategorie:Terminologieserver]]

ICD-O-3

2021-06-04T07:01:28Z

Sjencic:

{{#customtitle:ICF}}

==ICD-O-3 (2.16.840.1.113883.6.43.1)==
Die International Classification of Diseases for Oncology (ICD-O) ist eine medizinische Klassifikation. Sie stellt eine Erweiterung der ICD-10 für die Onkologie dar und wird wie diese durch die Weltgesundheitsorganisation (WHO) gepflegt und weiterentwickelt. Die aktuelle Version ist die ICD-O-3 zweite Revision von 2019 (Deutsche Übersetzung Dezember 2020). Die deutsche Übersetzung der ICD-O wird wie die der ICD durch das Deutsche Institut für medizinische Dokumentation und Information (DIMDI) bereitgestellt.

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Kurzbeschreibung===
Das „Kapitel II Neubildungen“ der ICD-10 ist für die Klassierung von Tumorerkrankungen zum Beispiel in Krebsregistern nicht ausreichend genau, da sie zum Beispiel im Allgemeinen keine Aussage über den histologischen Typ einer Erkrankung erlaubt.

Deshalb wurde ein zweiachsiges System entwickelt. Die eine Achse bezeichnet den Sitz des Tumors (Topographieachse, im deutschen der Lokalisationsschlüssel), die andere das histologische Aussehen des Tumors (Morphologieachse, Histologieschlüssel).

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Terminologie Provider ===
Internationale Ausgabe: WHO
Deutsche Übersetzung: BfArM

===Inhaltsverwalter am österreichischen e-Health Terminologieserver===
ELGA GmbH

===Struktur===
Die Codes der Topographieachse entsprechen im Wesentlichen den Codes des Kapitels "Bösartige Neubildungen" der ICD.

Beispiele:

* ..
* C18.2 Colon ascendens
* C18.3 Flexura hepatica
* C18.4 Colon transversum
** C18.41 Colon transversum, rechtes Drittel (deutsche Erweiterung des Topographieteils)
** C18.42 Colon transversum, mittleres Drittel
** ...
* ..
Die Codes der Morphologieachse sind auch im Morphologieteil des SNOMED enthalten und folgendermaßen aufgebaut:

_ _ _ _ / _ : Grundform des Tumors/Dignität (Bösartigkeit)

Beispiele:

* 8140/0 Adenom o.n.A. (gutartiger Tumor)
* 8140/1 Atypisches Adenom (unsicheres Verhalten, also weder vollständig gutartig noch vollständig bösartig)
* 8140/2 Adenocarcinoma in situ o.n.A. (oberflächlicher, noch nicht infiltrierender Tumor)
* 8140/3 Adenokarzinom o.n.A. (infiltrierender Tumor)
* 8140/6 Adenokarzinommetastase
* 8140/9 Unsicher, ob primäres Adenokarzinom oder Adenokarzinommetastase

Aus Lokalisations- und Histologieschlüssel kann meistens der ICD-10-Code gebildet werden.

Beispiele:

{| class="wikitable"
!Lokalisation
!Histologie
!ICD-10
|-
|C18.2
|8140/0
|D12.2
|-
|C18.2
|8140/1
|D37.4
|-
|C18.2
|8140/2
|D01.0
|-
|C18.2
|8140/3
|C18.2
|}

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Releasezyklus===
Bei Neuerscheinung einer aktualisierten deutschen Übersetzung

[[Kategorie:Terminologieserver]]

ICD-O-3

2021-06-04T07:00:27Z

Sjencic:

{{#customtitle:ICF}}

==ICD-O-3 (2.16.840.1.113883.6.43.1)==
Die International Classification of Diseases for Oncology (ICD-O) ist eine medizinische Klassifikation. Sie stellt eine Erweiterung der ICD-10 für die Onkologie dar und wird wie diese durch die Weltgesundheitsorganisation (WHO) gepflegt und weiterentwickelt. Die aktuelle Version ist die ICD-O-3 zweite Revision von 2019 (Deutsche Übersetzung Dezember 2020). Die deutsche Übersetzung der ICD-O wird wie die der ICD durch das Deutsche Institut für medizinische Dokumentation und Information (DIMDI) bereitgestellt.

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Kurzbeschreibung===
Das „Kapitel II Neubildungen“ der ICD-10 ist für die Klassierung von Tumorerkrankungen zum Beispiel in Krebsregistern nicht ausreichend genau, da sie zum Beispiel im Allgemeinen keine Aussage über den histologischen Typ einer Erkrankung erlaubt.

Deshalb wurde ein zweiachsiges System entwickelt. Die eine Achse bezeichnet den Sitz des Tumors (Topographieachse, im deutschen der Lokalisationsschlüssel), die andere das histologische Aussehen des Tumors (Morphologieachse, Histologieschlüssel).

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Terminologie Provider ===
Internationale Ausgabe: WHO
Deutsche Übersetzung: BfArM

===Inhaltsverwalter am österreichischen e-Health Terminologieserver===
ELGA GmbH

===Struktur===
Die Codes der Topographieachse entsprechen im Wesentlichen den Codes des Kapitels "Bösartige Neubildungen" der ICD.

Beispiele:

* ..
* C18.2 Colon ascendens
* C18.3 Flexura hepatica
* C18.4 Colon transversum
** C18.41 Colon transversum, rechtes Drittel (deutsche Erweiterung des Topographieteils)
** C18.42 Colon transversum, mittleres Drittel
** ...
* ..
Die Codes der Morphologieachse sind auch im Morphologieteil des SNOMED enthalten und folgendermaßen aufgebaut:

_ _ _ _ / _ : Grundform des Tumors/Dignität (Bösartigkeit)

Beispiele:

* 8140/0 Adenom o.n.A. (gutartiger Tumor)
* 8140/1 Atypisches Adenom (unsicheres Verhalten, also weder vollständig gutartig noch vollständig bösartig)
* 8140/2 Adenocarcinoma in situ o.n.A. (oberflächlicher, noch nicht infiltrierender Tumor)
* 8140/3 Adenokarzinom o.n.A. (infiltrierender Tumor)
* 8140/6 Adenokarzinommetastase
* 8140/9 Unsicher, ob primäres Adenokarzinom oder Adenokarzinommetastase

Aus Lokalisations- und Histologieschlüssel kann meistens der ICD-10-Code gebildet werden.

Beispiele:

{| class="wikitable"
!Lokalisation
!Histologie
!ICD-10
|-
|C18.2
|8140/0
|D12.2
|-
|C18.2
|8140/1
|D37.4
|-
|C18.2
|8140/2
|D01.0
|-
|C18.2
|8140/3
|C18.2
|}

===Releasezyklus===
Bei Neuerscheinung einer aktualisierten deutschen Übersetzung

[[Kategorie:Terminologieserver]]

ICD-O-3

2021-06-04T06:38:58Z

Sjencic: Die Seite wurde neu angelegt: „{{#customtitle:ICF}} ==ICD-O-3 (2.16.840.1.113883.6.43.1)== Die International Classification of Diseases for Oncology (ICD-O) ist eine medizinische Klassifika…“

{{#customtitle:ICF}}

==ICD-O-3 (2.16.840.1.113883.6.43.1)==
Die International Classification of Diseases for Oncology (ICD-O) ist eine medizinische Klassifikation. Sie stellt eine Erweiterung der ICD-10 für die Onkologie dar und wird wie diese durch die Weltgesundheitsorganisation (WHO) gepflegt und weiterentwickelt. Die aktuelle Version ist die ICD-O-3 zweite Revision von 2019 (Deutsche Übersetzung Dezember 2020).

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Kurzbeschreibung===
Das „Kapitel II Neubildungen“ der ICD-10 ist für die Klassierung von Tumorerkrankungen zum Beispiel in Krebsregistern nicht ausreichend genau, da sie zum Beispiel im Allgemeinen keine Aussage über den histologischen Typ einer Erkrankung erlaubt.

Deshalb wurde ein zweiachsiges System entwickelt. Die eine Achse bezeichnet den Sitz des Tumors (Topographieachse, im deutschen der Lokalisationsschlüssel), die andere das histologische Aussehen des Tumors (Morphologieachse, Histologieschlüssel).

Quelle: International Classification of Diseases for Oncology [https://de.wikipedia.org/wiki/International_Classification_of_Diseases_for_Oncology] abgerufen am 04.06.2021

===Terminologie Provider ===
Internationale Ausgabe: WHO
Deutsche Übersetzung: BfArM

===Inhaltsverwalter am österreichischen e-Health Terminologieserver===
ELGA GmbH

===Struktur===
Die Codes der Topographieachse entsprechen im Wesentlichen den Codes des Kapitels "Bösartige Neubildungen" der ICD.

Beispiele:

..
C18.2 Colon ascendens
C18.3 Flexura hepatica
C18.4 Colon transversum
C18.41 Colon transversum, rechtes Drittel (deutsche Erweiterung des Topographieteils)
C18.42 Colon transversum, mittleres Drittel
...
..
Die Codes der Morphologieachse sind auch im Morphologieteil des SNOMED enthalten und folgendermaßen aufgebaut:

_ _ _ _ / _ : Grundform des Tumors/Dignität (Bösartigkeit)

Beispiele:

8140/0 Adenom o.n.A. (gutartiger Tumor)
8140/1 Atypisches Adenom (unsicheres Verhalten, also weder vollständig gutartig noch vollständig bösartig)
8140/2 Adenocarcinoma in situ o.n.A. (oberflächlicher, noch nicht infiltrierender Tumor)
8140/3 Adenokarzinom o.n.A. (infiltrierender Tumor)
8140/6 Adenokarzinommetastase
8140/9 Unsicher, ob primäres Adenokarzinom oder Adenokarzinommetastase
Aus Lokalisations- und Histologieschlüssel kann meistens der ICD-10-Code gebildet werden.
Beispiele:

[[Kategorie:Terminologieserver]]

ICF

2021-06-04T05:23:56Z

Sjencic:

{{#customtitle:ICF}}

==ICF (2.16.840.1.113883.6.254-2005)==
Die International Classification of Functioning, Disability and Health (ICF) ist eine Klassifikation von der Weltgesundheitsorganisation, die erstmals 2001 erstellt und herausgegeben wurde. In deutscher Übersetzung liegt sie unter dem Titel „Internationale Klassifikation der Funktionsfähigkeit, Behinderung und Gesundheit“ vor.

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

===Kurzbeschreibung===
Mit Hilfe der ICF kann die aktuelle Funktionsfähigkeit jedes Menschen (oder ihre Beeinträchtigung) beschrieben und klassifiziert werden. Beschrieben wird der Gesundheitszustand und die mit dem Gesundheitszustand verbundenen Zustände. Die ICF „klassifiziert nicht Personen“; die Beschreibung einer Behinderung bezieht sich explizit sowohl auf den Körper einer Person als auch auf die spezifische Situation, z. B. einen bestimmten Arbeitsplatz, den aktuellen Wohnort oder die häusliche Umgebung, wo die funktionalen Behinderungen einer Person sichtbar werden.

Entgegen einem weitverbreiteten Missverständnis ist die ICF nicht nur auf Menschen mit Behinderung anwendbar. Sie kann vielmehr auf jede Person angewendet werden. Die ICF deckt jedoch keine Umstände ab, die nicht mit der Gesundheit in Verbindung stehen. Besteht eine Beeinträchtigung der Partizipation (Teilhabe) aus anderen Gründen, z. B. der Geschlechtszugehörigkeit, sozioökonomischen oder ethnischen Gründen, ist die ICF nicht anwendbar.

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

===Terminologie Provider ===
Internationale Ausgabe: WHO
Deutsche Übersetzung: BfArM

===Inhaltsverwalter am österreichischen e-Health Terminologieserver===
ELGA GmbH

===Struktur===
Die ICF ist in zwei Teile gegliedert, von denen jeder wiederum zwei Komponenten hat:

====Funktionsfähigkeit und Behinderung====
Beschrieben wird die Funktionsfähigkeit oder Behinderung in folgenden Bereichen:

'''Körper'''

Dieser Bereich bezieht sich auf den menschlichen Organismus als Ganzes, also auch auf das Gehirn und seine (geistigen und seelischen) Funktionen. Es wird unterschieden zwischen:

* ''Körperfunktionen'', d. h. die physiologischen Funktionen von Körpersystemen (einschließlich psychologischer Funktionen). Beschrieben wird die Veränderung physiologischer Strukturen (z. B. der Sehfähigkeit).
* ''Körperstrukturen'', d. h. anatomische Teile des Körpers, wie Organe, Gliedmaßen und ihre Bestandteile. Beschrieben wird die Veränderung anatomischer Strukturen (z. B. am Auge).
Es kann jeweils eine funktionale und strukturelle Integrität oder eine Schädigung (Beeinträchtigung einer Körperfunktion oder -struktur, wie z. B. eine wesentliche Abweichung oder ein Verlust) beschrieben werden. Die Schädigungen werden hinsichtlich ihrer Abweichung von der Populationsnorm beschrieben (fünfstufige Skala von "nicht vorhanden" bis "voll ausgeprägt"). Eine Schädigung bezeichnet nicht notwendigerweise eine Krankheit, d. h. der Begriff ist weiter gefasst. Auch Ursache und Entwicklung der Schädigung wird hier nicht berücksichtigt.

'''Aktivitäten und Partizipation (Teilhabe)'''

Hier geht es um Aspekte der Funktionsfähigkeit (Leistungsfähigkeit) aus individueller und gesellschaftlicher Perspektive. Beschrieben wird das Vorhandensein oder die Abwesenheit von Beeinträchtigungen, die bei der Durchführung einer Aufgabe oder Handlung (Aktivität) oder dem Eingebundensein in eine Lebenssituation (Partizipation bzw. Teilhabe) erlebt werden. In der ICF werden folgende Bereiche beschrieben:

* Lernen und Wissensanwendung
* Allgemeine Aufgaben und Anforderungen
* Kommunikation
* Mobilität
* Selbstversorgung
* Häusliches Leben
* Interpersonelle Interaktion und Beziehungen
* Bedeutende Lebensbereiche (Erziehung, Arbeit und Beschäftigung, Wirtschaftliches Leben)
* Gemeinschafts-, soziales und staatsbürgerliches Leben

Für jeden Bereich wurden Beurteilungsmerkmale festgelegt, die jeweils hinsichtlich der Konstrukte Leistung (Durchführung von Aufgaben in der gegenwärtigen, tatsächlichen Welt) und Leistungsfähigkeit (Kapazität, höchstmögliches Funktionsniveau in einer standardisierten Umwelt, z. B. Test) auf einer fünfstufigen Skala eingeschätzt werden ("Problem nicht vorhanden" bis "Problem voll ausgeprägt"). Eine Diskrepanz ist Anhaltspunkt für den Einfluss von Umweltfaktoren (z. B. wenn ein HIV-Kranker aufgrund der sozialen Stigmatisierung nicht arbeiten kann, obwohl er keine Schädigung aufweist und voll leistungsfähig ist).

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

====Kontextfaktoren====
'''Umweltfaktoren'''

Beschrieben werden hier äußere Einflüsse auf Funktionsfähigkeit und Behinderung. Das ICF liefert eine umfassende Liste von Umweltfaktoren, die nach Bereichen gegliedert und jeweils nach der Nähe zum Individuum (unmittelbare Umwelt bis entferntere Umwelt) geordnet sind. Die in der ICF klassifizierten Bereiche sind:

* Produkte und Technologien
* Natürliche und vom Menschen veränderte Umwelt
* Unterstützung und Beziehungen
* Einstellungen
* Dienste, Systeme und Handlungsgrundsätze
Für jeden Umweltfaktor soll (auf einer fünfstufigen Skala von "nicht vorhanden" bis "voll ausgeprägt") angegeben werden, inwieweit er eine Barriere oder ein Förderfaktor aus Sicht des Individuums ist.

'''Personbezogene Faktoren'''

Hier sollen "innere" Einflüsse auf Funktionsfähigkeit und Behinderung beschrieben werden, d. h. Einflüsse von Merkmalen der Person, die selbst nicht Teil des Gesundheitsproblems oder -zustands sind (z. B. Geschlecht, ethnische Zugehörigkeit, Alter, andere Gesundheitsprobleme, Fitness, Lebensstil, Gewohnheiten, Erziehung, Bewältigungsstile, sozialer Hintergrund, Bildung und Ausbildung, Beruf sowie vergangene oder gegenwärtige Erfahrungen/Ereignisse, allgemeine Verhaltensmuster und Charakter, individuelles psychisches Leistungsvermögen).

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

===Releasezyklus===
Bei Neuerscheinung einer aktualisierten deutschen Übersetzung

[[Kategorie:Terminologieserver]]

ICF

2021-06-04T05:23:26Z

Sjencic: /* Funktionsfähigkeit und Behinderung */

{{#customtitle:ICF}}

==ICF (2.16.840.1.113883.6.254-2005)==
Die International Classification of Functioning, Disability and Health (ICF) ist eine Klassifikation von der Weltgesundheitsorganisation, die erstmals 2001 erstellt und herausgegeben wurde. In deutscher Übersetzung liegt sie unter dem Titel „Internationale Klassifikation der Funktionsfähigkeit, Behinderung und Gesundheit“ vor.

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

===Kurzbeschreibung===
Mit Hilfe der ICF kann die aktuelle Funktionsfähigkeit jedes Menschen (oder ihre Beeinträchtigung) beschrieben und klassifiziert werden. Beschrieben wird der Gesundheitszustand und die mit dem Gesundheitszustand verbundenen Zustände. Die ICF „klassifiziert nicht Personen“; die Beschreibung einer Behinderung bezieht sich explizit sowohl auf den Körper einer Person als auch auf die spezifische Situation, z. B. einen bestimmten Arbeitsplatz, den aktuellen Wohnort oder die häusliche Umgebung, wo die funktionalen Behinderungen einer Person sichtbar werden.

Entgegen einem weitverbreiteten Missverständnis ist die ICF nicht nur auf Menschen mit Behinderung anwendbar. Sie kann vielmehr auf jede Person angewendet werden. Die ICF deckt jedoch keine Umstände ab, die nicht mit der Gesundheit in Verbindung stehen. Besteht eine Beeinträchtigung der Partizipation (Teilhabe) aus anderen Gründen, z. B. der Geschlechtszugehörigkeit, sozioökonomischen oder ethnischen Gründen, ist die ICF nicht anwendbar.

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

===Terminologie Provider ===
Internationale Ausgabe: WHO
Deutsche Übersetzung: BfArM

===Inhaltsverwalter am österreichischen e-Health Terminologieserver===
ELGA GmbH

===Struktur===
Die ICF ist in zwei Teile gegliedert, von denen jeder wiederum zwei Komponenten hat:

====Funktionsfähigkeit und Behinderung====
Beschrieben wird die Funktionsfähigkeit oder Behinderung in folgenden Bereichen:

'''Körper'''

Dieser Bereich bezieht sich auf den menschlichen Organismus als Ganzes, also auch auf das Gehirn und seine (geistigen und seelischen) Funktionen. Es wird unterschieden zwischen:

* ''Körperfunktionen'', d. h. die physiologischen Funktionen von Körpersystemen (einschließlich psychologischer Funktionen). Beschrieben wird die Veränderung physiologischer Strukturen (z. B. der Sehfähigkeit).
* ''Körperstrukturen'', d. h. anatomische Teile des Körpers, wie Organe, Gliedmaßen und ihre Bestandteile. Beschrieben wird die Veränderung anatomischer Strukturen (z. B. am Auge).
Es kann jeweils eine funktionale und strukturelle Integrität oder eine Schädigung (Beeinträchtigung einer Körperfunktion oder -struktur, wie z. B. eine wesentliche Abweichung oder ein Verlust) beschrieben werden. Die Schädigungen werden hinsichtlich ihrer Abweichung von der Populationsnorm beschrieben (fünfstufige Skala von "nicht vorhanden" bis "voll ausgeprägt"). Eine Schädigung bezeichnet nicht notwendigerweise eine Krankheit, d. h. der Begriff ist weiter gefasst. Auch Ursache und Entwicklung der Schädigung wird hier nicht berücksichtigt.

'''Aktivitäten und Partizipation (Teilhabe)'''

Hier geht es um Aspekte der Funktionsfähigkeit (Leistungsfähigkeit) aus individueller und gesellschaftlicher Perspektive. Beschrieben wird das Vorhandensein oder die Abwesenheit von Beeinträchtigungen, die bei der Durchführung einer Aufgabe oder Handlung (Aktivität) oder dem Eingebundensein in eine Lebenssituation (Partizipation bzw. Teilhabe) erlebt werden. In der ICF werden folgende Bereiche beschrieben:

* Lernen und Wissensanwendung
* Allgemeine Aufgaben und Anforderungen
* Kommunikation
* Mobilität
* Selbstversorgung
* Häusliches Leben
* Interpersonelle Interaktion und Beziehungen
* Bedeutende Lebensbereiche (Erziehung, Arbeit und Beschäftigung, Wirtschaftliches Leben)
* Gemeinschafts-, soziales und staatsbürgerliches Leben

Für jeden Bereich wurden Beurteilungsmerkmale festgelegt, die jeweils hinsichtlich der Konstrukte Leistung (Durchführung von Aufgaben in der gegenwärtigen, tatsächlichen Welt) und Leistungsfähigkeit (Kapazität, höchstmögliches Funktionsniveau in einer standardisierten Umwelt, z. B. Test) auf einer fünfstufigen Skala eingeschätzt werden ("Problem nicht vorhanden" bis "Problem voll ausgeprägt"). Eine Diskrepanz ist Anhaltspunkt für den Einfluss von Umweltfaktoren (z. B. wenn ein HIV-Kranker aufgrund der sozialen Stigmatisierung nicht arbeiten kann, obwohl er keine Schädigung aufweist und voll leistungsfähig ist).

====Kontextfaktoren====
'''Umweltfaktoren'''
Beschrieben werden hier äußere Einflüsse auf Funktionsfähigkeit und Behinderung. Das ICF liefert eine umfassende Liste von Umweltfaktoren, die nach Bereichen gegliedert und jeweils nach der Nähe zum Individuum (unmittelbare Umwelt bis entferntere Umwelt) geordnet sind. Die in der ICF klassifizierten Bereiche sind:

* Produkte und Technologien
* Natürliche und vom Menschen veränderte Umwelt
* Unterstützung und Beziehungen
* Einstellungen
* Dienste, Systeme und Handlungsgrundsätze
Für jeden Umweltfaktor soll (auf einer fünfstufigen Skala von "nicht vorhanden" bis "voll ausgeprägt") angegeben werden, inwieweit er eine Barriere oder ein Förderfaktor aus Sicht des Individuums ist.

'''Personbezogene Faktoren'''
Hier sollen "innere" Einflüsse auf Funktionsfähigkeit und Behinderung beschrieben werden, d. h. Einflüsse von Merkmalen der Person, die selbst nicht Teil des Gesundheitsproblems oder -zustands sind (z. B. Geschlecht, ethnische Zugehörigkeit, Alter, andere Gesundheitsprobleme, Fitness, Lebensstil, Gewohnheiten, Erziehung, Bewältigungsstile, sozialer Hintergrund, Bildung und Ausbildung, Beruf sowie vergangene oder gegenwärtige Erfahrungen/Ereignisse, allgemeine Verhaltensmuster und Charakter, individuelles psychisches Leistungsvermögen).

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

===Releasezyklus===
Bei Neuerscheinung einer aktualisierten deutschen Übersetzung

[[Kategorie:Terminologieserver]]

ICF

2021-06-04T05:22:41Z

Sjencic: Die Seite wurde neu angelegt: „{{#customtitle:ICF}} ==ICF (2.16.840.1.113883.6.254-2005)== Die International Classification of Functioning, Disability and Health (ICF) ist eine Klassifikati…“

{{#customtitle:ICF}}

==ICF (2.16.840.1.113883.6.254-2005)==
Die International Classification of Functioning, Disability and Health (ICF) ist eine Klassifikation von der Weltgesundheitsorganisation, die erstmals 2001 erstellt und herausgegeben wurde. In deutscher Übersetzung liegt sie unter dem Titel „Internationale Klassifikation der Funktionsfähigkeit, Behinderung und Gesundheit“ vor.

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

===Kurzbeschreibung===
Mit Hilfe der ICF kann die aktuelle Funktionsfähigkeit jedes Menschen (oder ihre Beeinträchtigung) beschrieben und klassifiziert werden. Beschrieben wird der Gesundheitszustand und die mit dem Gesundheitszustand verbundenen Zustände. Die ICF „klassifiziert nicht Personen“; die Beschreibung einer Behinderung bezieht sich explizit sowohl auf den Körper einer Person als auch auf die spezifische Situation, z. B. einen bestimmten Arbeitsplatz, den aktuellen Wohnort oder die häusliche Umgebung, wo die funktionalen Behinderungen einer Person sichtbar werden.

Entgegen einem weitverbreiteten Missverständnis ist die ICF nicht nur auf Menschen mit Behinderung anwendbar. Sie kann vielmehr auf jede Person angewendet werden. Die ICF deckt jedoch keine Umstände ab, die nicht mit der Gesundheit in Verbindung stehen. Besteht eine Beeinträchtigung der Partizipation (Teilhabe) aus anderen Gründen, z. B. der Geschlechtszugehörigkeit, sozioökonomischen oder ethnischen Gründen, ist die ICF nicht anwendbar.

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

===Terminologie Provider ===
Internationale Ausgabe: WHO
Deutsche Übersetzung: BfArM

===Inhaltsverwalter am österreichischen e-Health Terminologieserver===
ELGA GmbH

===Struktur===
Die ICF ist in zwei Teile gegliedert, von denen jeder wiederum zwei Komponenten hat:

====Funktionsfähigkeit und Behinderung====
Beschrieben wird die Funktionsfähigkeit oder Behinderung in folgenden Bereichen:

'''Körper'''
Dieser Bereich bezieht sich auf den menschlichen Organismus als Ganzes, also auch auf das Gehirn und seine (geistigen und seelischen) Funktionen. Es wird unterschieden zwischen:

* ''Körperfunktionen'', d. h. die physiologischen Funktionen von Körpersystemen (einschließlich psychologischer Funktionen). Beschrieben wird die Veränderung physiologischer Strukturen (z. B. der Sehfähigkeit).
* ''Körperstrukturen'', d. h. anatomische Teile des Körpers, wie Organe, Gliedmaßen und ihre Bestandteile. Beschrieben wird die Veränderung anatomischer Strukturen (z. B. am Auge).
Es kann jeweils eine funktionale und strukturelle Integrität oder eine Schädigung (Beeinträchtigung einer Körperfunktion oder -struktur, wie z. B. eine wesentliche Abweichung oder ein Verlust) beschrieben werden. Die Schädigungen werden hinsichtlich ihrer Abweichung von der Populationsnorm beschrieben (fünfstufige Skala von "nicht vorhanden" bis "voll ausgeprägt"). Eine Schädigung bezeichnet nicht notwendigerweise eine Krankheit, d. h. der Begriff ist weiter gefasst. Auch Ursache und Entwicklung der Schädigung wird hier nicht berücksichtigt.

'''Aktivitäten und Partizipation (Teilhabe)'''
Hier geht es um Aspekte der Funktionsfähigkeit (Leistungsfähigkeit) aus individueller und gesellschaftlicher Perspektive. Beschrieben wird das Vorhandensein oder die Abwesenheit von Beeinträchtigungen, die bei der Durchführung einer Aufgabe oder Handlung (Aktivität) oder dem Eingebundensein in eine Lebenssituation (Partizipation bzw. Teilhabe) erlebt werden. In der ICF werden folgende Bereiche beschrieben:

* Lernen und Wissensanwendung
* Allgemeine Aufgaben und Anforderungen
* Kommunikation
* Mobilität
* Selbstversorgung
* Häusliches Leben
* Interpersonelle Interaktion und Beziehungen
* Bedeutende Lebensbereiche (Erziehung, Arbeit und Beschäftigung, Wirtschaftliches Leben)
* Gemeinschafts-, soziales und staatsbürgerliches Leben

Für jeden Bereich wurden Beurteilungsmerkmale festgelegt, die jeweils hinsichtlich der Konstrukte Leistung (Durchführung von Aufgaben in der gegenwärtigen, tatsächlichen Welt) und Leistungsfähigkeit (Kapazität, höchstmögliches Funktionsniveau in einer standardisierten Umwelt, z. B. Test) auf einer fünfstufigen Skala eingeschätzt werden ("Problem nicht vorhanden" bis "Problem voll ausgeprägt"). Eine Diskrepanz ist Anhaltspunkt für den Einfluss von Umweltfaktoren (z. B. wenn ein HIV-Kranker aufgrund der sozialen Stigmatisierung nicht arbeiten kann, obwohl er keine Schädigung aufweist und voll leistungsfähig ist).

====Kontextfaktoren====
'''Umweltfaktoren'''
Beschrieben werden hier äußere Einflüsse auf Funktionsfähigkeit und Behinderung. Das ICF liefert eine umfassende Liste von Umweltfaktoren, die nach Bereichen gegliedert und jeweils nach der Nähe zum Individuum (unmittelbare Umwelt bis entferntere Umwelt) geordnet sind. Die in der ICF klassifizierten Bereiche sind:

* Produkte und Technologien
* Natürliche und vom Menschen veränderte Umwelt
* Unterstützung und Beziehungen
* Einstellungen
* Dienste, Systeme und Handlungsgrundsätze
Für jeden Umweltfaktor soll (auf einer fünfstufigen Skala von "nicht vorhanden" bis "voll ausgeprägt") angegeben werden, inwieweit er eine Barriere oder ein Förderfaktor aus Sicht des Individuums ist.

'''Personbezogene Faktoren'''
Hier sollen "innere" Einflüsse auf Funktionsfähigkeit und Behinderung beschrieben werden, d. h. Einflüsse von Merkmalen der Person, die selbst nicht Teil des Gesundheitsproblems oder -zustands sind (z. B. Geschlecht, ethnische Zugehörigkeit, Alter, andere Gesundheitsprobleme, Fitness, Lebensstil, Gewohnheiten, Erziehung, Bewältigungsstile, sozialer Hintergrund, Bildung und Ausbildung, Beruf sowie vergangene oder gegenwärtige Erfahrungen/Ereignisse, allgemeine Verhaltensmuster und Charakter, individuelles psychisches Leistungsvermögen).

Quelle: International Classification of Functioning, Disability and Health [https://de.wikipedia.org/wiki/International_Classification_of_Functioning,_Disability_and_Health] abgerufen am 04.06.2021

===Releasezyklus===
Bei Neuerscheinung einer aktualisierten deutschen Übersetzung

[[Kategorie:Terminologieserver]]

TS:Inhalte

2021-06-04T04:46:16Z

Sjencic:

{{#customtitle:Inhalte}}

== Codesysteme ==
Codesysteme, die am Terminologieserver abgelegt wurden, werden hier nach der selben Struktur - wenn möglich - beschrieben.

* Name
* Kurzbeschreibung
* Terminologie Provider (Quelle, Lizenz)
* Inhaltsverwalter am österreichischen e-Health Terminologieserver
* Struktur
* Releasezyklus
* Value Set

{{:ICD-10 BMG}}

{{:Leistungskatalog}}

{{:UCUM}}

{{:APPC}}

{{:ICPC-2}}

{{:ICF}}

{{:ICD-O-3}}

{{:HL7 Administrative Sex}}

{{:HL7 Administrative Gender}}

{{:ATC deutsch (WIdO)}}

{{:ASP Liste}}

{{:eImpf_Impfstoffe}}

==Value Sets==
Value Sets, die am Terminologieserver abgelegt wurden, werden hier nach der selben Struktur - wenn möglich - beschrieben.

* Name
* Kurzbeschreibung
* Terminologie Provider (Quelle, Lizenz)
* Inhaltsverwalter am österreichischen e-Health Terminologieserver
* Struktur
* Releasezyklus
* Codesystem

{{:ELGA_Administrative Gender_VS}}

{{:ELGA_Problemkatalog_VS}}

{{:ELGA_AllergyOrIntoleranceAgent_VS}}

{{:ELGA_Laborparameter}}

{{:ELGA_SpecimenType}}

{{:ELGA_MedikationsMengenart_VS}}

Dokumentenklassen für XDS Registries

2021-05-20T11:44:11Z

Sjencic:

==Hintergrund und Anwendungsfälle==
Für den organisationsübergreifenden Austausch von Dokumenten über Dokumentenregister (z.B. IHE XDS-basierende Registries) ist es notwendig, die Dokumente nach ihrer Art zu klassifizieren. Dieser Standard legt die für Österreich gültigen Dokumentenklassifikationen fest, ein Teil davon wurde bereits für ELGA festgelegt. Die Liste kann ergänzt werden, weitere ergänzende Codeskönnen bei HL7 Austria vorgeschlagen werden. Die oberste Hierarchieebene 0 umfasst die Hauptdokumentenklassen für ELGA Dokumente, sie entspricht dem ''classCode'' in XDS. Die Hierarchieebene 1 enthält die Spezialisierungen der Hauptdokumentenklassen(„Dokumententypen“), sie können in den XDS.''typeCode'' an die Registry übermittelt werden. In CDA-Dokumenten sind im Element clinicalDocument.code die spezialisierten Codes der untersten „Blattebene“(unterste Ebene, Dokumententyp) zu verwenden.

OID: 1.2.40.0.34.10.86

Aktuelle Version am Terminologieserver: https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen

{| class="wikitable sortable"
! Lvl- Typ
! Code
! Display Name
! Anwendungsbeschreibung
! Deutsche Sprachvariante
! Hinweise
! Parent Code System Name
! OID Parent Code System
|-
| 0-S
| 18842-5
| Discharge summary
|
| Entlassungsbrief
| Entlassungsbrief
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 11490-0
| Physician Discharge summary
|
| Entlassungsbrief Ärztlich
| Entlassungsbrief aus stationärer Behandlung (Arzt)
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34745-0
| Nurse Discharge summary
|
| Entlassungsbrief Pflege
| Entlassungsbrief aus stationärer Behandlung (Pflege)
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 11502-2
| Laboratory report
|
| Laborbefund
| Laborbefund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-S
| 18748-4
| Diagnostic Imaging Report
|
| Befund bildgebende Diagnostik
| Befund bildgebende Diagnostik
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 25045-6
| CT Unspecified body region
|
| Computertomographie-Befund
| Computertomographie-Befund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 25056-3
| MR Unspecified body region
|
| Magnetresonanztomographie-Befund
| Magnetresonanztomographie-Befund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 25061-3
| US Unspecified body region
|
| Ultraschall-Befund
| Ultraschall-Befund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 49118-3
| NM Unspecified body region
|
| Nuklearmedizinischer Befund
| Nuklearmedizinischer Befund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 44136-0
| PT Unspecified body region
|
| Positronen-Emissions-Tomographie-Befund
| Positronen-Emissions-Tomographie-Befund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 18745-0
| Cardiac catheterization study
|
| Herzkatheter-Befund
| Herzkatheter-Befund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 42148-7
| US Heart
|
| Echokardiographie-Befund
| Echokardiographie-Befund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 18782-3
| Radiology Study observation (narrative)
|
| Radiologie-Befund
| Radiologie-Befund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 18746-8
| Colonoscopy study
|
| Kolonoskopie-Befund
| Kolonoskopie-Befund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 18751-8
| Endoscopy study
|
| Endoskopie-Befund
| Endoskopie-Befund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 11525-3
| US for pregnancy
|
| Geburtshilfliche Ultraschalluntersuchung
| Geburtshilfliche Ultraschalluntersuchung
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 55113-5
| Key images Document Radiology
|
| KOS Objekte
| KOS Objekte
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-S
| 52471-0
| Medications
|
| Medikation
| Dokumente der e-Medikation
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 57833-6
| Prescription for medication
|
| Rezept
| Rezept
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 60593-1
| Medication dispensed.extended Document
|
| Abgabe
| Abgabe
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 56445-0
| Medication summary Document
|
| Medikationsliste
| Medikationsliste
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 61356-2
| Medication pharmaceutical advice.extended Document
|
| Pharmazeutische Empfehlung
| Pharmazeutische Empfehlung (Korrekturmeldung)
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 11529-5
| Surgical pathology study
| Pathologiebefund
| Pathologiebefund
| Differenzierung über ServiceEvent
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 18743-5
| Autopsy report
| Obduktionsbericht
| Obduktionsbefund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 18725-2
| Microbiology studies (set)
| Mikrobiologie
| Mikrobiologie-Befund
| Für direkt aus der Mikrobiologie erstellte Befunde
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 11504-8
| Surgical operation note
| OP-Bericht
| OP-Bericht
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-S
| 57829-4
| Prescription for medical equipment or product
| Nichtmedikamentöse Verordnungen (Allgemein)
| Verordnung von Heilbehelfen und Hilfsmitteln
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 64288-4
| Prescription for eyewear
| Verordnung für Brillen
| Brillenverordnung
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-S
| 51845-6
| Outpatient Consult note
| Facharztbefund/Fachambulanzbefund
| Allgemeiner Facharztbefund
| Spezialisierbar über Fachrichtung
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34764-1
| General medicine Consult note
| Allgemeinmedizin
| Allgemeinmedizinischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34803-7
| Occupational medicine Consult note
| Arbeitsmedizin
| Arbeitsmedizinischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34807-8
| Ophthalmology Consult note
| Augenheilkunde
| Augenbefund
| Augenbefund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 33720-4
| Blood bank consult
| Blutgruppenserologie und Transfusionsmedizin
| Immunhämatologischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34847-4
| Surgery Consult note
| Chirurgie
| Chirurgischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34758-3
| Dermatology Consult note
| Dermatologie
| Dermatologiebefund
| Dermatologiebefund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34760-9
| Diabetology Consult note
| Diabetologie
| Diabetologischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34879-7
| Endocrinology Consult note
| Endokrinologie
| Endokrinologiebefund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34761-7
| Gastroenterology Consult note
| Gastroenterologie
| Gastroenterologiebefund
| Gastroenterologiebefund
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34853-2
| Vascular surgery Consult note
| Gefäßchirurgie
| Gefäßchirurgischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34776-5
| Geriatric medicine Consult note
| Geriatrie / Akutgeriatrie
| Geriatriebefund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34777-3
| Obstetrics and Gynecology Consult note
| Gynäkologie und Geburtshilfe
| Gynäkologie-Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34779-9
| Hematology+Medical Oncology Consult note
| Hämatologie
| Hämatologie-Befund
| Für Hämatologie incl. der hämatologischen Onkologie
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34816-9
| Otolaryngology Consult note
| Hals-Nasen-Ohrenheilkunde
| HNO-Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34781-5
| Infectious disease Consult note
| Infektiologie
| Infektiologiebefund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34099-2
| Cardiology Consult note
| Kardiologie
| Kardiologiebefund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 68881-2
| Pediatric surgery Note
| Kinder- und Jugendchirurgie
| Kinder- und Jugendchirurgischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34812-8
| Oral and Maxillofacial Surgery Consult note
| Mund-, Kiefer- und Gesichtschirurge
| Mund-, Kiefer- und Gesichtschirurgischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34795-5
| Nephrology Consult note
| Nephrologie
| Nephrologischer befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34798-9
| Neurological surgery Consult note
| Neurochirurgie
| Neurochirurgischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34797-1
| Neurology Consult note
| Neurologie
| Neurologischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34805-2
| Oncology Consult note
| Onkologie
| Onkologiebefund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34814-4
| Orthopaedic surgery Consult note
| Orthopädie/Orthopädie-Chirurgie
| Orthopädischer/Orthopädisch-Chirurgischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 68818-4
| Pediatrics Note
| Pädiatrischer Befund
| Pädiatrischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34822-7
| Physical medicine and rehab Consult note
| Physikalische Medizin
| Physikalisch-Medizinischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34826-8
| Plastic surgery Consult note
| Plastische Chirurgie
| Plastisch-Chirurgischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34788-0
| Psychiatry Consult note
| Psychiatrie
| Psychiatrischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34103-2
| Pulmonary Consult note
| Pulmologie
| Pulmologischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34839-1
| Rheumatology Consult note
| Rheumatologie
| Rheumatologischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34831-8
| Radiation oncology Consult note
| Strahlentherapie-Radioonkologie
| Strahlentherapeutisch-Radioonkologischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34849-0
| Cardiothoracic surgery Consult note
| Thoraxchirurgie
| Thoraxchirurgischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 1-L
| 34851-6
| Urology Consult note
| Urologie
| Urologischer Befund
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 28651-8
| Nurse Transfer Note
| Pflegesituationsbericht
| Pflegesituationsbericht
| Pflegedokumentation
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 46215-0
| Wound care management Note
| Wunddokumentation
| Wunddokumentation
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 57016-8
| Privacy policy acknowledgment Document
| Einverständnis / Zustimmung des Patienten (Datenverwendung, Aufklärung etc.)
| Patienteneinverständniserklärung
| Die genaue Policy muss über eine OID referenziert werden
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 42348-3
| Advance directives
| Beachtliche und verbindliche Patientenverfügungen
| Patientenverfügung
| Die genaue Policy muss über eine OID referenziert werden
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 64298-3
| Power of attorney
| Vollmacht (medizinische Vorsorgevollmacht)
| Vorsorgevollmacht
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 34855-7
| Occupational therapy Consult note
| Ergotherapie
| Ergotherapeutischer Bericht
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 34845-8
| Speech-language pathology+Audiology Consult note
| Logopädie / Logotherapie
| Logopädischer Bericht
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 34841-7
| Social work Consult note
| Sozialarbeiter und Sozialpädagogen
| Sozialpädagogischer Bericht
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 34791-4
| Psychology Consult note
| Psychologie
| Psychologischer Bericht
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 34800-3
| Nutrition and dietetics Consult note
| Diätologie
| Diätologie-Bericht
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 34824-3
| Physical therapy Consult note
| Physiotherapie
| Physiotherapiebericht
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 57057-2
| Labor and delivery summary note
| Geburtshilfe
| Geburtsbericht (ärztlich)
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 59268-3
| Neonatal care report
| Hebammen
| Geburtsbericht (Hebamme)
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 34810-2
| Optometry Consult note
| Optometrie
| Optometrischer Bericht
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 29749-9
| Dialysis records
| Dialyse
| Dialysebericht
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 72134-0
| Cancer event report
| Krebsregistermeldung
| Krebsregistermeldung
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 57830-2
| Admission request Document
| Einweisung in stationäre Einrichtung
| Einweisungsbericht
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 57834-4
| Patient transportation request Document
| Anforderung für Patiententransport
| Anforderung für Patiententransport
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 11524-6
| EKG study
| EKG-Bericht
| EKG-Bericht
|
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 46209-3
| Provider orders
| Anforderung / Auftrag (allgemein)
| Anforderung / Auftrag
| Genaue Unterscheidung im Dokument (Level 3)
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 11488-4
| Consult note
| Befund
| Befund
| Verwendung nicht empfohlen. Befund ohne nähere Einschränkung, für nicht andernorts spezifizierte Dokumente oder Dokumente, für die NOCH kein spezifischer Code existiert.
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 60591-5
| Patient summary Document
| Patientenübersicht
| Patient Summary
| Übersicht über alle verfügbaren Daten eines Patienten
| LOINC
| 2.16.840.1.113883.6.1
|-
| 0-L
| 34133-9
| Summary of episode note
| Zusammenfassung eines Behandlungsfalles
| Krankengeschichte
| Übersicht über alle Daten zu einem Behandlungsfall
| LOINC
| 2.16.840.1.113883.6.1
|}

== Version 201907 ==
Neue Codes

{| class="wikitable sortable"
! style="font-weight: bold;" | Level-Type
! style="font-weight: bold;" | LOINC
! style="font-weight: bold;" | LOINC Long Common Name
! style="font-weight: bold;" | Deutsche Bezeichnung
! style="font-weight: bold;" | Bemerkung
|-
| 0-S
| 11369-6
| History of Immunization
| Immunisierungsstatus
|style="background:lightblue"| Neu
|-
| 1-L
| 82593-5
| Immunization summary report
| Kompletter Immunisierungsstatus
|style="background:lightblue"| Neu
|-
| 1-L
| 87273-9
| Immunization note
| Update Immunisierungsstatus
|style="background:lightblue"| Neu
|-
| 0-S
| 75496-0
| Telehealth Note
| Telemedizin Bericht
|style="background:lightblue"| Neu
|-
| 1-L
| 75497-8
| Telehealth Progress Note
| Telemedizin Fortschrittbericht
|style="background:lightblue"| Neu
|-
| 1-L
| 75498-6
| Telehealth Summary Note
| Telemedizin Endbericht
|style="background:lightblue"| Neu
|}

==Version 202001==
Änderungen für Version 202001

Entscheidung der AG "Outpatient Report": "''Die deutschen Benennungen der Dokumente soll dem Muster folgen „ Befund “ + Fach (entsprechend der offiziellen ärztlichen Fachrichtungen)''"

Neue und geänderte Codes

{| class="wikitable sortable"
! style="font-weight: bold;" | Level-Type
! style="font-weight: bold;" | LOINC
! style="font-weight: bold;" | LOINC Long Common Name
! style="font-weight: bold;" | Deutsche Bezeichnung
! style="font-weight: bold;" | Bemerkung
|-
|style="background:lightgreen"| 0-S
| 75476-2
| Physician note
| (Fach-) Arztbefund / Ambulanzbefund
| Vermutlich bessere Generalisierung als "Outpatient Consult Note"
|-
|style="background:lightgreen"| 0-D
| <del>51845-6</del>
| <del>Outpatient Consult note</del>
| <del>Facharztbefund / Fachambulanzbefund</del>
| Klassifiktion "Outpatient" schwierig - unpassend für stationäre Patienten (Konsile!)
|-
| 1-L
| 34131-3
| Outpatient Progress note
| Statusbericht
|style="background:lightblue"| Neu
|-
| 1-L
| 77403-4
| Anesthesiology Consult note
| Anästhesiologischer Befund
|style="background:lightblue"| Neu
|-
| 1-L
| 34816-9
| Otolaryngology Consult note
| Hals-Nasen-Ohrenheilkunde-Befund
| Korrektur der deutschen Bezeichnung
|-
| 1-L
| 34878-9
| Emergency medicine Note
| Notfallmedizinischer Befund
|style="background:lightblue"| Neu
|-
| 1-L
| 78568-3
| Palliative care Consult Note
| Palliativmedizinischer Befund
|style="background:lightblue"| Neu
|-
| 1-L
| 78726-7
| Pediatrics Consult Note
| Pädiatrischer Befund
|style="background:lightblue"| Neu
|-
| <del>1-D</del>
| <del>68818-4</del>
| <del>Pediatrics Note</del>
| <del>Pädiatrischer Befund</del>
|style="background:blue"| Entfernen
|-
| 1-L
| 67862-3
| Preoperative evaluation and management Note
| Präoperativer Befund
|style="background:lightblue"| Neu - Definition notwendig
|-
| 1-L
| 85866-2
| Sleep medicine Consult note
| Schlafmedizinischer Befund
|style="background:lightblue"| Neu
|-
| 1-L
| 78738-2
| Sports medicine Consult note
| Sportmedizinischer Befund
|style="background:lightblue"| Neu
|-
| 1-L
| 82359-1
| Reproductive endocrinology and infertility Consult note
| Reproduktionsmedizinischer Befund
|style="background:lightblue"| Neu

|-
| 1-L
| 78732-5
| Trauma Consult note
| Unfallchirurgischer Befund
|style="background:lightblue"| Neu
|-
| 0-L
| 57831-0
| Prescription for rehabilitation
| Antrag auf Anschlussheilverfahren
| style="background:lightblue"| Neu
|-
| 0-L
| 82593-5
| Immunization summary
| Impfpass
| style="background:lightblue"| Neu
|-
| 0-L
| 18761-7
| Transfer summary note
| Transferbericht (Verlegungsbericht)
| style="background:lightblue"| Neu - unter Entlassungsbrief einordnen
|}

Codes für Outpatient Report: [[ILF:Ärztlicher_Befund#Addenda_zum_.C3.84rztlichen_Befund_.28generisch.29|Klassifikation der Dokumente]]

==Version 20204==
Neue Codes

{| class="wikitable sortable"
! style="font-weight: bold;" | Level-Type
! style="font-weight: bold;" | LOINC
! style="font-weight: bold;" | LOINC Long Common Name
! style="font-weight: bold;" | Deutsche Bezeichnung
! style="font-weight: bold;" | Bemerkung
|-
| 0-S
| 75500-9
| Triage note
| Triage-Dokumentation
|style="background:lightblue"| Neu
|-
| 1-L
| 54094-8
| Emergency department Triage note
| Triage der Notfallabteilung
|style="background:lightblue"| Neu
|-
| 1-L
| 75499-4
| Telephone encounter Triage note
| Hotline-Triage (Telefonkontakt)
|style="background:lightblue"| Neu
|}

==Ballot Dezemeber 2020==
Die Programmer der 5 verschiedenen Herzschrittmacher-Hersteller liefern sowohl eine PDF-Datei als auch die einzelnen Datenelemente in maschinenlesbarer Form (XML oder Comma-separated). Daneben liefert die CRM-Lösung noch einen ärztlichen Befund. Damit beide Dokumentarten korrekt archiviert werden können, wird eine neue Dokumentenklasse und dazugehörige Dokumenttypen benötigt.

Die verschiedenen Dokumenttypen resultieren daraus, dass die Device Programmer ein abgeschlossenes Dokument als PDF oder XML Datei (gemäß ISO 11073-10103), Rosetta Terminologie) bei jeder Kontrolle im Spital liefern.
Die Ergebnisse des (kontinuierlichen) Home-Monitorings landen auf der Plattform der jeweiligen Hersteller und können als Zusammenfassung an die Kliniken übertragen werden.
In der Klinik selbst erfolgt eine Zusammenfassung des Status (im KIS oder einem entsprechenden Subsystem) womit ein weiteres Dokument entsteht.

Die unten angeführten Codes müssen zuerst ballotiert werden, bevor diese bei Regenstrief eingereicht werden.

{| class="wikitable sortable"
! style="font-weight: bold;" | Level-Type
! style="font-weight: bold;" | LOINC
! style="font-weight: bold;" | LOINC Long Common Name
! style="font-weight: bold;" | Deutsche Bezeichnung
! style="font-weight: bold;" | Bemerkung
|-
|0-S
|Beantragung offen
|Implanted device maintenance report
|Wartungsbericht implantierte Geräte
|style="background:lightblue"| Neu
|-
|1-L
|Beantragung offen
|Pacemaker programmer report
|Herzschrittmacher Programmer Bericht
|style="background:lightblue"| Neu
|-
|1-L
|Beantragung offen
|Defibrillator programmer report
|Defibrillator Programmer Bericht
|style="background:lightblue"| Neu
|-
|1-L
|Beantragung offen
|Loop recorder programmer report
|Loop recorder Programmer Bericht
|style="background:lightblue"| Neu
|-
|1-L
|Beantragung offen
|Pacemaker home monitoring report
|Herzschrittmacher Home Monitoring Bericht
|style="background:lightblue"| Neu
|-
|1-L
|Beantragung offen
|Defibrillator home monitoring report
|Defibrillator Home Monitoring Bericht
|style="background:lightblue"| Neu
|-
|1-L
|Beantragung offen
|Loop recorder home monitoring report
|Loop recorder Home Monitoring Bericht
|style="background:lightblue"| Neu
|-
|1-L
|Beantragung offen
|Pacemaker clinical report
|Herzschrittmacher Klinischer Bericht
|style="background:lightblue"| Neu
|-
|1-L
|Beantragung offen
|Defibrillator clinical report
|Defibrillator Klinischer Bericht
|style="background:lightblue"| Neu
|-
|1-L
|Beantragung offen
|Loop recorder clinical report
|Loop recorder Klinischer Bericht
|style="background:lightblue"| Neu
|}

===IHE - PCD Implantable Device Cardiac Observation===
Implantable Device - Cardiac - Observation (IDCO) überträgt Daten von implantierbaren Herzschrittmachern, Defibrillatoren oder Ereignisrecordern (oder implantierbaren Loop-Recordern) an Anwendungen in Unternehmen wie EHRs.

Kardiologen begleiten Patienten mit implantierbaren Herzgeräten verschiedener Hersteller. Diese Geräte werden in Herzschrittmacher, implantierbare Defibrillatoren und Herzmonitorgeräte unterteilt.

Im Rahmen der Patientennachsorge wird eine Untersuchung eines Herzgeräts durchgeführt. Es werden Informationen über das Gerät gesammelt, wie z.B. Geräteidentifikation, Therapieeinstellungen, Gerätediagnostik und Gerätetests. Diese Abfragen werden von herstellerspezifischen Geräten durchgeführt.

Zur Verbesserung der Workflow-Effizienz erfordern kardiologische und elektrophysiologische Praxen die Verwaltung von "Key"-Summarys der Abfragedaten eines implantierbaren Rhythmussteuergeräts in einem zentralen System wie einem elektronischen Gesundheitsdatensystem (EHR). Um diese Anforderung zu erfüllen, definiert das IDCO-Profil (Implantable Device - Cardiac - Observation) eine standardbasierte Übersetzung und Übertragung der zusammenfassenden Geräteabfrageinformationen vom Abfragesystem zum Informationsmanagementsystem.

Mit dem verstärkten Einsatz von EHR-Systemen, der Vernetzung von Systemen zur stationären und ambulanten Nachsorge implantierter Herzgeräte und dem anhaltenden Wachstum des Marktes für implantierbare Herzgeräte hat die Bedeutung dieses Profils für Ärzte weiter zugenommen. Die starke Beteiligung von Geräte- und EHR-Herstellern an der Entwicklung des IDCO-Profils ist eine Anerkennung dieser Bedeutung. Da sich das IDCO-Profil und die damit verbundenen Standards ständig weiterentwickeln, gibt es kaum Zweifel daran, dass die Verwendung dieses Profils eine entscheidende Komponente einer umfassenden kardiologischen Versorgung sein wird.

Quelle: [[https://wiki.ihe.net/index.php/PCD_Implantable_Device_Cardiac_Observation PCD_Implantable_Device_Cardiac_Observation]]

[[Datei:IHE Profils ICDO.png]]

== Version 202005.1 ==
Aktualisierung der Codes

{| class="wikitable sortable"
! style="font-weight: bold;" | Level-Type
! style="font-weight: bold;" | LOINC
! style="font-weight: bold;" | LOINC Long Common Name
! style="font-weight: bold;" | Deutsche Bezeichnung
! style="font-weight: bold;" | Bemerkung
|-
| 0-S
| 11502-2
| Laboratory report
| Laborbefund
| Keine Änderung
|-
| 1-L
| 18725-2
| Microbiology studies (set)
| Mikrobiologie-Befund
| Neues Unterelement von Laborbefund
|-
| 0-S
| 75496-0
| Telehealth Note
| Telegesundheitsdienst Bericht
| Korrektur der deutschen Bezeichnung
|-
| 1-L
| 75497-8
| Telehealth Progress Note
| Telegesundheitsdienst Zwischenbericht
| Korrektur der deutschen Bezeichnung
|-
| 1-L
| 75498-6
| Telehealth Summary Note
| Telegesundheitsdienst Entlassungsbericht
| Korrektur der deutschen Bezeichnung
|}

[[Category:Änderungsüberwachung]]

EImpf Impfstoffe

2021-03-03T10:37:31Z

Sjencic: /* Attribute der eImpf_Impfstoffe Liste */

{{#customtitle:eImpf_Impfstoffe}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==eImpf_Impfstoffe (1.2.40.0.34.4.16.1)==
Liste der Impfungen gelistet nach PZN. Hinweis: In der Liste der Impfstoffe sind idente Impfstoff Bezeichnungen mit unterschiedlichen PZN enthalten. Diese Präparate unterscheiden sich in der Packungsgröße oder der Zulassungsnummer. Die Attribute können unter den Details der einzelnen Konzepte nachgelesen werden.

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für den e-Impfpass verwendbaren Impfstoffe. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der eImpf_Impfstoffe Liste. '''UNKLAR''' In der eImpf_Impfstoffe Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
ELGA GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH und ELGA GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen

====Attribute der eImpf_Impfstoffe Liste====
Die Attribute in der eImpf_Impfstoffe Liste werden aus der ASP-Liste herangezogen, jedoch gelten nicht dieselben Regeln wie in der e-Medikation. Alle Impfstoffe, die in der eImpf_Impfstoffe Liste vorhanden sind, dürfen im e-Impfpass ausgewählt werden. Die e-Med-Attribute werden nur mitgeführt, damit die Codeliste in Zukunft mit der ASP-Liste wieder vereinigt werden kann.

Wichtig für den e-Impfpass sind die Informationen zu den Impfindikationen! Diese Informationen werden nicht in der aktuellen ASP-Liste bereitgestellt und müssen manuell in diese Listen eingetragen werden.

* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - “Zulassungsname“
* '''DisplayName''' (Datenquelle APO-Verlag) - Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamen (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES)
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Die Logik der "ELGA Gültigkeit" hat für den e-Impfpass keine Relevanz.
Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen). Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - Dieses Attribute wird beim Eintrag in den e-Impfpass nicht berücksichtigt. Es beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA ImpfungIndikation''' (Datenquelle ELGA) - Dieses Attribut stellt die Krankheit dar, gegen die die Impfung wirkt und dient als Verknüpfung zu den ImmunizationTargets. Je nach Impfung kann eine PZN mehrere Impfindikationen beinhalten (z.B. Kombinationsimpfungen). Bei den Kombinationsimpfungen werden die Attribute ELGA_ImpfungIndikation_K_code, ELGA_ImpfungIndikation_K_text mit dem entsprechenden ImmunizationTarget befüllt z.B.Diphtherie-Pertussis-Tetanus Impfstoffkombination und danach werden die einzelnen Impfstoffe in die ELGA_ImpfungIndikation_01_code, ELGA_ImpfungIndikation_01_text usw. eingefüllt.
** Code z.B. 2.16.840.1.113883.6.96:836377006 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
** Text z.B. "Influenza Impfstoff"
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
** Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft

Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant
* '''Status''' (Datenquelle ELGA) - '''UNKLAR'''noch nicht durchgedacht - hier sollten die aktiven und inaktiven Codes von einander unterschieden werden

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

Aktuell befinden sich leere Attribute (Barcode1-5) im Codesystem, die nicht zu beachten sind.

===Releasezyklus===
Die ASP-Liste wird monatlich aktualisiert, aber die Impfstoffe ändern sich nicht im selben Rhythmus. Daher muss monatlich eine Kontrolle durchgeführt und bei Bedarf die Liste (inkl. eImpf_Impfstoffe_VS) angepasst werden

[[Kategorie:Terminologieserver]]

EImpf Impfstoffe

2021-03-03T10:30:46Z

Sjencic: /* Attribute der eImpf_Impfstoffe Liste */

{{#customtitle:eImpf_Impfstoffe}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==eImpf_Impfstoffe (1.2.40.0.34.4.16.1)==
Liste der Impfungen gelistet nach PZN. Hinweis: In der Liste der Impfstoffe sind idente Impfstoff Bezeichnungen mit unterschiedlichen PZN enthalten. Diese Präparate unterscheiden sich in der Packungsgröße oder der Zulassungsnummer. Die Attribute können unter den Details der einzelnen Konzepte nachgelesen werden.

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für den e-Impfpass verwendbaren Impfstoffe. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der eImpf_Impfstoffe Liste. '''UNKLAR''' In der eImpf_Impfstoffe Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
ELGA GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH und ELGA GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen

====Attribute der eImpf_Impfstoffe Liste====
Die Attribute in der eImpf_Impfstoffe Liste werden aus der ASP-Liste herangezogen, jedoch gelten nicht dieselben Regeln wie in der e-Medikation. Alle Impfstoffe, die in der eImpf_Impfstoffe Liste vorhanden sind, dürfen im e-Impfpass ausgewählt werden - unabhängig davon welche Werte in den verschiedenen Attributen dokumentiert sind. Die e-Med-Attribute werden nur mitgeführt, damit die Codeliste in Zukunft mit der ASP-Liste wieder vereinigt werden kann.

Wichtig für den e-Impfpass sind die Informationen zu den Impfindikationen! Diese Informationen werden nicht in der aktuellen ASP-Liste bereitgestellt und müssen manuell in diese Listen eingetragen werden.

* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - “Zulassungsname“
* '''DisplayName''' (Datenquelle APO-Verlag) - Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamen (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES)
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Die Logik der "ELGA Gültigkeit" hat für den e-Impfpass keine Relevanz.
Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen). Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - Dieses Attribute wird beim Eintrag in den e-Impfpass nicht berücksichtigt. Es beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA ImpfungIndikation''' (Datenquelle ELGA) - Dieses Attribut stellt die Krankheit dar, gegen die die Impfung wirkt und dient als Verknüpfung zu den ImmunizationTargets. Je nach Impfung kann eine PZN mehrere Impfindikationen beinhalten (z.B. Kombinationsimpfungen). Bei den Kombinationsimpfungen werden die Attribute ELGA_ImpfungIndikation_K_code, ELGA_ImpfungIndikation_K_text mit dem entsprechenden ImmunizationTarget befüllt z.B.Diphtherie-Pertussis-Tetanus Impfstoffkombination und danach werden die einzelnen Impfstoffe in die ELGA_ImpfungIndikation_01_code, ELGA_ImpfungIndikation_01_text usw. eingefüllt.
** Code z.B. 2.16.840.1.113883.6.96:836377006 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
** Text z.B. "Influenza Impfstoff"
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
** Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft

Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant
* '''Status''' (Datenquelle ELGA) - '''UNKLAR'''noch nicht durchgedacht - hier sollten die aktiven und inaktiven Codes von einander unterschieden werden

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

Aktuell befinden sich leere Attribute (Barcode1-5) im Codesystem, die nicht zu beachten sind.

===Releasezyklus===
Die ASP-Liste wird monatlich aktualisiert, aber die Impfstoffe ändern sich nicht im selben Rhythmus. Daher muss monatlich eine Kontrolle durchgeführt und bei Bedarf die Liste (inkl. eImpf_Impfstoffe_VS) angepasst werden

[[Kategorie:Terminologieserver]]

EImpf Impfstoffe

2021-03-03T10:22:06Z

Sjencic: /* Attribute der eImpf_Impfstoffe Liste */

{{#customtitle:eImpf_Impfstoffe}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==eImpf_Impfstoffe (1.2.40.0.34.4.16.1)==
Liste der Impfungen gelistet nach PZN. Hinweis: In der Liste der Impfstoffe sind idente Impfstoff Bezeichnungen mit unterschiedlichen PZN enthalten. Diese Präparate unterscheiden sich in der Packungsgröße oder der Zulassungsnummer. Die Attribute können unter den Details der einzelnen Konzepte nachgelesen werden.

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für den e-Impfpass verwendbaren Impfstoffe. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der eImpf_Impfstoffe Liste. '''UNKLAR''' In der eImpf_Impfstoffe Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
ELGA GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH und ELGA GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen

====Attribute der eImpf_Impfstoffe Liste====
Die Attribute in der eImpf_Impfstoffe Liste werden aus der ASP-Liste herangezogen, jedoch gelten nicht dieselben Regeln wie in der e-Medikation. Alle Impfstoffe, die in der eImpf_Impfstoffe Liste vorhanden sind, dürfen im e-Impfpass ausgewählt werden - unabhängig davon welche Werte in den verschiedenen Attributen dokumentiert sind. Die e-Med-Attribute werden nur deshalb mitgeführt, damit die Codeliste in Zukunft mit der ASP-Liste wieder vereinigt werden kann.

Wichtig für den e-Impfpass sind die Informationen zu den Impfindikationen! Diese Informationen werden nicht in der aktuellen ASP-Liste bereitgestellt und müssen manuell in diese Listen eingetragen werden.

* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - “Zulassungsname“
* '''DisplayName''' (Datenquelle APO-Verlag) - Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamen (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES)
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Die Logik der "ELGA Gültigkeit" hat für den e-Impfpass keine Relevanz.
Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen). Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - Dieses Attribute wird beim Eintrag in den e-Impfpass nicht berücksichtigt. Es beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA ImpfungIndikation''' (Datenquelle ELGA) - Dieses Attribut stellt die Krankheit dar, gegen die die Impfung wirkt und dient als Verknüpfung zu den ImmunizationTargets. Je nach Impfung kann eine PZN mehrere Impfindikationen beinhalten (z.B. Kombinationsimpfungen). Bei den Kombinationsimpfungen werden die Attribute ELGA_ImpfungIndikation_K_code, ELGA_ImpfungIndikation_K_text mit dem entsprechenden ImmunizationTarget befüllt z.B.Diphtherie-Pertussis-Tetanus Impfstoffkombination und danach werden die einzelnen Impfstoffe in die ELGA_ImpfungIndikation_01_code, ELGA_ImpfungIndikation_01_text usw. eingefüllt.
** Code z.B. 2.16.840.1.113883.6.96:836377006 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
** Text z.B. "Influenza Impfstoff"
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
** Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft

Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant
* '''Status''' (Datenquelle ELGA) - '''UNKLAR'''noch nicht durchgedacht - hier sollten die aktiven und inaktiven Codes von einander unterschieden werden

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

Aktuell befinden sich leere Attribute (Barcode1-5) im Codesystem, die nicht zu beachten sind.

===Releasezyklus===
Die ASP-Liste wird monatlich aktualisiert, aber die Impfstoffe ändern sich nicht im selben Rhythmus. Daher muss monatlich eine Kontrolle durchgeführt und bei Bedarf die Liste (inkl. eImpf_Impfstoffe_VS) angepasst werden

[[Kategorie:Terminologieserver]]

EImpf Impfstoffe

2021-03-03T10:21:01Z

Sjencic: /* Attribute der eImpf_Impfstoffe Liste */

{{#customtitle:eImpf_Impfstoffe}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==eImpf_Impfstoffe (1.2.40.0.34.4.16.1)==
Liste der Impfungen gelistet nach PZN. Hinweis: In der Liste der Impfstoffe sind idente Impfstoff Bezeichnungen mit unterschiedlichen PZN enthalten. Diese Präparate unterscheiden sich in der Packungsgröße oder der Zulassungsnummer. Die Attribute können unter den Details der einzelnen Konzepte nachgelesen werden.

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für den e-Impfpass verwendbaren Impfstoffe. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der eImpf_Impfstoffe Liste. '''UNKLAR''' In der eImpf_Impfstoffe Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
ELGA GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH und ELGA GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen

====Attribute der eImpf_Impfstoffe Liste====
Die Attribute in der eImpf_Impfstoffe Liste werden aus der ASP-Liste herangezogen, jedoch gelten nicht dieselben Regeln wie in der e-Medikation. Alle Impfstoffe, die in der eImpf_Impfstoffe Liste vorhanden sind, dürfen im e-Impfpass ausgewählt werden - unabhängig davon welche Werte in den verschiedenen Attributen dokumentiert sind. Die e-Med-Attribute werden nur deshalb mitgeführt, damit die Codeliste in Zukunft mit der ASP-Liste wieder vereinigt werden kann.

Wichtig für den e-Impfpass sind die Informationen zu den Impfindikationen! Diese Informationen werden nicht in der aktuellen ASP-Liste bereitgestellt und müssen manuell in diese Listen eingetragen werden.

* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - “Zulassungsname“
* '''DisplayName''' (Datenquelle APO-Verlag) - Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamen (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES)
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Die Logik der "ELGA Gültigkeit" hat für den e-Impfpass keine Relevanz.
Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen). Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar. '''UNKLAR''' Dieses Attribute wird beim Eintrag in den e-Impfpass nicht berücksichtigt.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA ImpfungIndikation''' (Datenquelle ELGA) - Dieses Attribut stellt die Krankheit dar, gegen die die Impfung wirkt und dient als Verknüpfung zu den ImmunizationTargets. Je nach Impfung kann eine PZN mehrere Impfindikationen beinhalten (z.B. Kombinationsimpfungen). Bei den Kombinationsimpfungen werden die Attribute ELGA_ImpfungIndikation_K_code, ELGA_ImpfungIndikation_K_text mit dem entsprechenden ImmunizationTarget befüllt z.B.Diphtherie-Pertussis-Tetanus Impfstoffkombination und danach werden die einzelnen Impfstoffe in die ELGA_ImpfungIndikation_01_code, ELGA_ImpfungIndikation_01_text usw. eingefüllt.
** Code z.B. 2.16.840.1.113883.6.96:836377006 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
** Text z.B. "Influenza Impfstoff"
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
** Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft

Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant
* '''Status''' (Datenquelle ELGA) - '''UNKLAR'''noch nicht durchgedacht - hier sollten die aktiven und inaktiven Codes von einander unterschieden werden

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

Aktuell befinden sich leere Attribute (Barcode1-5) im Codesystem, die nicht zu beachten sind.

===Releasezyklus===
Die ASP-Liste wird monatlich aktualisiert, aber die Impfstoffe ändern sich nicht im selben Rhythmus. Daher muss monatlich eine Kontrolle durchgeführt und bei Bedarf die Liste (inkl. eImpf_Impfstoffe_VS) angepasst werden

[[Kategorie:Terminologieserver]]

EImpf Impfstoffe

2021-03-03T09:56:26Z

Sjencic: /* Attribute der eImpf_Impfstoffe Liste */

{{#customtitle:eImpf_Impfstoffe}}

{{Informationsbox|In Bearbeitung|Diese Beschreibung befindet sich derzeit in Bearbeitung}}

==eImpf_Impfstoffe (1.2.40.0.34.4.16.1)==
Liste der Impfungen gelistet nach PZN. Hinweis: In der Liste der Impfstoffe sind idente Impfstoff Bezeichnungen mit unterschiedlichen PZN enthalten. Diese Präparate unterscheiden sich in der Packungsgröße oder der Zulassungsnummer. Die Attribute können unter den Details der einzelnen Konzepte nachgelesen werden.

===Kurzbeschreibung===
Dieses Codesystem enthält im Wesentlichen die für den e-Impfpass verwendbaren Impfstoffe. Der Identifier (Code) ist die Pharmazentralnummer (PZN) d.h. für alle Packungen eines Medikaments gibt es einen eigenen Eintrag in der eImpf_Impfstoffe Liste. '''UNKLAR''' In der eImpf_Impfstoffe Liste sind „zugelassene“, „registrierte“, „ruhend gestellt“, „Parallelimport genehmigt“ und „paralleldistributierte“ als auch „aufgehobene“ Arzneimittel enthalten. Diese sind entsprechend den Attributen gekennzeichnet. In der ASP-Liste sind weder homöopathische Arzneispezialitäten noch Allergene enthalten.

===Nutzungsbedigungen===
Die AGES GmbH stellt mit großer Sorgfalt Informationen zu Arzneispezialitäten zur Verwendung für die ELGA-Maßnahme "e-Medikation" (§ 16a GTelG 2012 idgF) zur Verfügung. Trotz größtmöglicher Sorgfalt können Fehler dennoch nicht gänzlich ausgeschlossen werden. Sollten beispielsweise Widersprüche hinsichtlich der der Arzneispezialität beiliegenden Fach- bzw. Gebrauchsinformation und den Informationen auf den Inhalten des Terminologieservers bestehen, gilt der Inhalt der jeweiligen Fach- bzw. Gebrauchsinformation. Bei Unterschieden zu Informationen des Warenverzeichnisses des Apothekerverlages gilt die Information des Warenverzeichnisses. Die AGES GmbH übernimmt daher keine Haftung für eventuelle unmittelbare oder mittelbare Schäden, die durch die direkte oder indirekte Nutzung der angebotenen Inhalte entstehen. Sollten Sie die angebotenen Daten und Inhalte herunterladen und weiterverwenden, so dürfen diese inhaltlich nicht verändert werden und die Weiterverwendung erfolgt auf eigenes Risiko. Teile der bereitgestellten Daten stammen aus Katalogen der EMA, European Medicines Agency, bzw. des EDQM, European Directorate of the Quality of Medicines. Die Weiterwendung dieser Daten unterliegt den jeweiligen Copyright und Nutzungsbestimmungen der EMA bzw. EDQM.

===Terminologie Provider===
ELGA GmbH

===Inhaltsverwalter am österreichischen Terminologieserver===
AGES GmbH und ELGA GmbH

===Struktur===
* Der Code entspricht der Pharmazentralnummer (PZN).
* Danach folgen zahlreiche Attribute zum Medikament bzw. der Zulassung (Name, Zulassungsnummer, Wirkstoffe, Art der Anwendung, ATC-Codes etc.). Nähere Beschreibung der Attribute folgt weiter unten.
* Einzelne Attribute verweisen auf andere Codesysteme, wie etwa ArtderAnwendung:
** 1.2.40.0.10.1.4.3.4.3.4 ist die OID des referenzierten Codesystems „ELGA_MedikationArtAnwendung“
** 100000073619 ist der Code („zum Einnehmen“)
** Ein zusätzliches Attribut gibt den Anzeigetext des Codes aus dem referenzierten Codesystem aus: ELGA_MedikationArtAnwendung_01_text = zum Einnehmen

====Attribute der eImpf_Impfstoffe Liste====
Die AGES liefert dem e-Medikation System eine Liste der Arzneispezialitäten (ASP-Liste) zu. In dieser Datenbasis MÜSSEN (ausgenommen ATC-Code) folgende Datenfelder vorhanden sein:
* '''Pharmazentralnummer (PZN)''' (Datenquelle AGES) - eindeutiger Identifikator. Die letzte Ziffer ist eine Prüfnummer. Hinweis: Im Packungs-Barcode auf Medikamenten wird der PZN ein Präfix vorangestellt, dadurch errechnet sich die Prüfnummer anders und kann von der hier angegebenen abweichen. Anmerkung: Die österreichische und deutsche Pharmazentralnummer sind identisch bezüglich Aufbau und Verfahren für die Prüfziffernrechnung, werden jedoch unabhängig voneinander vergeben.
* '''Bezeichnung der Arzneispezialität''' (Datenquelle AGES) - “Zulassungsname“
* '''DisplayName''' (Datenquelle APO-Verlag) - Es wird der Kurztext des APO-Verlags dazu verwendet (z.B. Aspirin, Textfeld). Für eine Historisierung des Handelsnamen (d.h. auch wenn in einem aktuellen Warenverzeichnis, kein Handelsname mehr angeführt ist) muss der bisher angeführte Handelsname in der ASP-Liste weiterhin vorhanden sein
* '''Zulassungsnummer''' (Datenquelle AGES)
* '''ELGA Gültigkeit''' (Datenquelle AGES) - Die Logik der "ELGA Gültigkeit" hat für den e-Impfpass keine Relevanz.
Die Datenqualität hängt in diesem Punkt von der korrekten Information im Warenverzeichnisses ab (d.h. der Veränderungscode muss auf „Streichung“ oder lieferbar auf „nicht lieferbar“ angeliefert worden sein)
**TRUE: ASP-Status „zugelassen“, „registriert“, „Parallelimport“ und "„Paralleldistribution" (Ausgangszeitpunkt ist der 01.01.2015)
**FALSE: alle anderen Status im Lifecycle einer ASP (ab dem Stichtag 02.01.2015). Wenn nicht zugelassen, dann false (um größtmögliche Patientensicherheit zu erzielen). Wenn ein ASP lt. Warenverzeichnis gestrichen oder nicht mehr lieferbar ist, aber weiterhin zugelassen, parallelimportiert, paralleldistributiert oder registriert ist, dann erhält es ELGA Gültigkeit „true“ und MedikationPackungsstatusLieferbar „false“.
* '''ELGA MedikationPackungsstatusLieferbar''' (Datenquelle APO-Verlag ) - beschreibt, ob ASP lieferbar oder gestrichen ist. Der Status „Streichung“ lt. Veränderungscode des Warenverzeichnisses bzw. „nicht lieferbar“ lt. Liefercode des Warenverzeichnisses führen zu einem „false“-Wert im Feld MedikationPackungsstatusLieferbar. '''UNKLAR''' Dieses Attribute wird beim Eintrag in den e-Impfpass nicht berücksichtigt.
* '''GroesseGewicht''' (Datenquelle Warenverzeichnis) - Packungsgröße
* '''ELGA MedikationMengenart''' (Datenquelle Warenverzeichnis) - Mengenarten sind lt. den Einheiten des UCUM-Katalogs auszugeben. Ein Ausschnit des UCUM Katalogs mit den in Österreich gängigsten UCUM Einheiten kann am Terminologieserver abgerufen werden.
** Code z.B. 2.16.840.1.113883.6.8:{Stueck} (OID des UCUM Katalogs:UCUM Code)
** Text z.B. Stück
* '''ELGA ImpfungIndikation''' (Datenquelle ELGA) - Dieses Attribut stellt die Krankheit dar, gegen die die Impfung wirkt und dient als Verknüpfung zu den ImmunizationTargets. Je nach Impfung kann eine PZN mehrere Impfindikationen beinhalten (z.B. Kombinationsimpfungen). Bei den Kombinationsimpfungen werden die Attribute ELGA_ImpfungIndikation_K_code, ELGA_ImpfungIndikation_K_text mit dem entsprechenden ImmunizationTarget befüllt z.B.Diphtherie-Pertussis-Tetanus Impfstoffkombination und danach werden die einzelnen Impfstoffe in die ELGA_ImpfungIndikation_01_code, ELGA_ImpfungIndikation_01_text usw. eingefüllt.
** Code z.B. 2.16.840.1.113883.6.96:836377006 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
** Text z.B. "Influenza Impfstoff"
* '''ELGA MedikationRezeptpflichtStatus''' (Datenquelle AGES) - Indikator für Präparate, die nicht rezeptpflichtig sind ("OTC-Präparate"). Es werden die Originalwerte (mehrere Abstufungen) verwendet, die GDA-Softwarehersteller müssen selbst mappen. Alle Codes und die dazu gehörigen Texte findet man im Codesystem "MedikationRezeptpflichtstatus" (OID 1.2.40.0.10.1.4.3.4.3.7) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.7:100000072086 (OID des Codesystems "MedikationRezeptpflichtstatus":Code)
**Text z.B. "Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
* '''ELGA whoATC''' (Datenquelle AGES)
**Code z.B. 2.16.840.1.113883.6.73:G04BE08 (OID des ATC WHO und der ATC-Code)
** Text z.B. Tadalafil (Deutsche Übersetzung des ATC WHO, Datenquelle: ATC deutsch Wido) Falls keine deutsche Bezeichnung vorliegt, wird der englische Originaltext zum ATC eingetragen.
* '''ELGA MedikationArtAnwendung''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationArtAnwendung" (OID 1.2.40.0.10.1.4.3.4.3.4) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.4:100000073619 (OID des Codesystems "MedikationArtAnwendung":Code)
**Text z.B. "zum Einnehmen"
* '''ELGA Substanzen''' (Datenquelle AGES) – entspricht dem Wirkstoff ohne Hilfsstoffe. Alle gültigen Codes findet man im Codesystem "Medikation_AGES_Wirkstoffe" (OID 1.2.40.0.34.5.156) am Terminologieserver.
**Code z.B. 1.2.40.0.34.5.156:1708237 (OID des Codesystems "Medikation_AGES_Wirkstoffe":Code)
**Text z.B. TADALAFIL
* '''ELGA MedikationDarreichungsform''' (Datenquelle AGES) - Alle gültigen Codes findet man im Codesystem "MedikationDarreichungsform" (OID 1.2.40.0.10.1.4.3.4.3.5) am Terminologieserver.
**Code z.B. 1.2.40.0.10.1.4.3.4.3.5:100000073665 (OID des Codesystems "MedikationDarreichungsform":Code)
**Text z.B. Filmtablette
* '''ELGA MedikationWechselwirkungsRelevant''' (Datenquelle AGES) - true/false, Noch nicht eingestufte OTCs werden bis zu einer Entscheidung durch die Kommission als wechselwirkungsrelevant (true) eingestuft

Folgende Regel wurden von der AGES definiert, die die Zuordnung zu "rezeptfreien" und "nicht rezeptfreien" Arzneimitteln ermöglicht:
{| class="wikitable"
!Bedeutung
!Ausgabe in Spalte "ELGA_MedikationRezeptpflichtStatus_text"
!Ausgabe in Spalte "ELGA_MedikationWechselwirkungsRelevant"
|-
|nicht wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|false
|-
|wechselwirkungsrelevantes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|noch nicht eingestuftes Arzneimittel (rezeptfrei)
|„Arzneimittel zur Abgabe ohne aerztliche Verschreibung“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|„Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Substitution“
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur Abgabe gegen besondere aerztliche Verschreibung, Suchtgifte"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur eingeschraenkten Abgabe gegen aerztliche Verschreibung, deren Anwendung definierten Spezialisten vorbehalten ist"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen Abgabe auf aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur einmaligen oder wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|-
|Nicht rezeptfreies Arzneimittel
|"Arzneimittel zur wiederholten Abgabe gegen aerztliche Verschreibung"
|true
|}
* '''Domaene''' (Datenquelle AGES) - ausschließlich „human“ relevant
* '''Status''' (Datenquelle ELGA) - '''UNKLAR'''noch nicht durchgedacht - hier sollten die aktiven und inaktiven Codes von einander unterschieden werden

'''Auffälligkeit''':
Beim Export werden sehr viele leere Felder für diese Art von Attributen geliefert. Grund: Wenn die ASP mit den meisten Arten der Anwendung/Wirkstoffen/ATC-Codes fünf Einträge für code und text hat, werden beim Terminologie-Export bei ASPs mit nur einem Eintrag für code und text vier leere Attributspaare hinzugefügt.

Aktuell befinden sich leere Attribute (Barcode1-5) im Codesystem, die nicht zu beachten sind.

===Releasezyklus===
Die ASP-Liste wird monatlich aktualisiert, aber die Impfstoffe ändern sich nicht im selben Rhythmus. Daher muss monatlich eine Kontrolle durchgeführt und bei Bedarf die Liste (inkl. eImpf_Impfstoffe_VS) angepasst werden

[[Kategorie:Terminologieserver]]

ILF:XDS Metadaten (Version 3)

2021-02-10T10:57:56Z

Sjencic: /* 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)}}
{{Underconstruction}}


{{#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.7]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0
|Submitted = ELGA GmbH
|Date = Februar 2021
|Copyright = 2011-
|Status = Kommentierung
|Period = n.a.
|OID = 1.2.40.0.34.7.6.7
|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 CDA Dokumenten in der ELGA Infrastruktur notwendig sind und wie sie aus den CDA Dokumenten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden XDS-Metadaten-Guide im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für elektronische Dokumente der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti IHE ITI]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref>.

Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012), aber auch für medizinische Dokumente im österreichischen Gesundheitswesen. 
TODO: XDSi-Metadaten einfügen https://collab.dicom-austria.at/pages/viewpage.action?pageId=20709391&preview=/20709391/20709392/AnbindungBilddaten_Gesamtarchitektur.pdf

=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 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]</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]</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 [ILF:Allgemeiner_Implementierungsleitfaden_2020]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at]). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020]'''.
{{EndILFBox}}

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website TODO: [[ILF:Ambulanzbefund_Guide|Ambulanzbefund Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
* Beispieldokumente
* Schematron-Prüfregeln
* Design-Beispiele
{{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:

*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 und Hinweise===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''Hinweis:''' Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden
{{EndYellowBox}}
''Hinweis auf anderen Implementierungsleitfaden:''
{{BeginILFBox}}
'''Verweis''' Verweis auf den Allgemeinen Leitfaden:…
{{EndILFBox}}
''Themenbezogenes CDA Beispiel-Fragment im XML Format:''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>

<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"
|-
! style="text-align:left" colspan="3"| Autoren
|-
! style="text-align:left" width="10%" | Kürzel ||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person1
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Herausgeber, Projektleiter, CDA-Koordinator
|- style="background:#FFFFFF"
| SSA || ELGA GmbH || Stefan Sabutsch
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Autoren
|- style="background:#FFFFFF"
| JB|| CodeWerk Software Services and Development GmbH|| Jürgen Brandstätter
|- style="background:#FFFFFF"
| SSA|| ELGA GmbH, HL7 Austria||Stefan Sabutsch
|- style="background:#FFFFFF"
| OKU|| ELGA GmbH|| Oliver Kuttin
|- style="background:#FFFFFF"
| KHO|| Wiener Krankenanstaltenverbund|| Konrad Hölzl
|}

1 Namen ohne Titel




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

Eine IHE XDS Registry verwaltet Dokumente und macht diese 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.

Für die Registrierung von Bilddaten über XDS-I wird eine eigene Spezifikation veröffentlicht.

Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.

==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten<ref name="ALF"></ref> in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten (Metadaten der XDSDocumentEntry Objekte)
** ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 (16.9.2020) Final Text''<ref name="IHE ITI TF-3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 17.0 (2020), 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> und den "ELGA CDA Implementierungsleitfäden" erstellt.

===XDS Folder===
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
===XDS Submission Sets===
Eine weitere Profilierung des XDS SubmissionSets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.

==Hinweise zur Verwendung des Dokuments==
===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}}

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

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. Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.

====Löschen aus der Registry [ITI-62]====
Das Löschen von Dokumenten in ELGA erfolgt ausschließlich in folgenden Fällen: Löschen durch Bürger, Opt-Out, Ablauf der Aufbewahrungsdauer (nach 10 Jahren müssen Dokumente gelöscht werden). Das Löschen erfolgt i.d.R. "sicher", sodass die Daten nicht wiederhergestellt werden können, sowohl für Verweise als auch Dokumente. Über die Transaktion ITI-62 kann ein Dokument aus der Registry gelöscht werden. Beim Löschen werden sowohl der Registereintrag als auch das Dokument aus dem Repository gelöscht; falls das Löschen der Dokumente aufgrund anderer Verpflichtungen ausgeschlossen ist, sind nur die Verweise zu löschen. Siehe "Organisationshandbuch ELGA-Bereiche und Krankenanstalten" [8].

===Größenbeschränkung ===
ELGA schreibt keine Größenbeschränkung für registrierte Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1]]].

==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-TF3).<ref name="IHE ITI TF-3"></ref>

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:''' Sehen Sie auch die Vorschrift zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument 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 korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.

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

Die IHE hat im Rahmen des "Patient 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="IHE ITI"></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, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus Bilddaten (KOS)===
TODO:

===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'''
# 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"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" rowspan="2" |'''Metadaten Element'''
|'''Optionalität'''
| rowspan="2" |'''Beschreibung'''
| rowspan="2" |'''Que-'''

'''lle'''
|-
|'''ELGA'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''R'''
|Die Person, welche das Dokument verfasst hat
|<nowiki>-</nowiki>
|-
| rowspan="4" |
|authorInstitution
|'''R'''
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|A/K
|-
|authorPerson
|'''R2'''
|Daten der Person

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

z.B.: 55113-5 "KOSObjekte"
|A
|-
| colspan="2" |'''confidentialityCode'''
|'''R'''
|Vertraulichkeitscode. Fester Wert "N"
|A
|-
| colspan="2" |'''creationTime'''
|'''R'''
|Zeitpunkt der Dokumentenerstellung
|K
|-
| colspan="2" |'''eventCodeList'''
|'''R'''
|Liste von Codes von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''eventCodeDisplayNameList'''
|'''R2'''
|Liste von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''intendedRecipient'''
|'''X'''
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
| -
|-
| colspan="2" |'''languageCode'''
|'''R'''
|Sprachcode. Fester Wert "de-AT"
|A
|-
| colspan="2" |'''legalAuthenticator'''
|'''X'''
|Rechtlicher Unterzeichner
| -
|-
| colspan="2" |'''serviceStartTime'''
|'''R'''
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|K
|-
| colspan="2" |'''serviceStopTime'''
|'''X'''
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
| -
|-
| colspan="2" |'''sourcePatientId'''
|'''R'''
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''sourcePatientInfo'''
|'''R'''
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''Title'''
|'''R'''
|Titel des Dokuments
|A/K
|-
| colspan="2" |'''typeCode'''
|'''R'''
|Objekttyp (Unterklasse)

codierter Wert
|A
|-
| colspan="2" |'''uniqueId'''
|'''R'''
|Global eindeutige ID des Objektes

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

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

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

 



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

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

TODO: urn:ihe:iti:xds:2015:encounterId als referenceIdList Eintrag ergänzen?

{| 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 1: Legende zur Spalte "Quelle" der folgenden Tabelle''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| 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="45%" |'''Beschreibung '''|| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
|- style="background:#CBD7F1"
|'''SD9'''||'''OD10'''
|- 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)||'''R'''||'''R'''||Die Person, welche das Dokument verfasst hat||-
|- style="background:white"
| ||authorInstitution||'''R'''||'''R'''||ID der Organisation, der die Person angehört. (OID aus dem GDA-Index)||C
|- style="background:white"
| ||authorPerson||'''R'''||'''R'''||Daten der Person (Name, ID, etc.)||C
|- style="background:white"
| ||authorRole||'''R2'''||'''X'''||Rolle der Person||C
|- style="background:white"
| ||authorSpeciality||'''R2'''||'''X'''||Fachrichtung der Person||C
|- style="background:white"
| colspan="2" |'''classCode'''||'''R'''||'''R'''||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"||C
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''R'''||'''X'''||Vertraulichkeitscode des Dokuments||C
|- style="background:white"
| colspan="2" |'''creationTime'''||'''R'''||'''R'''||Zeitpunkt der Dokumentenerstellung||C
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R2'''||'''R2'''||Liste von Gesundheitsdienstleistungen||C
|-
| colspan="2" |'''formatCode'''
|'''R'''
|'''R'''
|Format des Dokumenteninhalts
|C
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O'''||'''X'''||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C
|- style="background:white"
| colspan="2" |'''languageCode'''||'''R'''||'''R'''||Sprachcode des Dokuments z.B.: "de-AT"||C
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R2'''||'''X'''||Rechtlicher Unterzeichner des Dokuments||C
|-
| colspan="2" |'''practiceSettingCode'''
|'''R'''
|'''R'''
|Fachliche Zuordnung des Dokuments
|C
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R2'''||'''O'''||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R2'''||'''O'''||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung||C
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''R'''||'''R'''||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH||C
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''X'''||'''X'''||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C
|- style="background:white"
| colspan="2" |'''Title'''||'''R'''||'''R'''||Titel des Dokuments||C
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''R'''||'''R'''||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"||C
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''R'''||'''R'''||Global eindeutige ID des Dokuments||C
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''R'''||'''O'''||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert||C
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''R'''||'''R'''||Klassifizierung des GDA
|C

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
|- style="background:white"
| colspan="2" |'''availabilityStatus'''||'''R'''||'''R'''||Gültigkeit des Dokuments||E1
|- style="background:white"
| colspan="2" |'''mimeType'''||'''R'''||'''R'''||Mime Type des Dokuments z.B.: "text/xml" für CDA||E1
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O'''||'''O'''||Verweis auf ein referenziertes Dokument||E1
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O'''||'''O'''||Typ der Relation zu dem referenzierten Dokument. z.B.: RPLC, XFRM||E1
|- style="background:white"
| colspan="2" |'''entryUUID'''||'''R'''||'''R'''||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)||E1
|- style="background:white"
| colspan="2" |'''objectType'''||'''R'''||'''R'''||Typ des DocumentEntries (SD oder ODD)||E1
|- style="background:white"
| colspan="2" |'''comments'''||'''O'''||'''O'''||Kommentar zum Dokument||E2
|- style="background:white"
| colspan="2" |'''patientId'''||'''R'''||'''R'''||Patienten-ID in der XDS Affinity Domain||E1

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|- style="background:white"
| colspan="2" |'''hash'''||'''R'''||'''X'''||Hash Wert des Dokuments. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''homeCommunityId'''||'''R'''||'''R'''||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.||A
|- style="background:white"
| colspan="2" |'''repositoryUniqueId '''||'''R'''||'''R'''||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''size'''||'''R'''||'''X'''||Größe des Dokuments in Bytes. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''URI'''14||'''-'''||'''-'''||'''Wird in XDS nicht verwendet'''||A
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|- style="background:white"
| colspan="2" |'''elgaFlag'''||'''R'''||'''R'''||Kennzeichnet ein Dokument als "ELGA-Dokument"||B
|- style="background:white"
| colspan="2" |'''elgaHash'''||'''R'''||'''R'''||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B
|}
''Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)''

9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht. 
10 OD: "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 SubmissionSets übereinstimmen. 
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. 
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein. 
14 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.


=XDS-I Metadaten für DICOM KOS Objekte=
==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

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.

{| class="wikitable"
|'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

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

'''im KOS'''
|'''Beschreibung'''
|-
| colspan="5" |author
|-
|author.authorInstitution
|R
|
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl den Namen als auch die OID der Institution im 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.
|-
| colspan="5" |Die die Studie durchführende Person ist als author anzugeben:
|-
|author.authorPerson
|R2
|(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.
|-
|
|
|'''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.
|-
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|-
|author.authorPerson
|R2
|(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.
|-
|creationTime
|R
|(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.
|-
|eventCodeList
|R
|
|
|Enthält den APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|eventCodeListDisplayNameList
|R2
|
|
|Enthält den Display Name des APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|serviceStartTime
|R
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|-
|sourcePatientId
|R
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|-
|sourcePatientInfo
|R
|(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.
|-
|title
|R
|(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".
 
|-
|uniqueId
|R
|
|(0008,0018)
|Die SOP Instance UID des KOS
|-
| colspan="4" |referenceIdList
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|-
|value mit CXi.5 =

"<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>"
|R
|(0020,000D) oder ein vergleich-bares Attribut
|(0020,000D) oder ein vergleich-bares 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 Kapitel 8.2.2.
|-
|value mit CXi.5 =

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
|O
|(0008,0050) oder ein vergleich-bares 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.
|-
|comments
|O
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

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 Radiology Technical Framework, vol2, rev. 19, "4.68.4.1.2.3.2 DocumentEntry Metadata" sowie IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. 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 kann

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

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

$id ... OID der Organisation aus dem GDA-Index

concat( 
$name,"^^^^^^^^^", 
$id 
) 
<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-TF3].
====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[[#%20ftn1|[1]]], wenn vorhanden
#*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) ----[[#%20ftnref1|[1]]] Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den DICOM Attribut Modality der Studie abgleitet werden
#*Modalität[[#%20ftn1|[2]]]: Attribut "Modality", (0008,0060)
#*Hersteller: Attribut "Manufacturer", (0008,0070)
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</nowiki>

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

$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>2323^MusterDoc^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
=====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-TF3].

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objektation 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|4.2.15]]
|}

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "[https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen hl7-austria-Dokumentenklassen]" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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 "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]".

====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 registrieren 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)
#Sollten 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''[[#%20ftn1|[3]]] berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

[[#%20ftnref1|[3]]] <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</nowiki>
====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 +(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. 20160518 in 20160518000000).

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-TF3].{{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".[[# ftn4|[4]]])
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.
----[[# ftnref4|[4]]] DICOM Austria: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten", 22.01.2020, <nowiki>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</nowiki> (zuletzt besucht am 12.3.2020)

====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 des DICOM Objektes aus den Attributen des KOS Objektes:
#*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. 20160518 in 20160518000000).

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel 3.2.12 sourcePatientId gemappt und verwendet.

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

====Spezifikation (empfohlene Variante)====
'''sourcePatientInfo''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = concat(

$patientID, "^^^&amp;",

$oid, "&amp;ISO"

)

Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO

$name = ""

$birthtime = ""

$gender = ""

$addr = "" <pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientInfo">
<ValueList>
<Value>PID-3|$id</Value>
<Value>PID-5|$name</Value>
<Value>PID-7|$birthtime</Value>
<Value>PID-8|$gender</Value>
<Value>PID-11|$addr</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modailty 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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 entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.

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 zwei unterschiedliche Einträge in referenceIdList notwendig:

#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId)
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number)

'''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="IHE ITI TF-3"></ref>

{| 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 z.B. 1.2.40.0.34.99.999

concat

(

$id, "^^^^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

"&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>^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^^^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"

====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 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 [https://tools.ietf.org/html/rfc2045 <nowiki>RFC 2045[6]</nowiki>] und RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

[6] <nowiki>http://tools.ietf.org/html/rfc2045</nowiki>

[7] <nowiki>http://tools.ietf.org/html/rfc2049</nowiki>

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das 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 "[[urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be]]" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

====Spezifikation====

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

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.

===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 weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

==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 SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description 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"

#GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
{{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 
) 
<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-TF3].

====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). Mindestens eine Person

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

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

====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 '''''[R2]'''''.
#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 '''''[R2]'''''.
#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|4.2.15]]
|}

 

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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===
Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:
##ClinicalDocument/effectiveTime
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.
#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
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-TF3].
{{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 [R2].
#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 PCC Profil definiert in Kapitel "Medical Document Bindings" Spezialbehandlungen für gewissen 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}}

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

===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 '''''[R2]'''''.

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

TODO: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.

====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] … Lokale ID des Patienten vom einbringenden System
##d[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-TF3].

===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|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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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.
uniqueId wird als ebRIM

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===
Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommen.
{{BeginYellowBox}}
Im Rahmen von ELGA ist die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten einzubringen. Weitere andere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.
{{EndYellowBox}}

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

====Spezifikation====
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="IHE ITI TF-3"></ref>

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

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

referenceIdList wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat

(

ClinicalDocument/setId/@extension, "^^^",

ClinicalDocument/setId/@root, "^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

homeCommunityId

)

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;amp;1.2.40.0.34.99.111.1.1
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>
^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</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^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"
<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><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;2.25
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki>
&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

====Bildungsregel für den formatCodeDisplayName====
TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.

Der formatCodeDisplayName ist analog zum formatCode aus den displayNames des entsprechenden Value Sets [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS] zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels ":" (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).

'''Beispiele:'''

*'''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''
*'''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''
*'''ELGA Laborbefund, EIS Full Support v2.06+'''

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = gemäß Liste der in ELGA gültigen FormatCodes 
$codeSystem = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]
<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">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>
<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">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>

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, das das DocumentEntry repräsentiert.

Folgende Mime-Types sind für Dokumente zugelassen: 
CDA R2: '''text/xml''' 
DICOM/KOS: '''application/dicom''' 

<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 wurde ein genau entsprechendes Element 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 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 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"

====Spezifikation====

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

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.

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

<references />

==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 (2015) HL7 Implementation Guide for CDA® R2: Ärztlicher Entlassungsbrief.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.2.6], http://www.elga.gv.at

|-
|[3]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Entlassungsbrief Pflege. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.3.6], http://www.elga.gv.at
|-
| || 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

|-
|[4]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Laborbefund.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.4.6], http://www.elga.gv.at

|-
|[5]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Befund bildgebende Diagnostik.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.5.6], http://www.elga.gv.at
|-
|[6]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: e-Medikation.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.8.6], http://www.elga.gv.at

|-
|[7]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2:
|-
| || Pflegesituationsbericht (2.06) [OID 1.2.40.0.34.7.12.6], http://www.elga.gv.at

|-
|[8]|| ELGA GmbH (2015) Organisationshandbuch.
|-
| || ELGA-Bereiche und Krankenanstalten (2.2.1) [OID 1.2.40.0.34.3.1.2.1.32], http://www.elga.gv.at
|}

==Revisionsliste==
{| class="wikitable"
!Vers.
!Datum
!Änderungsgrund
|-
|0.05
|16.05.2011
|Ergebnisse aus dem technischen Online-Meeting
|-
|2.00 Beta
|12.08.2011
|Erster "Release candidate" des Dokuments für internen Review innerhalb der Arbeitsgruppe.
|-
|2.00 rc1
|30.08.2011
|Redaktionelle Überarbeitung.
|-
|2.00 FWGD
|10.10.2011
|Fertigstellung des "Final Working Group Draft". Veröffentlicht für öffentlichen Review.
|-
|2.01
|11.06.2012
|Fertigstellung der gültigen Version 2.01 "Final". Abgrenzung des Geltungsbereiches (XDSDocumentEntry), Überarbeitung "PracticeSettingCode", Hinweis zu OID eingefügt (1.2.3), Überarbeitung der "parentDocumentRelationship", Typos ausgebessert
|-
|2.01
|21.12.2012
|Layout-Anpassung
|-
|2.01a
|07.03-2013
|Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16: "dieses Dokuments" eingefügt; 363: displayNameOf($code), "Of" gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch "2"-> "Enhanced" etc.) Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt Allgemein: Typos ausgebessert
|-
|2.02
|12.08.2013
|2.3.2 Präzisierung der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessert.
|-
|2.02
|12.08.2013
|2.3.2.3 PDF/A-1a-Vorschrift hinzugefügt
|-
|2.02
|13.08.2013
|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF/A-1a-
|-
|2.02
|17.09.2013
|Typos, Formatierung und Seitenumbrüche ausgebessert
|-
|2.02a
|06.02.2014
|Beispiele in Tabelle 3 korrigiert
|-
|2.03
|26.02.2014
|Definition von ReferenceIdList eingefügt
|-
|2.03
|03.03.2014
|Definition von intendedRecipient eingefügt
|-
|2.03
|03.03.2014
|Änderungen in Tabelle 3: LegalAuthenticator – von [R] auf [R2] geändert IntendedRecipient – von "-" auf [O] geändert, für Verwendung mit XDW vorgesehen ReferenceIdList hinzugefügt Den Namen des Value Sets von "ELGA-PracticeSettingCode" auf "ELGA-PracticeSettingCode-vs" geändert
|-
|2.03.
|03.03.2014
|Anhang gelöscht: 3.1. IHE ITI-TF3, Kapitel 4.1.7 "Document Definition Metadata" 3.2. IHE PCC-TF2, Kapitel 4.1.1 "XDSDocumentEntry Metadata" 3.3. IHE XDS Data Types
|-
|2.03
|03.03.2014
|Korrekturen: ITI Version einheitlich geändert auf "(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)". 1.1.3 Hinweis auf Terminologieserver hinzugefügt Tabelle 3 angepasst: EntryUUID Beschreibung geändert patientId Beschreibung geändert
|-
|2.03
|06.03.2014
|Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId
|-
|2.03
|21.03.2014
|Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt
|-
|2.03
|26.03.2014
|Kapitel 1.4. Korrektur von Dokumentverweisen
|-
|2.03a
|28.03.2014
|Kapitel 2.1 Korrektur von Fußnotennummern
|-
|2.03a
|28.03.2014
|Kapitel 2.2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000
|-
|2.03b
|1.7.2014
|Den Namen des Value Sets von "ELGA-PracticeSetting Code-vs" auf "ELGA_Practicesetting_VS" korrigiert
|-
|2.03b
|11.07.2014
|2.3.2.5 OID in der Spezifikation ergänzt
|-
|2.03b
|11.07.2014
|2.3.6 OID in der Spezifikation ergänzt
|-
|2.03b
|05.08.2014
|2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert
|-
|2.03b
|06.08.2014
|2.1 Überblickstabelle: ParentDocumentId und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]
|-
|2.03b
|06.08.2014
|Referenzen auf CDA Implementierungsleitfäden aktualisiert
|-
| colspan="3" |Version 2.05
|-
|2.05
|03.11.2014
|EntryUUID als "ELGA-Relevant" klassifiziert. Darstellung der Übersichtstabelle geändert
|-
|2.05
|03.11.2014
|2.2.15 TypeCode: ClassificationScheme im Beispiel korrigiert von "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" (falsch) auf "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" (richtig)
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht
|-
|2.05
|19.11.2014
|2.2.2. authorPerson: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden
|-
|2.05
|19.11.2014
|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software
|-
|2.05
|24.11.2014
|2.2.1.1. Spezifikation von authorInstitution: Fall entfernt, in dem die ID des GDA unbekannt ist. Die OID des GDA ist für ELGA-CDA [M]
|-
|2.05
|26.11.2014
|2.4 ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und ELGA-Flag. Auch in 2.1 entsprechend angegeben.
|-
|2.05
|12.03.2014
|Seite 2-3: Absätze "Verbindlichkeit", "Hinweise zur Verwendung" und "Erarbeitung des Implementierungsleitfadens" hinzugefügt.
|-
| colspan="3" |Version 2.06
|-
|2.06
|19.05.2015
|1.2.2. Codesysteme und Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.
|-
|2.06
|13.10.2015
|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch
|-
|2.06
|13.10.2015
|1.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.
|-
|2.06
|07.10.2015
|1.4.3. Kapitel "Metadaten aus 'On-Demand Documents' (ODD)" eingefügt
|-
|2.06
|10.09.2015
|2.1 Tabelle 3: Beschreibung der entryUUID ergänzt
|-
|2.06
|07.10.2015
|2.1 Tabelle 3: Spalte "Optionalität IHE" gelöscht, Spalte zur Definition von On-Demand-Documents eingefügt. objectType hinzugefügt patientid als E1 "ELGA relevant" deklariert (war E2)
|-
|2.06
|30.10.2015
|2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt wird, falls mehrere ID-Elemente angegeben sind.
|-
|2.06
|19.05.2015
|2.2.5. und 2.2.15: Typos verbessert
|-
|2.06
|29.10.2015
|2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt
|-
|2.06
|21.07.2015
|2.2.10. legalAuthenticator: Hinweis, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar ist.
|-
|2.06
|08.10.2015
|2.3.7 objectType hinzugefügt
|-
| colspan="3" |'''Version 2.06.2 (Nebenversion)''' x …betrifft Implementierung (erste Spalte)
|-
|
|01.08.2016
|Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
|-
|
|18.5.2016
|1.2 Erklärung zur Verwendung von XDS Folder und SubmissionSet hinzugefügt.
|-
|
|01.08.2016
|2.1. Tabelle 3: Korrektur der Optionalität von eventCodeList auf [R2], wie im Text bei 2.2.8 angegeben
|-
|x
|14.6.2016
|creationTime, serviceStartTime, serviceStopTime: Präzisierung der Vorgaben für Datum/Zeit, sie MUSS immer entsprechen der Angabe in CDA entweder 8 oder 14-stellig angegeben werden.
|-
|
|03.08.2016
|2.2.5, 2.3.2.2, 2.3.2.5, 2.3.5, 2.3.5.1, 2.3.5.1, 2.1, 1.4, 2.2.7, 2.2.11, 2.2.15, 2.3.6, 1.4.1.2 Korrektur der Großschreibung bei normativen Vorgaben
|-
|
|05.01.2017
|2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.
|-
|
|y
|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;"
|-
|
|y
|Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
|-
|
|y
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
|-
|
|y
|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.
|-
|
|
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
|-
|
|
|Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
|-
|
|
|Kapitel "4.2.7 legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
|-
|
|
|Kapitel "4.2.4 creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
|-
|
|y
|Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
|-
|
|y
|Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
|-
|
|
|Kapitel "4.2.2.1 Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
|-
|
|y
|Kapitel "XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.
|}

ILF:XDS Metadaten (Version 3)

2021-02-10T10:52:17Z

Sjencic: /* 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)}}
{{Underconstruction}}


{{#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.7]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0
|Submitted = ELGA GmbH
|Date = Februar 2021
|Copyright = 2011-
|Status = Kommentierung
|Period = n.a.
|OID = 1.2.40.0.34.7.6.7
|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 CDA Dokumenten in der ELGA Infrastruktur notwendig sind und wie sie aus den CDA Dokumenten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden XDS-Metadaten-Guide im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für elektronische Dokumente der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti IHE ITI]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref>.

Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012), aber auch für medizinische Dokumente im österreichischen Gesundheitswesen. 
TODO: XDSi-Metadaten einfügen https://collab.dicom-austria.at/pages/viewpage.action?pageId=20709391&preview=/20709391/20709392/AnbindungBilddaten_Gesamtarchitektur.pdf

=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 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]</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]</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 [ILF:Allgemeiner_Implementierungsleitfaden_2020]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at]). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020]'''.
{{EndILFBox}}

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website TODO: [[ILF:Ambulanzbefund_Guide|Ambulanzbefund Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
* Beispieldokumente
* Schematron-Prüfregeln
* Design-Beispiele
{{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:

*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 und Hinweise===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''Hinweis:''' Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden
{{EndYellowBox}}
''Hinweis auf anderen Implementierungsleitfaden:''
{{BeginILFBox}}
'''Verweis''' Verweis auf den Allgemeinen Leitfaden:…
{{EndILFBox}}
''Themenbezogenes CDA Beispiel-Fragment im XML Format:''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>

<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"
|-
! style="text-align:left" colspan="3"| Autoren
|-
! style="text-align:left" width="10%" | Kürzel ||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person1
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Herausgeber, Projektleiter, CDA-Koordinator
|- style="background:#FFFFFF"
| SSA || ELGA GmbH || Stefan Sabutsch
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Autoren
|- style="background:#FFFFFF"
| JB|| CodeWerk Software Services and Development GmbH|| Jürgen Brandstätter
|- style="background:#FFFFFF"
| SSA|| ELGA GmbH, HL7 Austria||Stefan Sabutsch
|- style="background:#FFFFFF"
| OKU|| ELGA GmbH|| Oliver Kuttin
|- style="background:#FFFFFF"
| KHO|| Wiener Krankenanstaltenverbund|| Konrad Hölzl
|}

1 Namen ohne Titel




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

Eine IHE XDS Registry verwaltet Dokumente und macht diese 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.

Für die Registrierung von Bilddaten über XDS-I wird eine eigene Spezifikation veröffentlicht.

Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.

==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten<ref name="ALF"></ref> in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten (Metadaten der XDSDocumentEntry Objekte)
** ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 (16.9.2020) Final Text''<ref name="IHE ITI TF-3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 17.0 (2020), 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> und den "ELGA CDA Implementierungsleitfäden" erstellt.

===XDS Folder===
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
===XDS Submission Sets===
Eine weitere Profilierung des XDS SubmissionSets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.

==Hinweise zur Verwendung des Dokuments==
===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}}

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

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. Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.

====Löschen aus der Registry [ITI-62]====
Das Löschen von Dokumenten in ELGA erfolgt ausschließlich in folgenden Fällen: Löschen durch Bürger, Opt-Out, Ablauf der Aufbewahrungsdauer (nach 10 Jahren müssen Dokumente gelöscht werden). Das Löschen erfolgt i.d.R. "sicher", sodass die Daten nicht wiederhergestellt werden können, sowohl für Verweise als auch Dokumente. Über die Transaktion ITI-62 kann ein Dokument aus der Registry gelöscht werden. Beim Löschen werden sowohl der Registereintrag als auch das Dokument aus dem Repository gelöscht; falls das Löschen der Dokumente aufgrund anderer Verpflichtungen ausgeschlossen ist, sind nur die Verweise zu löschen. Siehe "Organisationshandbuch ELGA-Bereiche und Krankenanstalten" [8].

===Größenbeschränkung ===
ELGA schreibt keine Größenbeschränkung für registrierte Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1]]].

==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-TF3).<ref name="IHE ITI TF-3"></ref>

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:''' Sehen Sie auch die Vorschrift zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument 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 korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.

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

Die IHE hat im Rahmen des "Patient 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="IHE ITI"></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, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus Bilddaten (KOS)===
TODO:

===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'''
# 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"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" rowspan="2" |'''Metadaten Element'''
|'''Optionalität'''
| rowspan="2" |'''Beschreibung'''
| rowspan="2" |'''Que-'''

'''lle'''
|-
|'''ELGA'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''R'''
|Die Person, welche das Dokument verfasst hat
|<nowiki>-</nowiki>
|-
| rowspan="4" |
|authorInstitution
|'''R'''
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|A/K
|-
|authorPerson
|'''R2'''
|Daten der Person

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

z.B.: 55113-5 "KOSObjekte"
|A
|-
| colspan="2" |'''confidentialityCode'''
|'''R'''
|Vertraulichkeitscode. Fester Wert "N"
|A
|-
| colspan="2" |'''creationTime'''
|'''R'''
|Zeitpunkt der Dokumentenerstellung
|K
|-
| colspan="2" |'''eventCodeList'''
|'''R'''
|Liste von Codes von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''eventCodeDisplayNameList'''
|'''R2'''
|Liste von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''intendedRecipient'''
|'''X'''
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
| -
|-
| colspan="2" |'''languageCode'''
|'''R'''
|Sprachcode. Fester Wert "de-AT"
|A
|-
| colspan="2" |'''legalAuthenticator'''
|'''X'''
|Rechtlicher Unterzeichner
| -
|-
| colspan="2" |'''serviceStartTime'''
|'''R'''
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|K
|-
| colspan="2" |'''serviceStopTime'''
|'''X'''
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
| -
|-
| colspan="2" |'''sourcePatientId'''
|'''R'''
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''sourcePatientInfo'''
|'''R'''
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''Title'''
|'''R'''
|Titel des Dokuments
|A/K
|-
| colspan="2" |'''typeCode'''
|'''R'''
|Objekttyp (Unterklasse)

codierter Wert
|A
|-
| colspan="2" |'''uniqueId'''
|'''R'''
|Global eindeutige ID des Objektes

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

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

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

 



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

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

TODO: urn:ihe:iti:xds:2015:encounterId als referenceIdList Eintrag ergänzen?

{| 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 1: Legende zur Spalte "Quelle" der folgenden Tabelle''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| 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="45%" |'''Beschreibung '''|| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
|- style="background:#CBD7F1"
|'''SD9'''||'''OD10'''
|- 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)||'''R'''||'''R'''||Die Person, welche das Dokument verfasst hat||-
|- style="background:white"
| ||authorInstitution||'''R'''||'''R'''||ID der Organisation, der die Person angehört. (OID aus dem GDA-Index)||C
|- style="background:white"
| ||authorPerson||'''R'''||'''R'''||Daten der Person (Name, ID, etc.)||C
|- style="background:white"
| ||authorRole||'''R2'''||'''X'''||Rolle der Person||C
|- style="background:white"
| ||authorSpeciality||'''R2'''||'''X'''||Fachrichtung der Person||C
|- style="background:white"
| colspan="2" |'''classCode'''||'''R'''||'''R'''||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"||C
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''R'''||'''X'''||Vertraulichkeitscode des Dokuments||C
|- style="background:white"
| colspan="2" |'''creationTime'''||'''R'''||'''R'''||Zeitpunkt der Dokumentenerstellung||C
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R2'''||'''R2'''||Liste von Gesundheitsdienstleistungen||C
|-
| colspan="2" |'''formatCode'''
|'''R'''
|'''R'''
|Format des Dokumenteninhalts
|C
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O'''||'''X'''||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C
|- style="background:white"
| colspan="2" |'''languageCode'''||'''R'''||'''R'''||Sprachcode des Dokuments z.B.: "de-AT"||C
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R2'''||'''X'''||Rechtlicher Unterzeichner des Dokuments||C
|-
| colspan="2" |'''practiceSettingCode'''
|'''R'''
|'''R'''
|Fachliche Zuordnung des Dokuments
|C
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R2'''||'''O'''||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R2'''||'''O'''||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung||C
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''R'''||'''R'''||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH||C
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''X'''||'''X'''||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C
|- style="background:white"
| colspan="2" |'''Title'''||'''R'''||'''R'''||Titel des Dokuments||C
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''R'''||'''R'''||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"||C
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''R'''||'''R'''||Global eindeutige ID des Dokuments||C
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''R'''||'''O'''||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert||C
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''R'''||'''R'''||Klassifizierung des GDA
|C

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
|- style="background:white"
| colspan="2" |'''availabilityStatus'''||'''R'''||'''R'''||Gültigkeit des Dokuments||E1
|- style="background:white"
| colspan="2" |'''mimeType'''||'''R'''||'''R'''||Mime Type des Dokuments z.B.: "text/xml" für CDA||E1
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O'''||'''O'''||Verweis auf ein referenziertes Dokument||E1
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O'''||'''O'''||Typ der Relation zu dem referenzierten Dokument. z.B.: RPLC, XFRM||E1
|- style="background:white"
| colspan="2" |'''entryUUID'''||'''R'''||'''R'''||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)||E1
|- style="background:white"
| colspan="2" |'''objectType'''||'''R'''||'''R'''||Typ des DocumentEntries (SD oder ODD)||E1
|- style="background:white"
| colspan="2" |'''comments'''||'''O'''||'''O'''||Kommentar zum Dokument||E2
|- style="background:white"
| colspan="2" |'''patientId'''||'''R'''||'''R'''||Patienten-ID in der XDS Affinity Domain||E1

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|- style="background:white"
| colspan="2" |'''hash'''||'''R'''||'''X'''||Hash Wert des Dokuments. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''homeCommunityId'''||'''R'''||'''R'''||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.||A
|- style="background:white"
| colspan="2" |'''repositoryUniqueId '''||'''R'''||'''R'''||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''size'''||'''R'''||'''X'''||Größe des Dokuments in Bytes. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''URI'''14||'''-'''||'''-'''||'''Wird in XDS nicht verwendet'''||A
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|- style="background:white"
| colspan="2" |'''elgaFlag'''||'''R'''||'''R'''||Kennzeichnet ein Dokument als "ELGA-Dokument"||B
|- style="background:white"
| colspan="2" |'''elgaHash'''||'''R'''||'''R'''||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B
|}
''Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)''

9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht. 
10 OD: "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 SubmissionSets übereinstimmen. 
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. 
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein. 
14 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.


=XDS-I Metadaten für DICOM KOS Objekte=
==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

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.

{| class="wikitable"
|'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

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

'''im KOS'''
|'''Beschreibung'''
|-
| colspan="5" |author
|-
|author.authorInstitution
|R
|
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl den Namen als auch die OID der Institution im 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.
|-
| colspan="5" |Die die Studie durchführende Person ist als author anzugeben:
|-
|author.authorPerson
|R2
|(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.
|-
|
|
|'''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.
|-
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|-
|author.authorPerson
|R2
|(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.
|-
|creationTime
|R
|(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.
|-
|eventCodeList
|R
|
|
|Enthält den APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|eventCodeListDisplayNameList
|R2
|
|
|Enthält den Display Name des APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|serviceStartTime
|R
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|-
|sourcePatientId
|R
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|-
|sourcePatientInfo
|R
|(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.
|-
|title
|R
|(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".
 
|-
|uniqueId
|R
|
|(0008,0018)
|Die SOP Instance UID des KOS
|-
| colspan="4" |referenceIdList
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|-
|value mit CXi.5 =

"<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>"
|R
|(0020,000D) oder ein vergleich-bares Attribut
|(0020,000D) oder ein vergleich-bares 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 Kapitel 8.2.2.
|-
|value mit CXi.5 =

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
|O
|(0008,0050) oder ein vergleich-bares 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.
|-
|comments
|O
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

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 Radiology Technical Framework, vol2, rev. 19, "4.68.4.1.2.3.2 DocumentEntry Metadata" sowie IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. 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 kann

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

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

$id ... OID der Organisation aus dem GDA-Index

concat( 
$name,"^^^^^^^^^", 
$id 
) 
<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-TF3].
====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[[#%20ftn1|[1]]], wenn vorhanden
#*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) ----[[#%20ftnref1|[1]]] Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den DICOM Attribut Modality der Studie abgleitet werden
#*Modalität[[#%20ftn1|[2]]]: Attribut "Modality", (0008,0060)
#*Hersteller: Attribut "Manufacturer", (0008,0070)
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</nowiki>

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

$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>2323^MusterDoc^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
=====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-TF3].

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objektation 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|4.2.15]]
|}

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "[https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen hl7-austria-Dokumentenklassen]" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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 "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]".

====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 registrieren 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)
#Sollten 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''[[#%20ftn1|[3]]] berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

[[#%20ftnref1|[3]]] <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</nowiki>
====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 +(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. 20160518 in 20160518000000).

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-TF3].{{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".[[# ftn4|[4]]])
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.
----[[# ftnref4|[4]]] DICOM Austria: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten", 22.01.2020, <nowiki>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</nowiki> (zuletzt besucht am 12.3.2020)

====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 des DICOM Objektes aus den Attributen des KOS Objektes:
#*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. 20160518 in 20160518000000).

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel 3.2.12 sourcePatientId gemappt und verwendet.

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

====Spezifikation (empfohlene Variante)====
'''sourcePatientInfo''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = concat(

$patientID, "^^^&amp;",

$oid, "&amp;ISO"

)

Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO

$name = ""

$birthtime = ""

$gender = ""

$addr = "" <pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientInfo">
<ValueList>
<Value>PID-3|$id</Value>
<Value>PID-5|$name</Value>
<Value>PID-7|$birthtime</Value>
<Value>PID-8|$gender</Value>
<Value>PID-11|$addr</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modailty 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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 entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.

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 zwei unterschiedliche Einträge in referenceIdList notwendig:

#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId)
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number)

'''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="IHE ITI TF-3"></ref>

{| 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 z.B. 1.2.40.0.34.99.999

concat

(

$id, "^^^^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

"&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>^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^^^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"

====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 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 [https://tools.ietf.org/html/rfc2045 <nowiki>RFC 2045[6]</nowiki>] und RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

[6] <nowiki>http://tools.ietf.org/html/rfc2045</nowiki>

[7] <nowiki>http://tools.ietf.org/html/rfc2049</nowiki>

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das 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 "[[urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be]]" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

====Spezifikation====

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

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.

===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 weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

==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 SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description 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"

#GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
{{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 
) 
<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-TF3].

====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). Mindestens eine Person

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

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

====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 '''''[R2]'''''.
#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 '''''[R2]'''''.
#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|4.2.15]]
|}

 

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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===
Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:
##ClinicalDocument/effectiveTime
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.
#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
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-TF3].
{{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 [R2].
#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 PCC Profil definiert in Kapitel "Medical Document Bindings" Spezialbehandlungen für gewissen 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}}

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

===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 '''''[R2]'''''.

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

TODO: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.

====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] … Lokale ID des Patienten vom einbringenden System
##d[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-TF3].

===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|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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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.
uniqueId wird als ebRIM

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===
Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommen.
{{BeginYellowBox}}
Im Rahmen von ELGA ist die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten einzubringen. Weitere andere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.
{{EndYellowBox}}

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

====Spezifikation====
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="IHE ITI TF-3"></ref>

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

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

referenceIdList wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat

(

ClinicalDocument/setId/@extension, "^^^",

ClinicalDocument/setId/@root, "^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

homeCommunityId

)

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;amp;1.2.40.0.34.99.111.1.1
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>
^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</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^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"
<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><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;2.25
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki>
&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

====Bildungsregel für den formatCodeDisplayName====
TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.

Der formatCodeDisplayName ist analog zum formatCode aus den displayNames des entsprechenden Value Sets [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS] zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels ":" (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).

'''Beispiele:'''

*'''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''
*'''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''
*'''ELGA Laborbefund, EIS Full Support v2.06+'''

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = gemäß Liste der in ELGA gültigen FormatCodes 
$codeSystem = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]
<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">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>
<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">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>

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, das das DocumentEntry repräsentiert.

Folgende Mime-Types sind für Dokumente zugelassen: 
CDA R2: '''text/xml''' 
DICOM/KOS: '''application/dicom''' 

<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 wurde ein genau entsprechendes Element 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 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 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"

====Spezifikation====

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

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.

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

<references />

==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 (2015) HL7 Implementation Guide for CDA® R2: Ärztlicher Entlassungsbrief.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.2.6], http://www.elga.gv.at

|-
|[3]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Entlassungsbrief Pflege. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.3.6], http://www.elga.gv.at
|-
| || 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

|-
|[4]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Laborbefund.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.4.6], http://www.elga.gv.at

|-
|[5]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Befund bildgebende Diagnostik.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.5.6], http://www.elga.gv.at
|-
|[6]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: e-Medikation.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.8.6], http://www.elga.gv.at

|-
|[7]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2:
|-
| || Pflegesituationsbericht (2.06) [OID 1.2.40.0.34.7.12.6], http://www.elga.gv.at

|-
|[8]|| ELGA GmbH (2015) Organisationshandbuch.
|-
| || ELGA-Bereiche und Krankenanstalten (2.2.1) [OID 1.2.40.0.34.3.1.2.1.32], http://www.elga.gv.at
|}

==Revisionsliste==
{| class="wikitable"
!Vers.
!Datum
!Änderungsgrund
|-
|0.05
|16.05.2011
|Ergebnisse aus dem technischen Online-Meeting
|-
|2.00 Beta
|12.08.2011
|Erster "Release candidate" des Dokuments für internen Review innerhalb der Arbeitsgruppe.
|-
|2.00 rc1
|30.08.2011
|Redaktionelle Überarbeitung.
|-
|2.00 FWGD
|10.10.2011
|Fertigstellung des "Final Working Group Draft". Veröffentlicht für öffentlichen Review.
|-
|2.01
|11.06.2012
|Fertigstellung der gültigen Version 2.01 "Final". Abgrenzung des Geltungsbereiches (XDSDocumentEntry), Überarbeitung "PracticeSettingCode", Hinweis zu OID eingefügt (1.2.3), Überarbeitung der "parentDocumentRelationship", Typos ausgebessert
|-
|2.01
|21.12.2012
|Layout-Anpassung
|-
|2.01a
|07.03-2013
|Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16: "dieses Dokuments" eingefügt; 363: displayNameOf($code), "Of" gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch "2"-> "Enhanced" etc.) Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt Allgemein: Typos ausgebessert
|-
|2.02
|12.08.2013
|2.3.2 Präzisierung der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessert.
|-
|2.02
|12.08.2013
|2.3.2.3 PDF/A-1a-Vorschrift hinzugefügt
|-
|2.02
|13.08.2013
|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF/A-1a-
|-
|2.02
|17.09.2013
|Typos, Formatierung und Seitenumbrüche ausgebessert
|-
|2.02a
|06.02.2014
|Beispiele in Tabelle 3 korrigiert
|-
|2.03
|26.02.2014
|Definition von ReferenceIdList eingefügt
|-
|2.03
|03.03.2014
|Definition von intendedRecipient eingefügt
|-
|2.03
|03.03.2014
|Änderungen in Tabelle 3: LegalAuthenticator – von [R] auf [R2] geändert IntendedRecipient – von "-" auf [O] geändert, für Verwendung mit XDW vorgesehen ReferenceIdList hinzugefügt Den Namen des Value Sets von "ELGA-PracticeSettingCode" auf "ELGA-PracticeSettingCode-vs" geändert
|-
|2.03.
|03.03.2014
|Anhang gelöscht: 3.1. IHE ITI-TF3, Kapitel 4.1.7 "Document Definition Metadata" 3.2. IHE PCC-TF2, Kapitel 4.1.1 "XDSDocumentEntry Metadata" 3.3. IHE XDS Data Types
|-
|2.03
|03.03.2014
|Korrekturen: ITI Version einheitlich geändert auf "(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)". 1.1.3 Hinweis auf Terminologieserver hinzugefügt Tabelle 3 angepasst: EntryUUID Beschreibung geändert patientId Beschreibung geändert
|-
|2.03
|06.03.2014
|Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId
|-
|2.03
|21.03.2014
|Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt
|-
|2.03
|26.03.2014
|Kapitel 1.4. Korrektur von Dokumentverweisen
|-
|2.03a
|28.03.2014
|Kapitel 2.1 Korrektur von Fußnotennummern
|-
|2.03a
|28.03.2014
|Kapitel 2.2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000
|-
|2.03b
|1.7.2014
|Den Namen des Value Sets von "ELGA-PracticeSetting Code-vs" auf "ELGA_Practicesetting_VS" korrigiert
|-
|2.03b
|11.07.2014
|2.3.2.5 OID in der Spezifikation ergänzt
|-
|2.03b
|11.07.2014
|2.3.6 OID in der Spezifikation ergänzt
|-
|2.03b
|05.08.2014
|2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert
|-
|2.03b
|06.08.2014
|2.1 Überblickstabelle: ParentDocumentId und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]
|-
|2.03b
|06.08.2014
|Referenzen auf CDA Implementierungsleitfäden aktualisiert
|-
| colspan="3" |Version 2.05
|-
|2.05
|03.11.2014
|EntryUUID als "ELGA-Relevant" klassifiziert. Darstellung der Übersichtstabelle geändert
|-
|2.05
|03.11.2014
|2.2.15 TypeCode: ClassificationScheme im Beispiel korrigiert von "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" (falsch) auf "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" (richtig)
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht
|-
|2.05
|19.11.2014
|2.2.2. authorPerson: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden
|-
|2.05
|19.11.2014
|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software
|-
|2.05
|24.11.2014
|2.2.1.1. Spezifikation von authorInstitution: Fall entfernt, in dem die ID des GDA unbekannt ist. Die OID des GDA ist für ELGA-CDA [M]
|-
|2.05
|26.11.2014
|2.4 ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und ELGA-Flag. Auch in 2.1 entsprechend angegeben.
|-
|2.05
|12.03.2014
|Seite 2-3: Absätze "Verbindlichkeit", "Hinweise zur Verwendung" und "Erarbeitung des Implementierungsleitfadens" hinzugefügt.
|-
| colspan="3" |Version 2.06
|-
|2.06
|19.05.2015
|1.2.2. Codesysteme und Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.
|-
|2.06
|13.10.2015
|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch
|-
|2.06
|13.10.2015
|1.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.
|-
|2.06
|07.10.2015
|1.4.3. Kapitel "Metadaten aus 'On-Demand Documents' (ODD)" eingefügt
|-
|2.06
|10.09.2015
|2.1 Tabelle 3: Beschreibung der entryUUID ergänzt
|-
|2.06
|07.10.2015
|2.1 Tabelle 3: Spalte "Optionalität IHE" gelöscht, Spalte zur Definition von On-Demand-Documents eingefügt. objectType hinzugefügt patientid als E1 "ELGA relevant" deklariert (war E2)
|-
|2.06
|30.10.2015
|2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt wird, falls mehrere ID-Elemente angegeben sind.
|-
|2.06
|19.05.2015
|2.2.5. und 2.2.15: Typos verbessert
|-
|2.06
|29.10.2015
|2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt
|-
|2.06
|21.07.2015
|2.2.10. legalAuthenticator: Hinweis, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar ist.
|-
|2.06
|08.10.2015
|2.3.7 objectType hinzugefügt
|-
| colspan="3" |'''Version 2.06.2 (Nebenversion)''' x …betrifft Implementierung (erste Spalte)
|-
|
|01.08.2016
|Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
|-
|
|18.5.2016
|1.2 Erklärung zur Verwendung von XDS Folder und SubmissionSet hinzugefügt.
|-
|
|01.08.2016
|2.1. Tabelle 3: Korrektur der Optionalität von eventCodeList auf [R2], wie im Text bei 2.2.8 angegeben
|-
|x
|14.6.2016
|creationTime, serviceStartTime, serviceStopTime: Präzisierung der Vorgaben für Datum/Zeit, sie MUSS immer entsprechen der Angabe in CDA entweder 8 oder 14-stellig angegeben werden.
|-
|
|03.08.2016
|2.2.5, 2.3.2.2, 2.3.2.5, 2.3.5, 2.3.5.1, 2.3.5.1, 2.1, 1.4, 2.2.7, 2.2.11, 2.2.15, 2.3.6, 1.4.1.2 Korrektur der Großschreibung bei normativen Vorgaben
|-
|
|05.01.2017
|2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.
|-
|
|y
|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;"
|-
|
|y
|Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
|-
|
|y
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
|-
|
|y
|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.
|-
|
|
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
|-
|
|
|Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
|-
|
|
|Kapitel "4.2.7 legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
|-
|
|
|Kapitel "4.2.4 creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
|-
|
|y
|Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
|-
|
|y
|Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
|-
|
|
|Kapitel "4.2.2.1 Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
|-
|
|y
|Kapitel "XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.
|}

ILF:XDS Metadaten (Version 3)

2021-02-10T09:23:10Z

Sjencic: /* 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)}}
{{Underconstruction}}


{{#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.7]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0
|Submitted = ELGA GmbH
|Date = Februar 2021
|Copyright = 2011-
|Status = Kommentierung
|Period = n.a.
|OID = 1.2.40.0.34.7.6.7
|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 CDA Dokumenten in der ELGA Infrastruktur notwendig sind und wie sie aus den CDA Dokumenten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden XDS-Metadaten-Guide im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für elektronische Dokumente der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti IHE ITI]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref>.

Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012), aber auch für medizinische Dokumente im österreichischen Gesundheitswesen. 
TODO: XDSi-Metadaten einfügen https://collab.dicom-austria.at/pages/viewpage.action?pageId=20709391&preview=/20709391/20709392/AnbindungBilddaten_Gesamtarchitektur.pdf

=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 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]</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]</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 [ILF:Allgemeiner_Implementierungsleitfaden_2020]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at]). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020]'''.
{{EndILFBox}}

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website TODO: [[ILF:Ambulanzbefund_Guide|Ambulanzbefund Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
* Beispieldokumente
* Schematron-Prüfregeln
* Design-Beispiele
{{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:

*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 und Hinweise===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''Hinweis:''' Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden
{{EndYellowBox}}
''Hinweis auf anderen Implementierungsleitfaden:''
{{BeginILFBox}}
'''Verweis''' Verweis auf den Allgemeinen Leitfaden:…
{{EndILFBox}}
''Themenbezogenes CDA Beispiel-Fragment im XML Format:''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>

<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"
|-
! style="text-align:left" colspan="3"| Autoren
|-
! style="text-align:left" width="10%" | Kürzel ||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person1
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Herausgeber, Projektleiter, CDA-Koordinator
|- style="background:#FFFFFF"
| SSA || ELGA GmbH || Stefan Sabutsch
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Autoren
|- style="background:#FFFFFF"
| JB|| CodeWerk Software Services and Development GmbH|| Jürgen Brandstätter
|- style="background:#FFFFFF"
| SSA|| ELGA GmbH, HL7 Austria||Stefan Sabutsch
|- style="background:#FFFFFF"
| OKU|| ELGA GmbH|| Oliver Kuttin
|- style="background:#FFFFFF"
| KHO|| Wiener Krankenanstaltenverbund|| Konrad Hölzl
|}

1 Namen ohne Titel




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

Eine IHE XDS Registry verwaltet Dokumente und macht diese 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.

Für die Registrierung von Bilddaten über XDS-I wird eine eigene Spezifikation veröffentlicht.

Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.

==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten<ref name="ALF"></ref> in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten (Metadaten der XDSDocumentEntry Objekte)
** ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 (16.9.2020) Final Text''<ref name="IHE ITI TF-3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 17.0 (2020), 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> und den "ELGA CDA Implementierungsleitfäden" erstellt.

===XDS Folder===
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
===XDS Submission Sets===
Eine weitere Profilierung des XDS SubmissionSets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.

==Hinweise zur Verwendung des Dokuments==
===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}}

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

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. Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.

====Löschen aus der Registry [ITI-62]====
Das Löschen von Dokumenten in ELGA erfolgt ausschließlich in folgenden Fällen: Löschen durch Bürger, Opt-Out, Ablauf der Aufbewahrungsdauer (nach 10 Jahren müssen Dokumente gelöscht werden). Das Löschen erfolgt i.d.R. "sicher", sodass die Daten nicht wiederhergestellt werden können, sowohl für Verweise als auch Dokumente. Über die Transaktion ITI-62 kann ein Dokument aus der Registry gelöscht werden. Beim Löschen werden sowohl der Registereintrag als auch das Dokument aus dem Repository gelöscht; falls das Löschen der Dokumente aufgrund anderer Verpflichtungen ausgeschlossen ist, sind nur die Verweise zu löschen. Siehe "Organisationshandbuch ELGA-Bereiche und Krankenanstalten" [8].

===Größenbeschränkung ===
ELGA schreibt keine Größenbeschränkung für registrierte Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1]]].

==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-TF3).<ref name="IHE ITI TF-3"></ref>

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:''' Sehen Sie auch die Vorschrift zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument 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 korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.

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

Die IHE hat im Rahmen des "Patient 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="IHE ITI"></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, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus Bilddaten (KOS)===
TODO:

===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'''
# 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"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" rowspan="2" |'''Metadaten Element'''
|'''Optionalität'''
| rowspan="2" |'''Beschreibung'''
| rowspan="2" |'''Que-'''

'''lle'''
|-
|'''ELGA'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''R'''
|Die Person, welche das Dokument verfasst hat
|<nowiki>-</nowiki>
|-
| rowspan="4" |
|authorInstitution
|'''R'''
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|A/K
|-
|authorPerson
|'''R2'''
|Daten der Person

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

z.B.: 55113-5 "KOSObjekte"
|A
|-
| colspan="2" |'''confidentialityCode'''
|'''R'''
|Vertraulichkeitscode. Fester Wert "N"
|A
|-
| colspan="2" |'''creationTime'''
|'''R'''
|Zeitpunkt der Dokumentenerstellung
|K
|-
| colspan="2" |'''eventCodeList'''
|'''R'''
|Liste von Codes von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''eventCodeDisplayNameList'''
|'''R2'''
|Liste von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''intendedRecipient'''
|'''X'''
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
| -
|-
| colspan="2" |'''languageCode'''
|'''R'''
|Sprachcode. Fester Wert "de-AT"
|A
|-
| colspan="2" |'''legalAuthenticator'''
|'''X'''
|Rechtlicher Unterzeichner
| -
|-
| colspan="2" |'''serviceStartTime'''
|'''R'''
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|K
|-
| colspan="2" |'''serviceStopTime'''
|'''X'''
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
| -
|-
| colspan="2" |'''sourcePatientId'''
|'''R'''
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''sourcePatientInfo'''
|'''R'''
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''Title'''
|'''R'''
|Titel des Dokuments
|A/K
|-
| colspan="2" |'''typeCode'''
|'''R'''
|Objekttyp (Unterklasse)

codierter Wert
|A
|-
| colspan="2" |'''uniqueId'''
|'''R'''
|Global eindeutige ID des Objektes

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

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

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

 



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

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

TODO: urn:ihe:iti:xds:2015:encounterId als referenceIdList Eintrag ergänzen?

{| 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 1: Legende zur Spalte "Quelle" der folgenden Tabelle''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| 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="45%" |'''Beschreibung '''|| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
|- style="background:#CBD7F1"
|'''SD9'''||'''OD10'''
|- 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)||'''R'''||'''R'''||Die Person, welche das Dokument verfasst hat||-
|- style="background:white"
| ||authorInstitution||'''R'''||'''R'''||ID der Organisation, der die Person angehört. (OID aus dem GDA-Index)||C
|- style="background:white"
| ||authorPerson||'''R'''||'''R'''||Daten der Person (Name, ID, etc.)||C
|- style="background:white"
| ||authorRole||'''R2'''||'''X'''||Rolle der Person||C
|- style="background:white"
| ||authorSpeciality||'''R2'''||'''X'''||Fachrichtung der Person||C
|- style="background:white"
| colspan="2" |'''classCode'''||'''R'''||'''R'''||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"||C
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''R'''||'''X'''||Vertraulichkeitscode des Dokuments||C
|- style="background:white"
| colspan="2" |'''creationTime'''||'''R'''||'''R'''||Zeitpunkt der Dokumentenerstellung||C
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R2'''||'''R2'''||Liste von Gesundheitsdienstleistungen||C
|-
| colspan="2" |'''formatCode'''
|'''R'''
|'''R'''
|Format des Dokumenteninhalts
|C
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O'''||'''X'''||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C
|- style="background:white"
| colspan="2" |'''languageCode'''||'''R'''||'''R'''||Sprachcode des Dokuments z.B.: "de-AT"||C
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R2'''||'''X'''||Rechtlicher Unterzeichner des Dokuments||C
|-
| colspan="2" |'''practiceSettingCode'''
|'''R'''
|'''R'''
|Fachliche Zuordnung des Dokuments
|C
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R2'''||'''O'''||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R2'''||'''O'''||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung||C
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''R'''||'''R'''||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH||C
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''X'''||'''X'''||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C
|- style="background:white"
| colspan="2" |'''Title'''||'''R'''||'''R'''||Titel des Dokuments||C
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''R'''||'''R'''||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"||C
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''R'''||'''R'''||Global eindeutige ID des Dokuments||C
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''R'''||'''O'''||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert||C
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''R'''||'''R'''||Klassifizierung des GDA
|C

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
|- style="background:white"
| colspan="2" |'''availabilityStatus'''||'''R'''||'''R'''||Gültigkeit des Dokuments||E1
|- style="background:white"
| colspan="2" |'''mimeType'''||'''R'''||'''R'''||Mime Type des Dokuments z.B.: "text/xml" für CDA||E1
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O'''||'''O'''||Verweis auf ein referenziertes Dokument||E1
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O'''||'''O'''||Typ der Relation zu dem referenzierten Dokument. z.B.: RPLC, XFRM||E1
|- style="background:white"
| colspan="2" |'''entryUUID'''||'''R'''||'''R'''||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)||E1
|- style="background:white"
| colspan="2" |'''objectType'''||'''R'''||'''R'''||Typ des DocumentEntries (SD oder ODD)||E1
|- style="background:white"
| colspan="2" |'''comments'''||'''O'''||'''O'''||Kommentar zum Dokument||E2
|- style="background:white"
| colspan="2" |'''patientId'''||'''R'''||'''R'''||Patienten-ID in der XDS Affinity Domain||E1

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|- style="background:white"
| colspan="2" |'''hash'''||'''R'''||'''X'''||Hash Wert des Dokuments. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''homeCommunityId'''||'''R'''||'''R'''||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.||A
|- style="background:white"
| colspan="2" |'''repositoryUniqueId '''||'''R'''||'''R'''||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''size'''||'''R'''||'''X'''||Größe des Dokuments in Bytes. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''URI'''14||'''-'''||'''-'''||'''Wird in XDS nicht verwendet'''||A
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|- style="background:white"
| colspan="2" |'''elgaFlag'''||'''R'''||'''R'''||Kennzeichnet ein Dokument als "ELGA-Dokument"||B
|- style="background:white"
| colspan="2" |'''elgaHash'''||'''R'''||'''R'''||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B
|}
''Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)''

9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht. 
10 OD: "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 SubmissionSets übereinstimmen. 
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. 
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein. 
14 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.


=XDS-I Metadaten für DICOM KOS Objekte=
==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

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.

{| class="wikitable"
|'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

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

'''im KOS'''
|'''Beschreibung'''
|-
| colspan="5" |author
|-
|author.authorInstitution
|R
|
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl den Namen als auch die OID der Institution im 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.
|-
| colspan="5" |Die die Studie durchführende Person ist als author anzugeben:
|-
|author.authorPerson
|R2
|(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.
|-
|
|
|'''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.
|-
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|-
|author.authorPerson
|R2
|(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.
|-
|creationTime
|R
|(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.
|-
|eventCodeList
|R
|
|
|Enthält den APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|eventCodeListDisplayNameList
|R2
|
|
|Enthält den Display Name des APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|serviceStartTime
|R
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|-
|sourcePatientId
|R
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|-
|sourcePatientInfo
|R
|(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.
|-
|title
|R
|(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".
 
|-
|uniqueId
|R
|
|(0008,0018)
|Die SOP Instance UID des KOS
|-
| colspan="4" |referenceIdList
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|-
|value mit CXi.5 =

"<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>"
|R
|(0020,000D) oder ein vergleich-bares Attribut
|(0020,000D) oder ein vergleich-bares 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 Kapitel 8.2.2.
|-
|value mit CXi.5 =

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
|O
|(0008,0050) oder ein vergleich-bares 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.
|-
|comments
|O
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

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 Radiology Technical Framework, vol2, rev. 19, "4.68.4.1.2.3.2 DocumentEntry Metadata" sowie IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. 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 kann

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

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

$id ... OID der Organisation aus dem GDA-Index

concat( 
$name,"^^^^^^^^^", 
$id 
) 
<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-TF3].
====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[[#%20ftn1|[1]]], wenn vorhanden
#*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) ----[[#%20ftnref1|[1]]] Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den DICOM Attribut Modality der Studie abgleitet werden
#*Modalität[[#%20ftn1|[2]]]: Attribut "Modality", (0008,0060)
#*Hersteller: Attribut "Manufacturer", (0008,0070)
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</nowiki>

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

$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>2323^MusterDoc^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
=====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-TF3].

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objektation 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|4.2.15]]
|}

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "[https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen hl7-austria-Dokumentenklassen]" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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 "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]".

====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 registrieren 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)
#Sollten 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''[[#%20ftn1|[3]]] berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

[[#%20ftnref1|[3]]] <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</nowiki>
====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 +(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. 20160518 in 20160518000000).

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-TF3].{{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".[[# ftn4|[4]]])
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.
----[[# ftnref4|[4]]] DICOM Austria: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten", 22.01.2020, <nowiki>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</nowiki> (zuletzt besucht am 12.3.2020)

====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 des DICOM Objektes aus den Attributen des KOS Objektes:
#*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. 20160518 in 20160518000000).

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel 3.2.12 sourcePatientId gemappt und verwendet.

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

====Spezifikation (empfohlene Variante)====
'''sourcePatientInfo''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = concat(

$patientID, "^^^&amp;",

$oid, "&amp;ISO"

)

Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO

$name = ""

$birthtime = ""

$gender = ""

$addr = "" <pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientInfo">
<ValueList>
<Value>PID-3|$id</Value>
<Value>PID-5|$name</Value>
<Value>PID-7|$birthtime</Value>
<Value>PID-8|$gender</Value>
<Value>PID-11|$addr</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modailty 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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 entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.

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 zwei unterschiedliche Einträge in referenceIdList notwendig:

#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId)
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number)

'''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="IHE ITI TF-3"></ref>

{| 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 z.B. 1.2.40.0.34.99.999

concat

(

$id, "^^^^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

"&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>^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^^^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"

====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 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 [https://tools.ietf.org/html/rfc2045 <nowiki>RFC 2045[6]</nowiki>] und RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

[6] <nowiki>http://tools.ietf.org/html/rfc2045</nowiki>

[7] <nowiki>http://tools.ietf.org/html/rfc2049</nowiki>

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das 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 "[[urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be]]" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

====Spezifikation====

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

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.

===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 weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

==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 SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description 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"

#GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
{{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 
) 
<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-TF3].

====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). Mindestens eine Person

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

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

====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 '''''[R2]'''''.
#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 '''''[R2]'''''.
#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|4.2.15]]
|}

 

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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===
Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:
##ClinicalDocument/effectiveTime
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.
#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
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-TF3].
{{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 [R2].
#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 PCC Profil definiert in Kapitel "Medical Document Bindings" Spezialbehandlungen für gewissen 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}}

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

===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 '''''[R2]'''''.

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

TODO: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.

====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] … Lokale ID des Patienten vom einbringenden System
##d[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-TF3].

===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|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 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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.
uniqueId wird als ebRIM

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===
Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommen.
{{BeginYellowBox}}
Im Rahmen von ELGA ist die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten einzubringen. Weitere andere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.
{{EndYellowBox}}

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

====Spezifikation====
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="IHE ITI TF-3"></ref>

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

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

referenceIdList wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat

(

ClinicalDocument/setId/@extension, "^^^",

ClinicalDocument/setId/@root, "^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

homeCommunityId

)

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;amp;1.2.40.0.34.99.111.1.1
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>
^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</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^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"
<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><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;2.25
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki>
&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

====Bildungsregel für den formatCodeDisplayName====
TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.

Der formatCodeDisplayName ist analog zum formatCode aus den displayNames des entsprechenden Value Sets [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS] zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels ":" (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).

'''Beispiele:'''

*'''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''
*'''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''
*'''ELGA Laborbefund, EIS Full Support v2.06+'''

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = gemäß Liste der in ELGA gültigen FormatCodes 
$codeSystem = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]
<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">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>
<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">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>

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, das das DocumentEntry repräsentiert.

Folgende Mime-Types sind für Dokumente zugelassen: 
CDA R2: '''text/xml''' 
DICOM/KOS: '''application/dicom''' 

<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 wurde ein genau entsprechendes Element 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 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 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"

====Spezifikation====

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

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.

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

<references />

==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 (2015) HL7 Implementation Guide for CDA® R2: Ärztlicher Entlassungsbrief.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.2.6], http://www.elga.gv.at

|-
|[3]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Entlassungsbrief Pflege. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.3.6], http://www.elga.gv.at
|-
| || 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

|-
|[4]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Laborbefund.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.4.6], http://www.elga.gv.at

|-
|[5]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Befund bildgebende Diagnostik.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.5.6], http://www.elga.gv.at
|-
|[6]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: e-Medikation.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.8.6], http://www.elga.gv.at

|-
|[7]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2:
|-
| || Pflegesituationsbericht (2.06) [OID 1.2.40.0.34.7.12.6], http://www.elga.gv.at

|-
|[8]|| ELGA GmbH (2015) Organisationshandbuch.
|-
| || ELGA-Bereiche und Krankenanstalten (2.2.1) [OID 1.2.40.0.34.3.1.2.1.32], http://www.elga.gv.at
|}

==Revisionsliste==
{| class="wikitable"
!Vers.
!Datum
!Änderungsgrund
|-
|0.05
|16.05.2011
|Ergebnisse aus dem technischen Online-Meeting
|-
|2.00 Beta
|12.08.2011
|Erster "Release candidate" des Dokuments für internen Review innerhalb der Arbeitsgruppe.
|-
|2.00 rc1
|30.08.2011
|Redaktionelle Überarbeitung.
|-
|2.00 FWGD
|10.10.2011
|Fertigstellung des "Final Working Group Draft". Veröffentlicht für öffentlichen Review.
|-
|2.01
|11.06.2012
|Fertigstellung der gültigen Version 2.01 "Final". Abgrenzung des Geltungsbereiches (XDSDocumentEntry), Überarbeitung "PracticeSettingCode", Hinweis zu OID eingefügt (1.2.3), Überarbeitung der "parentDocumentRelationship", Typos ausgebessert
|-
|2.01
|21.12.2012
|Layout-Anpassung
|-
|2.01a
|07.03-2013
|Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16: "dieses Dokuments" eingefügt; 363: displayNameOf($code), "Of" gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch "2"-> "Enhanced" etc.) Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt Allgemein: Typos ausgebessert
|-
|2.02
|12.08.2013
|2.3.2 Präzisierung der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessert.
|-
|2.02
|12.08.2013
|2.3.2.3 PDF/A-1a-Vorschrift hinzugefügt
|-
|2.02
|13.08.2013
|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF/A-1a-
|-
|2.02
|17.09.2013
|Typos, Formatierung und Seitenumbrüche ausgebessert
|-
|2.02a
|06.02.2014
|Beispiele in Tabelle 3 korrigiert
|-
|2.03
|26.02.2014
|Definition von ReferenceIdList eingefügt
|-
|2.03
|03.03.2014
|Definition von intendedRecipient eingefügt
|-
|2.03
|03.03.2014
|Änderungen in Tabelle 3: LegalAuthenticator – von [R] auf [R2] geändert IntendedRecipient – von "-" auf [O] geändert, für Verwendung mit XDW vorgesehen ReferenceIdList hinzugefügt Den Namen des Value Sets von "ELGA-PracticeSettingCode" auf "ELGA-PracticeSettingCode-vs" geändert
|-
|2.03.
|03.03.2014
|Anhang gelöscht: 3.1. IHE ITI-TF3, Kapitel 4.1.7 "Document Definition Metadata" 3.2. IHE PCC-TF2, Kapitel 4.1.1 "XDSDocumentEntry Metadata" 3.3. IHE XDS Data Types
|-
|2.03
|03.03.2014
|Korrekturen: ITI Version einheitlich geändert auf "(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)". 1.1.3 Hinweis auf Terminologieserver hinzugefügt Tabelle 3 angepasst: EntryUUID Beschreibung geändert patientId Beschreibung geändert
|-
|2.03
|06.03.2014
|Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId
|-
|2.03
|21.03.2014
|Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt
|-
|2.03
|26.03.2014
|Kapitel 1.4. Korrektur von Dokumentverweisen
|-
|2.03a
|28.03.2014
|Kapitel 2.1 Korrektur von Fußnotennummern
|-
|2.03a
|28.03.2014
|Kapitel 2.2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000
|-
|2.03b
|1.7.2014
|Den Namen des Value Sets von "ELGA-PracticeSetting Code-vs" auf "ELGA_Practicesetting_VS" korrigiert
|-
|2.03b
|11.07.2014
|2.3.2.5 OID in der Spezifikation ergänzt
|-
|2.03b
|11.07.2014
|2.3.6 OID in der Spezifikation ergänzt
|-
|2.03b
|05.08.2014
|2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert
|-
|2.03b
|06.08.2014
|2.1 Überblickstabelle: ParentDocumentId und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]
|-
|2.03b
|06.08.2014
|Referenzen auf CDA Implementierungsleitfäden aktualisiert
|-
| colspan="3" |Version 2.05
|-
|2.05
|03.11.2014
|EntryUUID als "ELGA-Relevant" klassifiziert. Darstellung der Übersichtstabelle geändert
|-
|2.05
|03.11.2014
|2.2.15 TypeCode: ClassificationScheme im Beispiel korrigiert von "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" (falsch) auf "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" (richtig)
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht
|-
|2.05
|19.11.2014
|2.2.2. authorPerson: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden
|-
|2.05
|19.11.2014
|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software
|-
|2.05
|24.11.2014
|2.2.1.1. Spezifikation von authorInstitution: Fall entfernt, in dem die ID des GDA unbekannt ist. Die OID des GDA ist für ELGA-CDA [M]
|-
|2.05
|26.11.2014
|2.4 ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und ELGA-Flag. Auch in 2.1 entsprechend angegeben.
|-
|2.05
|12.03.2014
|Seite 2-3: Absätze "Verbindlichkeit", "Hinweise zur Verwendung" und "Erarbeitung des Implementierungsleitfadens" hinzugefügt.
|-
| colspan="3" |Version 2.06
|-
|2.06
|19.05.2015
|1.2.2. Codesysteme und Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.
|-
|2.06
|13.10.2015
|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch
|-
|2.06
|13.10.2015
|1.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.
|-
|2.06
|07.10.2015
|1.4.3. Kapitel "Metadaten aus 'On-Demand Documents' (ODD)" eingefügt
|-
|2.06
|10.09.2015
|2.1 Tabelle 3: Beschreibung der entryUUID ergänzt
|-
|2.06
|07.10.2015
|2.1 Tabelle 3: Spalte "Optionalität IHE" gelöscht, Spalte zur Definition von On-Demand-Documents eingefügt. objectType hinzugefügt patientid als E1 "ELGA relevant" deklariert (war E2)
|-
|2.06
|30.10.2015
|2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt wird, falls mehrere ID-Elemente angegeben sind.
|-
|2.06
|19.05.2015
|2.2.5. und 2.2.15: Typos verbessert
|-
|2.06
|29.10.2015
|2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt
|-
|2.06
|21.07.2015
|2.2.10. legalAuthenticator: Hinweis, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar ist.
|-
|2.06
|08.10.2015
|2.3.7 objectType hinzugefügt
|-
| colspan="3" |'''Version 2.06.2 (Nebenversion)''' x …betrifft Implementierung (erste Spalte)
|-
|
|01.08.2016
|Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
|-
|
|18.5.2016
|1.2 Erklärung zur Verwendung von XDS Folder und SubmissionSet hinzugefügt.
|-
|
|01.08.2016
|2.1. Tabelle 3: Korrektur der Optionalität von eventCodeList auf [R2], wie im Text bei 2.2.8 angegeben
|-
|x
|14.6.2016
|creationTime, serviceStartTime, serviceStopTime: Präzisierung der Vorgaben für Datum/Zeit, sie MUSS immer entsprechen der Angabe in CDA entweder 8 oder 14-stellig angegeben werden.
|-
|
|03.08.2016
|2.2.5, 2.3.2.2, 2.3.2.5, 2.3.5, 2.3.5.1, 2.3.5.1, 2.1, 1.4, 2.2.7, 2.2.11, 2.2.15, 2.3.6, 1.4.1.2 Korrektur der Großschreibung bei normativen Vorgaben
|-
|
|05.01.2017
|2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.
|-
|
|y
|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;"
|-
|
|y
|Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
|-
|
|y
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
|-
|
|y
|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.
|-
|
|
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
|-
|
|
|Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
|-
|
|
|Kapitel "4.2.7 legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
|-
|
|
|Kapitel "4.2.4 creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
|-
|
|y
|Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
|-
|
|y
|Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
|-
|
|
|Kapitel "4.2.2.1 Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
|-
|
|y
|Kapitel "XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.
|}

ILF:XDS Metadaten (Version 3)

2021-02-10T09:20:03Z

Sjencic: /* 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)}}
{{Underconstruction}}


{{#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.7]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0
|Submitted = ELGA GmbH
|Date = Februar 2021
|Copyright = 2011-
|Status = Kommentierung
|Period = n.a.
|OID = 1.2.40.0.34.7.6.7
|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 CDA Dokumenten in der ELGA Infrastruktur notwendig sind und wie sie aus den CDA Dokumenten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden XDS-Metadaten-Guide im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für elektronische Dokumente der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti IHE ITI]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref>.

Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012), aber auch für medizinische Dokumente im österreichischen Gesundheitswesen. 
TODO: XDSi-Metadaten einfügen https://collab.dicom-austria.at/pages/viewpage.action?pageId=20709391&preview=/20709391/20709392/AnbindungBilddaten_Gesamtarchitektur.pdf

=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 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]</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]</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 [ILF:Allgemeiner_Implementierungsleitfaden_2020]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at]). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020]'''.
{{EndILFBox}}

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website TODO: [[ILF:Ambulanzbefund_Guide|Ambulanzbefund Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
* Beispieldokumente
* Schematron-Prüfregeln
* Design-Beispiele
{{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:

*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 und Hinweise===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''Hinweis:''' Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden
{{EndYellowBox}}
''Hinweis auf anderen Implementierungsleitfaden:''
{{BeginILFBox}}
'''Verweis''' Verweis auf den Allgemeinen Leitfaden:…
{{EndILFBox}}
''Themenbezogenes CDA Beispiel-Fragment im XML Format:''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>

<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"
|-
! style="text-align:left" colspan="3"| Autoren
|-
! style="text-align:left" width="10%" | Kürzel ||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person1
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Herausgeber, Projektleiter, CDA-Koordinator
|- style="background:#FFFFFF"
| SSA || ELGA GmbH || Stefan Sabutsch
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Autoren
|- style="background:#FFFFFF"
| JB|| CodeWerk Software Services and Development GmbH|| Jürgen Brandstätter
|- style="background:#FFFFFF"
| SSA|| ELGA GmbH, HL7 Austria||Stefan Sabutsch
|- style="background:#FFFFFF"
| OKU|| ELGA GmbH|| Oliver Kuttin
|- style="background:#FFFFFF"
| KHO|| Wiener Krankenanstaltenverbund|| Konrad Hölzl
|}

1 Namen ohne Titel




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

Eine IHE XDS Registry verwaltet Dokumente und macht diese 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.

Für die Registrierung von Bilddaten über XDS-I wird eine eigene Spezifikation veröffentlicht.

Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.

==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten<ref name="ALF"></ref> in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten (Metadaten der XDSDocumentEntry Objekte)
** ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 (16.9.2020) Final Text''<ref name="IHE ITI TF-3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 17.0 (2020), 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> und den "ELGA CDA Implementierungsleitfäden" erstellt.

===XDS Folder===
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
===XDS Submission Sets===
Eine weitere Profilierung des XDS SubmissionSets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.

==Hinweise zur Verwendung des Dokuments==
===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}}

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

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. Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.

====Löschen aus der Registry [ITI-62]====
Das Löschen von Dokumenten in ELGA erfolgt ausschließlich in folgenden Fällen: Löschen durch Bürger, Opt-Out, Ablauf der Aufbewahrungsdauer (nach 10 Jahren müssen Dokumente gelöscht werden). Das Löschen erfolgt i.d.R. "sicher", sodass die Daten nicht wiederhergestellt werden können, sowohl für Verweise als auch Dokumente. Über die Transaktion ITI-62 kann ein Dokument aus der Registry gelöscht werden. Beim Löschen werden sowohl der Registereintrag als auch das Dokument aus dem Repository gelöscht; falls das Löschen der Dokumente aufgrund anderer Verpflichtungen ausgeschlossen ist, sind nur die Verweise zu löschen. Siehe "Organisationshandbuch ELGA-Bereiche und Krankenanstalten" [8].

===Größenbeschränkung ===
ELGA schreibt keine Größenbeschränkung für registrierte Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1]]].

==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-TF3).<ref name="IHE ITI TF-3"></ref>

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:''' Sehen Sie auch die Vorschrift zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument 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 korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.

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

Die IHE hat im Rahmen des "Patient 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="IHE ITI"></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, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus Bilddaten (KOS)===
TODO:

===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'''
# 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"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" rowspan="2" |'''Metadaten Element'''
|'''Optionalität'''
| rowspan="2" |'''Beschreibung'''
| rowspan="2" |'''Que-'''

'''lle'''
|-
|'''ELGA'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''R'''
|Die Person, welche das Dokument verfasst hat
|<nowiki>-</nowiki>
|-
| rowspan="4" |
|authorInstitution
|'''R'''
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|A/K
|-
|authorPerson
|'''R2'''
|Daten der Person

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

z.B.: 55113-5 "KOSObjekte"
|A
|-
| colspan="2" |'''confidentialityCode'''
|'''R'''
|Vertraulichkeitscode. Fester Wert "N"
|A
|-
| colspan="2" |'''creationTime'''
|'''R'''
|Zeitpunkt der Dokumentenerstellung
|K
|-
| colspan="2" |'''eventCodeList'''
|'''R'''
|Liste von Codes von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''eventCodeDisplayNameList'''
|'''R2'''
|Liste von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''intendedRecipient'''
|'''X'''
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
| -
|-
| colspan="2" |'''languageCode'''
|'''R'''
|Sprachcode. Fester Wert "de-AT"
|A
|-
| colspan="2" |'''legalAuthenticator'''
|'''X'''
|Rechtlicher Unterzeichner
| -
|-
| colspan="2" |'''serviceStartTime'''
|'''R'''
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|K
|-
| colspan="2" |'''serviceStopTime'''
|'''X'''
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
| -
|-
| colspan="2" |'''sourcePatientId'''
|'''R'''
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''sourcePatientInfo'''
|'''R'''
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''Title'''
|'''R'''
|Titel des Dokuments
|A/K
|-
| colspan="2" |'''typeCode'''
|'''R'''
|Objekttyp (Unterklasse)

codierter Wert
|A
|-
| colspan="2" |'''uniqueId'''
|'''R'''
|Global eindeutige ID des Objektes

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

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

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

 



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

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

TODO: urn:ihe:iti:xds:2015:encounterId als referenceIdList Eintrag ergänzen?

{| 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 1: Legende zur Spalte "Quelle" der folgenden Tabelle''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| 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="45%" |'''Beschreibung '''|| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
|- style="background:#CBD7F1"
|'''SD9'''||'''OD10'''
|- 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)||'''R'''||'''R'''||Die Person, welche das Dokument verfasst hat||-
|- style="background:white"
| ||authorInstitution||'''R'''||'''R'''||ID der Organisation, der die Person angehört. (OID aus dem GDA-Index)||C
|- style="background:white"
| ||authorPerson||'''R'''||'''R'''||Daten der Person (Name, ID, etc.)||C
|- style="background:white"
| ||authorRole||'''R2'''||'''X'''||Rolle der Person||C
|- style="background:white"
| ||authorSpeciality||'''R2'''||'''X'''||Fachrichtung der Person||C
|- style="background:white"
| colspan="2" |'''classCode'''||'''R'''||'''R'''||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"||C
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''R'''||'''X'''||Vertraulichkeitscode des Dokuments||C
|- style="background:white"
| colspan="2" |'''creationTime'''||'''R'''||'''R'''||Zeitpunkt der Dokumentenerstellung||C
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R2'''||'''R2'''||Liste von Gesundheitsdienstleistungen||C
|-
| colspan="2" |'''formatCode'''
|'''R'''
|'''R'''
|Format des Dokumenteninhalts
|C
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O'''||'''X'''||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C
|- style="background:white"
| colspan="2" |'''languageCode'''||'''R'''||'''R'''||Sprachcode des Dokuments z.B.: "de-AT"||C
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R2'''||'''X'''||Rechtlicher Unterzeichner des Dokuments||C
|-
| colspan="2" |'''practiceSettingCode'''
|'''R'''
|'''R'''
|Fachliche Zuordnung des Dokuments
|C
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R2'''||'''O'''||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R2'''||'''O'''||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung||C
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''R'''||'''R'''||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH||C
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''X'''||'''X'''||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C
|- style="background:white"
| colspan="2" |'''Title'''||'''R'''||'''R'''||Titel des Dokuments||C
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''R'''||'''R'''||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"||C
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''R'''||'''R'''||Global eindeutige ID des Dokuments||C
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''R'''||'''O'''||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert||C
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''R'''||'''R'''||Klassifizierung des GDA
|C

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
|- style="background:white"
| colspan="2" |'''availabilityStatus'''||'''R'''||'''R'''||Gültigkeit des Dokuments||E1
|- style="background:white"
| colspan="2" |'''mimeType'''||'''R'''||'''R'''||Mime Type des Dokuments z.B.: "text/xml" für CDA||E1
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O'''||'''O'''||Verweis auf ein referenziertes Dokument||E1
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O'''||'''O'''||Typ der Relation zu dem referenzierten Dokument. z.B.: RPLC, XFRM||E1
|- style="background:white"
| colspan="2" |'''entryUUID'''||'''R'''||'''R'''||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)||E1
|- style="background:white"
| colspan="2" |'''objectType'''||'''R'''||'''R'''||Typ des DocumentEntries (SD oder ODD)||E1
|- style="background:white"
| colspan="2" |'''comments'''||'''O'''||'''O'''||Kommentar zum Dokument||E2
|- style="background:white"
| colspan="2" |'''patientId'''||'''R'''||'''R'''||Patienten-ID in der XDS Affinity Domain||E1

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|- style="background:white"
| colspan="2" |'''hash'''||'''R'''||'''X'''||Hash Wert des Dokuments. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''homeCommunityId'''||'''R'''||'''R'''||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.||A
|- style="background:white"
| colspan="2" |'''repositoryUniqueId '''||'''R'''||'''R'''||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''size'''||'''R'''||'''X'''||Größe des Dokuments in Bytes. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''URI'''14||'''-'''||'''-'''||'''Wird in XDS nicht verwendet'''||A
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|- style="background:white"
| colspan="2" |'''elgaFlag'''||'''R'''||'''R'''||Kennzeichnet ein Dokument als "ELGA-Dokument"||B
|- style="background:white"
| colspan="2" |'''elgaHash'''||'''R'''||'''R'''||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B
|}
''Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)''

9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht. 
10 OD: "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 SubmissionSets übereinstimmen. 
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. 
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein. 
14 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.


=XDS-I Metadaten für DICOM KOS Objekte=
==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

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.

{| class="wikitable"
|'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

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

'''im KOS'''
|'''Beschreibung'''
|-
| colspan="5" |author
|-
|author.authorInstitution
|R
|
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl den Namen als auch die OID der Institution im 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.
|-
| colspan="5" |Die die Studie durchführende Person ist als author anzugeben:
|-
|author.authorPerson
|R2
|(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.
|-
|
|
|'''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.
|-
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|-
|author.authorPerson
|R2
|(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.
|-
|creationTime
|R
|(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.
|-
|eventCodeList
|R
|
|
|Enthält den APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|eventCodeListDisplayNameList
|R2
|
|
|Enthält den Display Name des APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|serviceStartTime
|R
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|-
|sourcePatientId
|R
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|-
|sourcePatientInfo
|R
|(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.
|-
|title
|R
|(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".
 
|-
|uniqueId
|R
|
|(0008,0018)
|Die SOP Instance UID des KOS
|-
| colspan="4" |referenceIdList
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|-
|value mit CXi.5 =

"<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>"
|R
|(0020,000D) oder ein vergleich-bares Attribut
|(0020,000D) oder ein vergleich-bares 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 Kapitel 8.2.2.
|-
|value mit CXi.5 =

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
|O
|(0008,0050) oder ein vergleich-bares 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.
|-
|comments
|O
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

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 Radiology Technical Framework, vol2, rev. 19, "4.68.4.1.2.3.2 DocumentEntry Metadata" sowie IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. 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 kann

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

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

$id ... OID der Organisation aus dem GDA-Index

concat( 
$name,"^^^^^^^^^", 
$id 
) 
<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-TF3].
====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[[#%20ftn1|[1]]], wenn vorhanden
#*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) ----[[#%20ftnref1|[1]]] Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den DICOM Attribut Modality der Studie abgleitet werden
#*Modalität[[#%20ftn1|[2]]]: Attribut "Modality", (0008,0060)
#*Hersteller: Attribut "Manufacturer", (0008,0070)
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</nowiki>

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

$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>2323^MusterDoc^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
=====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-TF3].

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objektation 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|4.2.15]]
|}

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "[https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen hl7-austria-Dokumentenklassen]" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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 "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]".

====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 registrieren 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)
#Sollten 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''[[#%20ftn1|[3]]] berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

[[#%20ftnref1|[3]]] <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</nowiki>
====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 +(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. 20160518 in 20160518000000).

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-TF3].{{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".[[# ftn4|[4]]])
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.
----[[# ftnref4|[4]]] DICOM Austria: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten", 22.01.2020, <nowiki>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</nowiki> (zuletzt besucht am 12.3.2020)

====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 des DICOM Objektes aus den Attributen des KOS Objektes:
#*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. 20160518 in 20160518000000).

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel 3.2.12 sourcePatientId gemappt und verwendet.

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

====Spezifikation (empfohlene Variante)====
'''sourcePatientInfo''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = concat(

$patientID, "^^^&amp;",

$oid, "&amp;ISO"

)

Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO

$name = ""

$birthtime = ""

$gender = ""

$addr = "" <pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientInfo">
<ValueList>
<Value>PID-3|$id</Value>
<Value>PID-5|$name</Value>
<Value>PID-7|$birthtime</Value>
<Value>PID-8|$gender</Value>
<Value>PID-11|$addr</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modailty 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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 entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.

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 zwei unterschiedliche Einträge in referenceIdList notwendig:

#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId)
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number)

'''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="IHE ITI TF-3"></ref>

{| 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 z.B. 1.2.40.0.34.99.999

concat

(

$id, "^^^^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

"&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>^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^^^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"

====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 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 [https://tools.ietf.org/html/rfc2045 <nowiki>RFC 2045[6]</nowiki>] und RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

[6] <nowiki>http://tools.ietf.org/html/rfc2045</nowiki>

[7] <nowiki>http://tools.ietf.org/html/rfc2049</nowiki>

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das 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 "[[urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be]]" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

====Spezifikation====

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

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.

===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 weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

==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 SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description 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"

#GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
{{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 
) 
<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-TF3].

====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). Mindestens eine Person

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

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

====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 '''''[R2]'''''.
#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 '''''[R2]'''''.
#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|4.2.15]]
|}

 

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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===
Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:
##ClinicalDocument/effectiveTime
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.
#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
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-TF3].
{{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 [R2].
#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 PCC Profil definiert in Kapitel "Medical Document Bindings" Spezialbehandlungen für gewissen 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}}

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

===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 '''''[R2]'''''.

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

TODO: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.

====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] … Lokale ID des Patienten vom einbringenden System
##d[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-TF3].

===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|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 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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.
uniqueId wird als ebRIM

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===
Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommen.
{{BeginYellowBox}}
Im Rahmen von ELGA ist die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten einzubringen. Weitere andere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.
{{EndYellowBox}}

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

====Spezifikation====
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="IHE ITI TF-3"></ref>

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

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

referenceIdList wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat

(

ClinicalDocument/setId/@extension, "^^^",

ClinicalDocument/setId/@root, "^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

homeCommunityId

)

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;amp;1.2.40.0.34.99.111.1.1
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>
^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</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^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"
<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><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;2.25
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki>
&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

====Bildungsregel für den formatCodeDisplayName====
TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.

Der formatCodeDisplayName ist analog zum formatCode aus den displayNames des entsprechenden Value Sets [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS] zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels ":" (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).

'''Beispiele:'''

*'''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''
*'''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''
*'''ELGA Laborbefund, EIS Full Support v2.06+'''

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = gemäß Liste der in ELGA gültigen FormatCodes 
$codeSystem = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]
<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">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>
<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">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>

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, das das DocumentEntry repräsentiert.

Folgende Mime-Types sind für Dokumente zugelassen: 
CDA R2: '''text/xml''' 
DICOM/KOS: '''application/dicom''' 

<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 wurde ein genau entsprechendes Element 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 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 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"

====Spezifikation====

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

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.

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

<references />

==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 (2015) HL7 Implementation Guide for CDA® R2: Ärztlicher Entlassungsbrief.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.2.6], http://www.elga.gv.at

|-
|[3]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Entlassungsbrief Pflege. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.3.6], http://www.elga.gv.at
|-
| || 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

|-
|[4]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Laborbefund.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.4.6], http://www.elga.gv.at

|-
|[5]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Befund bildgebende Diagnostik.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.5.6], http://www.elga.gv.at
|-
|[6]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: e-Medikation.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.8.6], http://www.elga.gv.at

|-
|[7]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2:
|-
| || Pflegesituationsbericht (2.06) [OID 1.2.40.0.34.7.12.6], http://www.elga.gv.at

|-
|[8]|| ELGA GmbH (2015) Organisationshandbuch.
|-
| || ELGA-Bereiche und Krankenanstalten (2.2.1) [OID 1.2.40.0.34.3.1.2.1.32], http://www.elga.gv.at
|}

==Revisionsliste==
{| class="wikitable"
!Vers.
!Datum
!Änderungsgrund
|-
|0.05
|16.05.2011
|Ergebnisse aus dem technischen Online-Meeting
|-
|2.00 Beta
|12.08.2011
|Erster "Release candidate" des Dokuments für internen Review innerhalb der Arbeitsgruppe.
|-
|2.00 rc1
|30.08.2011
|Redaktionelle Überarbeitung.
|-
|2.00 FWGD
|10.10.2011
|Fertigstellung des "Final Working Group Draft". Veröffentlicht für öffentlichen Review.
|-
|2.01
|11.06.2012
|Fertigstellung der gültigen Version 2.01 "Final". Abgrenzung des Geltungsbereiches (XDSDocumentEntry), Überarbeitung "PracticeSettingCode", Hinweis zu OID eingefügt (1.2.3), Überarbeitung der "parentDocumentRelationship", Typos ausgebessert
|-
|2.01
|21.12.2012
|Layout-Anpassung
|-
|2.01a
|07.03-2013
|Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16: "dieses Dokuments" eingefügt; 363: displayNameOf($code), "Of" gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch "2"-> "Enhanced" etc.) Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt Allgemein: Typos ausgebessert
|-
|2.02
|12.08.2013
|2.3.2 Präzisierung der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessert.
|-
|2.02
|12.08.2013
|2.3.2.3 PDF/A-1a-Vorschrift hinzugefügt
|-
|2.02
|13.08.2013
|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF/A-1a-
|-
|2.02
|17.09.2013
|Typos, Formatierung und Seitenumbrüche ausgebessert
|-
|2.02a
|06.02.2014
|Beispiele in Tabelle 3 korrigiert
|-
|2.03
|26.02.2014
|Definition von ReferenceIdList eingefügt
|-
|2.03
|03.03.2014
|Definition von intendedRecipient eingefügt
|-
|2.03
|03.03.2014
|Änderungen in Tabelle 3: LegalAuthenticator – von [R] auf [R2] geändert IntendedRecipient – von "-" auf [O] geändert, für Verwendung mit XDW vorgesehen ReferenceIdList hinzugefügt Den Namen des Value Sets von "ELGA-PracticeSettingCode" auf "ELGA-PracticeSettingCode-vs" geändert
|-
|2.03.
|03.03.2014
|Anhang gelöscht: 3.1. IHE ITI-TF3, Kapitel 4.1.7 "Document Definition Metadata" 3.2. IHE PCC-TF2, Kapitel 4.1.1 "XDSDocumentEntry Metadata" 3.3. IHE XDS Data Types
|-
|2.03
|03.03.2014
|Korrekturen: ITI Version einheitlich geändert auf "(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)". 1.1.3 Hinweis auf Terminologieserver hinzugefügt Tabelle 3 angepasst: EntryUUID Beschreibung geändert patientId Beschreibung geändert
|-
|2.03
|06.03.2014
|Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId
|-
|2.03
|21.03.2014
|Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt
|-
|2.03
|26.03.2014
|Kapitel 1.4. Korrektur von Dokumentverweisen
|-
|2.03a
|28.03.2014
|Kapitel 2.1 Korrektur von Fußnotennummern
|-
|2.03a
|28.03.2014
|Kapitel 2.2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000
|-
|2.03b
|1.7.2014
|Den Namen des Value Sets von "ELGA-PracticeSetting Code-vs" auf "ELGA_Practicesetting_VS" korrigiert
|-
|2.03b
|11.07.2014
|2.3.2.5 OID in der Spezifikation ergänzt
|-
|2.03b
|11.07.2014
|2.3.6 OID in der Spezifikation ergänzt
|-
|2.03b
|05.08.2014
|2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert
|-
|2.03b
|06.08.2014
|2.1 Überblickstabelle: ParentDocumentId und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]
|-
|2.03b
|06.08.2014
|Referenzen auf CDA Implementierungsleitfäden aktualisiert
|-
| colspan="3" |Version 2.05
|-
|2.05
|03.11.2014
|EntryUUID als "ELGA-Relevant" klassifiziert. Darstellung der Übersichtstabelle geändert
|-
|2.05
|03.11.2014
|2.2.15 TypeCode: ClassificationScheme im Beispiel korrigiert von "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" (falsch) auf "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" (richtig)
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht
|-
|2.05
|19.11.2014
|2.2.2. authorPerson: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden
|-
|2.05
|19.11.2014
|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software
|-
|2.05
|24.11.2014
|2.2.1.1. Spezifikation von authorInstitution: Fall entfernt, in dem die ID des GDA unbekannt ist. Die OID des GDA ist für ELGA-CDA [M]
|-
|2.05
|26.11.2014
|2.4 ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und ELGA-Flag. Auch in 2.1 entsprechend angegeben.
|-
|2.05
|12.03.2014
|Seite 2-3: Absätze "Verbindlichkeit", "Hinweise zur Verwendung" und "Erarbeitung des Implementierungsleitfadens" hinzugefügt.
|-
| colspan="3" |Version 2.06
|-
|2.06
|19.05.2015
|1.2.2. Codesysteme und Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.
|-
|2.06
|13.10.2015
|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch
|-
|2.06
|13.10.2015
|1.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.
|-
|2.06
|07.10.2015
|1.4.3. Kapitel "Metadaten aus 'On-Demand Documents' (ODD)" eingefügt
|-
|2.06
|10.09.2015
|2.1 Tabelle 3: Beschreibung der entryUUID ergänzt
|-
|2.06
|07.10.2015
|2.1 Tabelle 3: Spalte "Optionalität IHE" gelöscht, Spalte zur Definition von On-Demand-Documents eingefügt. objectType hinzugefügt patientid als E1 "ELGA relevant" deklariert (war E2)
|-
|2.06
|30.10.2015
|2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt wird, falls mehrere ID-Elemente angegeben sind.
|-
|2.06
|19.05.2015
|2.2.5. und 2.2.15: Typos verbessert
|-
|2.06
|29.10.2015
|2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt
|-
|2.06
|21.07.2015
|2.2.10. legalAuthenticator: Hinweis, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar ist.
|-
|2.06
|08.10.2015
|2.3.7 objectType hinzugefügt
|-
| colspan="3" |'''Version 2.06.2 (Nebenversion)''' x …betrifft Implementierung (erste Spalte)
|-
|
|01.08.2016
|Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
|-
|
|18.5.2016
|1.2 Erklärung zur Verwendung von XDS Folder und SubmissionSet hinzugefügt.
|-
|
|01.08.2016
|2.1. Tabelle 3: Korrektur der Optionalität von eventCodeList auf [R2], wie im Text bei 2.2.8 angegeben
|-
|x
|14.6.2016
|creationTime, serviceStartTime, serviceStopTime: Präzisierung der Vorgaben für Datum/Zeit, sie MUSS immer entsprechen der Angabe in CDA entweder 8 oder 14-stellig angegeben werden.
|-
|
|03.08.2016
|2.2.5, 2.3.2.2, 2.3.2.5, 2.3.5, 2.3.5.1, 2.3.5.1, 2.1, 1.4, 2.2.7, 2.2.11, 2.2.15, 2.3.6, 1.4.1.2 Korrektur der Großschreibung bei normativen Vorgaben
|-
|
|05.01.2017
|2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.
|-
|
|y
|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;"
|-
|
|y
|Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
|-
|
|y
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
|-
|
|y
|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.
|-
|
|
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
|-
|
|
|Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
|-
|
|
|Kapitel "4.2.7 legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
|-
|
|
|Kapitel "4.2.4 creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
|-
|
|y
|Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
|-
|
|y
|Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
|-
|
|
|Kapitel "4.2.2.1 Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
|-
|
|y
|Kapitel "XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.
|}

ILF:XDS Metadaten (Version 3)

2021-02-10T09:17:14Z

Sjencic: /* serviceStartTime / serviceStopTime */

{{#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)}}
{{Underconstruction}}


{{#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.7]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0
|Submitted = ELGA GmbH
|Date = Februar 2021
|Copyright = 2011-
|Status = Kommentierung
|Period = n.a.
|OID = 1.2.40.0.34.7.6.7
|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 CDA Dokumenten in der ELGA Infrastruktur notwendig sind und wie sie aus den CDA Dokumenten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden XDS-Metadaten-Guide im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für elektronische Dokumente der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti IHE ITI]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref>.

Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012), aber auch für medizinische Dokumente im österreichischen Gesundheitswesen. 
TODO: XDSi-Metadaten einfügen https://collab.dicom-austria.at/pages/viewpage.action?pageId=20709391&preview=/20709391/20709392/AnbindungBilddaten_Gesamtarchitektur.pdf

=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 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]</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]</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 [ILF:Allgemeiner_Implementierungsleitfaden_2020]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at]). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020]'''.
{{EndILFBox}}

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website TODO: [[ILF:Ambulanzbefund_Guide|Ambulanzbefund Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
* Beispieldokumente
* Schematron-Prüfregeln
* Design-Beispiele
{{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:

*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 und Hinweise===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''Hinweis:''' Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden
{{EndYellowBox}}
''Hinweis auf anderen Implementierungsleitfaden:''
{{BeginILFBox}}
'''Verweis''' Verweis auf den Allgemeinen Leitfaden:…
{{EndILFBox}}
''Themenbezogenes CDA Beispiel-Fragment im XML Format:''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>

<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"
|-
! style="text-align:left" colspan="3"| Autoren
|-
! style="text-align:left" width="10%" | Kürzel ||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person1
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Herausgeber, Projektleiter, CDA-Koordinator
|- style="background:#FFFFFF"
| SSA || ELGA GmbH || Stefan Sabutsch
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Autoren
|- style="background:#FFFFFF"
| JB|| CodeWerk Software Services and Development GmbH|| Jürgen Brandstätter
|- style="background:#FFFFFF"
| SSA|| ELGA GmbH, HL7 Austria||Stefan Sabutsch
|- style="background:#FFFFFF"
| OKU|| ELGA GmbH|| Oliver Kuttin
|- style="background:#FFFFFF"
| KHO|| Wiener Krankenanstaltenverbund|| Konrad Hölzl
|}

1 Namen ohne Titel




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

Eine IHE XDS Registry verwaltet Dokumente und macht diese 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.

Für die Registrierung von Bilddaten über XDS-I wird eine eigene Spezifikation veröffentlicht.

Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.

==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten<ref name="ALF"></ref> in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten (Metadaten der XDSDocumentEntry Objekte)
** ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 (16.9.2020) Final Text''<ref name="IHE ITI TF-3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 17.0 (2020), 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> und den "ELGA CDA Implementierungsleitfäden" erstellt.

===XDS Folder===
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
===XDS Submission Sets===
Eine weitere Profilierung des XDS SubmissionSets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.

==Hinweise zur Verwendung des Dokuments==
===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}}

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

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. Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.

====Löschen aus der Registry [ITI-62]====
Das Löschen von Dokumenten in ELGA erfolgt ausschließlich in folgenden Fällen: Löschen durch Bürger, Opt-Out, Ablauf der Aufbewahrungsdauer (nach 10 Jahren müssen Dokumente gelöscht werden). Das Löschen erfolgt i.d.R. "sicher", sodass die Daten nicht wiederhergestellt werden können, sowohl für Verweise als auch Dokumente. Über die Transaktion ITI-62 kann ein Dokument aus der Registry gelöscht werden. Beim Löschen werden sowohl der Registereintrag als auch das Dokument aus dem Repository gelöscht; falls das Löschen der Dokumente aufgrund anderer Verpflichtungen ausgeschlossen ist, sind nur die Verweise zu löschen. Siehe "Organisationshandbuch ELGA-Bereiche und Krankenanstalten" [8].

===Größenbeschränkung ===
ELGA schreibt keine Größenbeschränkung für registrierte Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1]]].

==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-TF3).<ref name="IHE ITI TF-3"></ref>

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:''' Sehen Sie auch die Vorschrift zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument 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 korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.

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

Die IHE hat im Rahmen des "Patient 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="IHE ITI"></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, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus Bilddaten (KOS)===
TODO:

===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'''
# 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"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" rowspan="2" |'''Metadaten Element'''
|'''Optionalität'''
| rowspan="2" |'''Beschreibung'''
| rowspan="2" |'''Que-'''

'''lle'''
|-
|'''ELGA'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''R'''
|Die Person, welche das Dokument verfasst hat
|<nowiki>-</nowiki>
|-
| rowspan="4" |
|authorInstitution
|'''R'''
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|A/K
|-
|authorPerson
|'''R2'''
|Daten der Person

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

z.B.: 55113-5 "KOSObjekte"
|A
|-
| colspan="2" |'''confidentialityCode'''
|'''R'''
|Vertraulichkeitscode. Fester Wert "N"
|A
|-
| colspan="2" |'''creationTime'''
|'''R'''
|Zeitpunkt der Dokumentenerstellung
|K
|-
| colspan="2" |'''eventCodeList'''
|'''R'''
|Liste von Codes von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''eventCodeDisplayNameList'''
|'''R2'''
|Liste von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''intendedRecipient'''
|'''X'''
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
| -
|-
| colspan="2" |'''languageCode'''
|'''R'''
|Sprachcode. Fester Wert "de-AT"
|A
|-
| colspan="2" |'''legalAuthenticator'''
|'''X'''
|Rechtlicher Unterzeichner
| -
|-
| colspan="2" |'''serviceStartTime'''
|'''R'''
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|K
|-
| colspan="2" |'''serviceStopTime'''
|'''X'''
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
| -
|-
| colspan="2" |'''sourcePatientId'''
|'''R'''
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''sourcePatientInfo'''
|'''R'''
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''Title'''
|'''R'''
|Titel des Dokuments
|A/K
|-
| colspan="2" |'''typeCode'''
|'''R'''
|Objekttyp (Unterklasse)

codierter Wert
|A
|-
| colspan="2" |'''uniqueId'''
|'''R'''
|Global eindeutige ID des Objektes

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

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

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

 



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

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

TODO: urn:ihe:iti:xds:2015:encounterId als referenceIdList Eintrag ergänzen?

{| 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 1: Legende zur Spalte "Quelle" der folgenden Tabelle''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| 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="45%" |'''Beschreibung '''|| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
|- style="background:#CBD7F1"
|'''SD9'''||'''OD10'''
|- 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)||'''R'''||'''R'''||Die Person, welche das Dokument verfasst hat||-
|- style="background:white"
| ||authorInstitution||'''R'''||'''R'''||ID der Organisation, der die Person angehört. (OID aus dem GDA-Index)||C
|- style="background:white"
| ||authorPerson||'''R'''||'''R'''||Daten der Person (Name, ID, etc.)||C
|- style="background:white"
| ||authorRole||'''R2'''||'''X'''||Rolle der Person||C
|- style="background:white"
| ||authorSpeciality||'''R2'''||'''X'''||Fachrichtung der Person||C
|- style="background:white"
| colspan="2" |'''classCode'''||'''R'''||'''R'''||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"||C
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''R'''||'''X'''||Vertraulichkeitscode des Dokuments||C
|- style="background:white"
| colspan="2" |'''creationTime'''||'''R'''||'''R'''||Zeitpunkt der Dokumentenerstellung||C
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R2'''||'''R2'''||Liste von Gesundheitsdienstleistungen||C
|-
| colspan="2" |'''formatCode'''
|'''R'''
|'''R'''
|Format des Dokumenteninhalts
|C
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O'''||'''X'''||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C
|- style="background:white"
| colspan="2" |'''languageCode'''||'''R'''||'''R'''||Sprachcode des Dokuments z.B.: "de-AT"||C
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R2'''||'''X'''||Rechtlicher Unterzeichner des Dokuments||C
|-
| colspan="2" |'''practiceSettingCode'''
|'''R'''
|'''R'''
|Fachliche Zuordnung des Dokuments
|C
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R2'''||'''O'''||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R2'''||'''O'''||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung||C
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''R'''||'''R'''||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH||C
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''X'''||'''X'''||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C
|- style="background:white"
| colspan="2" |'''Title'''||'''R'''||'''R'''||Titel des Dokuments||C
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''R'''||'''R'''||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"||C
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''R'''||'''R'''||Global eindeutige ID des Dokuments||C
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''R'''||'''O'''||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert||C
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''R'''||'''R'''||Klassifizierung des GDA
|C

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
|- style="background:white"
| colspan="2" |'''availabilityStatus'''||'''R'''||'''R'''||Gültigkeit des Dokuments||E1
|- style="background:white"
| colspan="2" |'''mimeType'''||'''R'''||'''R'''||Mime Type des Dokuments z.B.: "text/xml" für CDA||E1
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O'''||'''O'''||Verweis auf ein referenziertes Dokument||E1
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O'''||'''O'''||Typ der Relation zu dem referenzierten Dokument. z.B.: RPLC, XFRM||E1
|- style="background:white"
| colspan="2" |'''entryUUID'''||'''R'''||'''R'''||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)||E1
|- style="background:white"
| colspan="2" |'''objectType'''||'''R'''||'''R'''||Typ des DocumentEntries (SD oder ODD)||E1
|- style="background:white"
| colspan="2" |'''comments'''||'''O'''||'''O'''||Kommentar zum Dokument||E2
|- style="background:white"
| colspan="2" |'''patientId'''||'''R'''||'''R'''||Patienten-ID in der XDS Affinity Domain||E1

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|- style="background:white"
| colspan="2" |'''hash'''||'''R'''||'''X'''||Hash Wert des Dokuments. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''homeCommunityId'''||'''R'''||'''R'''||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.||A
|- style="background:white"
| colspan="2" |'''repositoryUniqueId '''||'''R'''||'''R'''||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''size'''||'''R'''||'''X'''||Größe des Dokuments in Bytes. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''URI'''14||'''-'''||'''-'''||'''Wird in XDS nicht verwendet'''||A
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|- style="background:white"
| colspan="2" |'''elgaFlag'''||'''R'''||'''R'''||Kennzeichnet ein Dokument als "ELGA-Dokument"||B
|- style="background:white"
| colspan="2" |'''elgaHash'''||'''R'''||'''R'''||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B
|}
''Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)''

9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht. 
10 OD: "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 SubmissionSets übereinstimmen. 
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. 
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein. 
14 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.


=XDS-I Metadaten für DICOM KOS Objekte=
==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

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.

{| class="wikitable"
|'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

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

'''im KOS'''
|'''Beschreibung'''
|-
| colspan="5" |author
|-
|author.authorInstitution
|R
|
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl den Namen als auch die OID der Institution im 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.
|-
| colspan="5" |Die die Studie durchführende Person ist als author anzugeben:
|-
|author.authorPerson
|R2
|(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.
|-
|
|
|'''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.
|-
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|-
|author.authorPerson
|R2
|(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.
|-
|creationTime
|R
|(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.
|-
|eventCodeList
|R
|
|
|Enthält den APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|eventCodeListDisplayNameList
|R2
|
|
|Enthält den Display Name des APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|serviceStartTime
|R
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|-
|sourcePatientId
|R
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|-
|sourcePatientInfo
|R
|(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.
|-
|title
|R
|(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".
 
|-
|uniqueId
|R
|
|(0008,0018)
|Die SOP Instance UID des KOS
|-
| colspan="4" |referenceIdList
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|-
|value mit CXi.5 =

"<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>"
|R
|(0020,000D) oder ein vergleich-bares Attribut
|(0020,000D) oder ein vergleich-bares 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 Kapitel 8.2.2.
|-
|value mit CXi.5 =

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
|O
|(0008,0050) oder ein vergleich-bares 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.
|-
|comments
|O
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

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 Radiology Technical Framework, vol2, rev. 19, "4.68.4.1.2.3.2 DocumentEntry Metadata" sowie IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. 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 kann

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

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

$id ... OID der Organisation aus dem GDA-Index

concat( 
$name,"^^^^^^^^^", 
$id 
) 
<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-TF3].
====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[[#%20ftn1|[1]]], wenn vorhanden
#*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) ----[[#%20ftnref1|[1]]] Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den DICOM Attribut Modality der Studie abgleitet werden
#*Modalität[[#%20ftn1|[2]]]: Attribut "Modality", (0008,0060)
#*Hersteller: Attribut "Manufacturer", (0008,0070)
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</nowiki>

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

$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>2323^MusterDoc^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
=====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-TF3].

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objektation 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|4.2.15]]
|}

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "[https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen hl7-austria-Dokumentenklassen]" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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 "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]".

====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 registrieren 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)
#Sollten 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''[[#%20ftn1|[3]]] berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

[[#%20ftnref1|[3]]] <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</nowiki>
====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 +(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. 20160518 in 20160518000000).

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-TF3].{{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".[[# ftn4|[4]]])
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.
----[[# ftnref4|[4]]] DICOM Austria: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten", 22.01.2020, <nowiki>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</nowiki> (zuletzt besucht am 12.3.2020)

====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 des DICOM Objektes aus den Attributen des KOS Objektes:
#*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. 20160518 in 20160518000000).

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel 3.2.12 sourcePatientId gemappt und verwendet.

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

====Spezifikation (empfohlene Variante)====
'''sourcePatientInfo''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = concat(

$patientID, "^^^&amp;",

$oid, "&amp;ISO"

)

Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO

$name = ""

$birthtime = ""

$gender = ""

$addr = "" <pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientInfo">
<ValueList>
<Value>PID-3|$id</Value>
<Value>PID-5|$name</Value>
<Value>PID-7|$birthtime</Value>
<Value>PID-8|$gender</Value>
<Value>PID-11|$addr</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modailty 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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 entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.

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 zwei unterschiedliche Einträge in referenceIdList notwendig:

#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId)
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number)

'''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="IHE ITI TF-3"></ref>

{| 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 z.B. 1.2.40.0.34.99.999

concat

(

$id, "^^^^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

"&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>^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^^^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"

====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 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 [https://tools.ietf.org/html/rfc2045 <nowiki>RFC 2045[6]</nowiki>] und RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

[6] <nowiki>http://tools.ietf.org/html/rfc2045</nowiki>

[7] <nowiki>http://tools.ietf.org/html/rfc2049</nowiki>

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das 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 "[[urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be]]" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

====Spezifikation====

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

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.

===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 weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

==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 SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description 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"

#GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
{{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 
) 
<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-TF3].

====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). Mindestens eine Person

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

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

====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 '''''[R2]'''''.
#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 '''''[R2]'''''.
#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|4.2.15]]
|}

 

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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===
Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:
##ClinicalDocument/effectiveTime
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.
#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
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-TF3].
{{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 [R2].
#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 PCC Profil definiert in Kapitel "Medical Document Bindings" Spezialbehandlungen für gewissen 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}}

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

===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 '''''[R2]'''''.

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

TODO: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.

====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] … Lokale ID des Patienten vom einbringenden System
##d[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-TF3].

===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|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 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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.
uniqueId wird als ebRIM

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===
Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommen.
{{BeginYellowBox}}
Im Rahmen von ELGA ist die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten einzubringen. Weitere andere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.
{{EndYellowBox}}

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

====Spezifikation====
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="IHE ITI TF-3"></ref>

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

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

referenceIdList wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat

(

ClinicalDocument/setId/@extension, "^^^",

ClinicalDocument/setId/@root, "^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

homeCommunityId

)

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;amp;1.2.40.0.34.99.111.1.1
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>
^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</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^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"
<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><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;2.25
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki>
&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

====Bildungsregel für den formatCodeDisplayName====
TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.

Der formatCodeDisplayName ist analog zum formatCode aus den displayNames des entsprechenden Value Sets [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS] zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels ":" (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).

'''Beispiele:'''

*'''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''
*'''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''
*'''ELGA Laborbefund, EIS Full Support v2.06+'''

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = gemäß Liste der in ELGA gültigen FormatCodes 
$codeSystem = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]
<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">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>
<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">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>

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, das das DocumentEntry repräsentiert.

Folgende Mime-Types sind für Dokumente zugelassen: 
CDA R2: '''text/xml''' 
DICOM/KOS: '''application/dicom''' 

<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 wurde ein genau entsprechendes Element 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 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 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"

====Spezifikation====

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

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.

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

<references />

==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 (2015) HL7 Implementation Guide for CDA® R2: Ärztlicher Entlassungsbrief.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.2.6], http://www.elga.gv.at

|-
|[3]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Entlassungsbrief Pflege. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.3.6], http://www.elga.gv.at
|-
| || 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

|-
|[4]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Laborbefund.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.4.6], http://www.elga.gv.at

|-
|[5]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Befund bildgebende Diagnostik.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.5.6], http://www.elga.gv.at
|-
|[6]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: e-Medikation.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.8.6], http://www.elga.gv.at

|-
|[7]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2:
|-
| || Pflegesituationsbericht (2.06) [OID 1.2.40.0.34.7.12.6], http://www.elga.gv.at

|-
|[8]|| ELGA GmbH (2015) Organisationshandbuch.
|-
| || ELGA-Bereiche und Krankenanstalten (2.2.1) [OID 1.2.40.0.34.3.1.2.1.32], http://www.elga.gv.at
|}

==Revisionsliste==
{| class="wikitable"
!Vers.
!Datum
!Änderungsgrund
|-
|0.05
|16.05.2011
|Ergebnisse aus dem technischen Online-Meeting
|-
|2.00 Beta
|12.08.2011
|Erster "Release candidate" des Dokuments für internen Review innerhalb der Arbeitsgruppe.
|-
|2.00 rc1
|30.08.2011
|Redaktionelle Überarbeitung.
|-
|2.00 FWGD
|10.10.2011
|Fertigstellung des "Final Working Group Draft". Veröffentlicht für öffentlichen Review.
|-
|2.01
|11.06.2012
|Fertigstellung der gültigen Version 2.01 "Final". Abgrenzung des Geltungsbereiches (XDSDocumentEntry), Überarbeitung "PracticeSettingCode", Hinweis zu OID eingefügt (1.2.3), Überarbeitung der "parentDocumentRelationship", Typos ausgebessert
|-
|2.01
|21.12.2012
|Layout-Anpassung
|-
|2.01a
|07.03-2013
|Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16: "dieses Dokuments" eingefügt; 363: displayNameOf($code), "Of" gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch "2"-> "Enhanced" etc.) Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt Allgemein: Typos ausgebessert
|-
|2.02
|12.08.2013
|2.3.2 Präzisierung der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessert.
|-
|2.02
|12.08.2013
|2.3.2.3 PDF/A-1a-Vorschrift hinzugefügt
|-
|2.02
|13.08.2013
|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF/A-1a-
|-
|2.02
|17.09.2013
|Typos, Formatierung und Seitenumbrüche ausgebessert
|-
|2.02a
|06.02.2014
|Beispiele in Tabelle 3 korrigiert
|-
|2.03
|26.02.2014
|Definition von ReferenceIdList eingefügt
|-
|2.03
|03.03.2014
|Definition von intendedRecipient eingefügt
|-
|2.03
|03.03.2014
|Änderungen in Tabelle 3: LegalAuthenticator – von [R] auf [R2] geändert IntendedRecipient – von "-" auf [O] geändert, für Verwendung mit XDW vorgesehen ReferenceIdList hinzugefügt Den Namen des Value Sets von "ELGA-PracticeSettingCode" auf "ELGA-PracticeSettingCode-vs" geändert
|-
|2.03.
|03.03.2014
|Anhang gelöscht: 3.1. IHE ITI-TF3, Kapitel 4.1.7 "Document Definition Metadata" 3.2. IHE PCC-TF2, Kapitel 4.1.1 "XDSDocumentEntry Metadata" 3.3. IHE XDS Data Types
|-
|2.03
|03.03.2014
|Korrekturen: ITI Version einheitlich geändert auf "(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)". 1.1.3 Hinweis auf Terminologieserver hinzugefügt Tabelle 3 angepasst: EntryUUID Beschreibung geändert patientId Beschreibung geändert
|-
|2.03
|06.03.2014
|Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId
|-
|2.03
|21.03.2014
|Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt
|-
|2.03
|26.03.2014
|Kapitel 1.4. Korrektur von Dokumentverweisen
|-
|2.03a
|28.03.2014
|Kapitel 2.1 Korrektur von Fußnotennummern
|-
|2.03a
|28.03.2014
|Kapitel 2.2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000
|-
|2.03b
|1.7.2014
|Den Namen des Value Sets von "ELGA-PracticeSetting Code-vs" auf "ELGA_Practicesetting_VS" korrigiert
|-
|2.03b
|11.07.2014
|2.3.2.5 OID in der Spezifikation ergänzt
|-
|2.03b
|11.07.2014
|2.3.6 OID in der Spezifikation ergänzt
|-
|2.03b
|05.08.2014
|2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert
|-
|2.03b
|06.08.2014
|2.1 Überblickstabelle: ParentDocumentId und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]
|-
|2.03b
|06.08.2014
|Referenzen auf CDA Implementierungsleitfäden aktualisiert
|-
| colspan="3" |Version 2.05
|-
|2.05
|03.11.2014
|EntryUUID als "ELGA-Relevant" klassifiziert. Darstellung der Übersichtstabelle geändert
|-
|2.05
|03.11.2014
|2.2.15 TypeCode: ClassificationScheme im Beispiel korrigiert von "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" (falsch) auf "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" (richtig)
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht
|-
|2.05
|19.11.2014
|2.2.2. authorPerson: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden
|-
|2.05
|19.11.2014
|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software
|-
|2.05
|24.11.2014
|2.2.1.1. Spezifikation von authorInstitution: Fall entfernt, in dem die ID des GDA unbekannt ist. Die OID des GDA ist für ELGA-CDA [M]
|-
|2.05
|26.11.2014
|2.4 ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und ELGA-Flag. Auch in 2.1 entsprechend angegeben.
|-
|2.05
|12.03.2014
|Seite 2-3: Absätze "Verbindlichkeit", "Hinweise zur Verwendung" und "Erarbeitung des Implementierungsleitfadens" hinzugefügt.
|-
| colspan="3" |Version 2.06
|-
|2.06
|19.05.2015
|1.2.2. Codesysteme und Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.
|-
|2.06
|13.10.2015
|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch
|-
|2.06
|13.10.2015
|1.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.
|-
|2.06
|07.10.2015
|1.4.3. Kapitel "Metadaten aus 'On-Demand Documents' (ODD)" eingefügt
|-
|2.06
|10.09.2015
|2.1 Tabelle 3: Beschreibung der entryUUID ergänzt
|-
|2.06
|07.10.2015
|2.1 Tabelle 3: Spalte "Optionalität IHE" gelöscht, Spalte zur Definition von On-Demand-Documents eingefügt. objectType hinzugefügt patientid als E1 "ELGA relevant" deklariert (war E2)
|-
|2.06
|30.10.2015
|2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt wird, falls mehrere ID-Elemente angegeben sind.
|-
|2.06
|19.05.2015
|2.2.5. und 2.2.15: Typos verbessert
|-
|2.06
|29.10.2015
|2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt
|-
|2.06
|21.07.2015
|2.2.10. legalAuthenticator: Hinweis, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar ist.
|-
|2.06
|08.10.2015
|2.3.7 objectType hinzugefügt
|-
| colspan="3" |'''Version 2.06.2 (Nebenversion)''' x …betrifft Implementierung (erste Spalte)
|-
|
|01.08.2016
|Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
|-
|
|18.5.2016
|1.2 Erklärung zur Verwendung von XDS Folder und SubmissionSet hinzugefügt.
|-
|
|01.08.2016
|2.1. Tabelle 3: Korrektur der Optionalität von eventCodeList auf [R2], wie im Text bei 2.2.8 angegeben
|-
|x
|14.6.2016
|creationTime, serviceStartTime, serviceStopTime: Präzisierung der Vorgaben für Datum/Zeit, sie MUSS immer entsprechen der Angabe in CDA entweder 8 oder 14-stellig angegeben werden.
|-
|
|03.08.2016
|2.2.5, 2.3.2.2, 2.3.2.5, 2.3.5, 2.3.5.1, 2.3.5.1, 2.1, 1.4, 2.2.7, 2.2.11, 2.2.15, 2.3.6, 1.4.1.2 Korrektur der Großschreibung bei normativen Vorgaben
|-
|
|05.01.2017
|2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.
|-
|
|y
|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;"
|-
|
|y
|Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
|-
|
|y
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
|-
|
|y
|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.
|-
|
|
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
|-
|
|
|Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
|-
|
|
|Kapitel "4.2.7 legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
|-
|
|
|Kapitel "4.2.4 creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
|-
|
|y
|Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
|-
|
|y
|Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
|-
|
|
|Kapitel "4.2.2.1 Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
|-
|
|y
|Kapitel "XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.
|}

ILF:XDS Metadaten (Version 3)

2021-02-10T07:55:32Z

Sjencic: /* eventCodeList (und eventCodeListDisplayName) */

{{#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)}}
{{Underconstruction}}


{{#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.7]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0
|Submitted = ELGA GmbH
|Date = Februar 2021
|Copyright = 2011-
|Status = Kommentierung
|Period = n.a.
|OID = 1.2.40.0.34.7.6.7
|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 CDA Dokumenten in der ELGA Infrastruktur notwendig sind und wie sie aus den CDA Dokumenten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden XDS-Metadaten-Guide im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für elektronische Dokumente der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti IHE ITI]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref>.

Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012), aber auch für medizinische Dokumente im österreichischen Gesundheitswesen. 
TODO: XDSi-Metadaten einfügen https://collab.dicom-austria.at/pages/viewpage.action?pageId=20709391&preview=/20709391/20709392/AnbindungBilddaten_Gesamtarchitektur.pdf

=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 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]</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]</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 [ILF:Allgemeiner_Implementierungsleitfaden_2020]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at]). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020]'''.
{{EndILFBox}}

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website TODO: [[ILF:Ambulanzbefund_Guide|Ambulanzbefund Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
* Beispieldokumente
* Schematron-Prüfregeln
* Design-Beispiele
{{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:

*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 und Hinweise===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''Hinweis:''' Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden
{{EndYellowBox}}
''Hinweis auf anderen Implementierungsleitfaden:''
{{BeginILFBox}}
'''Verweis''' Verweis auf den Allgemeinen Leitfaden:…
{{EndILFBox}}
''Themenbezogenes CDA Beispiel-Fragment im XML Format:''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>

<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"
|-
! style="text-align:left" colspan="3"| Autoren
|-
! style="text-align:left" width="10%" | Kürzel ||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person1
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Herausgeber, Projektleiter, CDA-Koordinator
|- style="background:#FFFFFF"
| SSA || ELGA GmbH || Stefan Sabutsch
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Autoren
|- style="background:#FFFFFF"
| JB|| CodeWerk Software Services and Development GmbH|| Jürgen Brandstätter
|- style="background:#FFFFFF"
| SSA|| ELGA GmbH, HL7 Austria||Stefan Sabutsch
|- style="background:#FFFFFF"
| OKU|| ELGA GmbH|| Oliver Kuttin
|- style="background:#FFFFFF"
| KHO|| Wiener Krankenanstaltenverbund|| Konrad Hölzl
|}

1 Namen ohne Titel




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

Eine IHE XDS Registry verwaltet Dokumente und macht diese 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.

Für die Registrierung von Bilddaten über XDS-I wird eine eigene Spezifikation veröffentlicht.

Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.

==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten<ref name="ALF"></ref> in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten (Metadaten der XDSDocumentEntry Objekte)
** ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 (16.9.2020) Final Text''<ref name="IHE ITI TF-3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 17.0 (2020), 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> und den "ELGA CDA Implementierungsleitfäden" erstellt.

===XDS Folder===
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
===XDS Submission Sets===
Eine weitere Profilierung des XDS SubmissionSets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.

==Hinweise zur Verwendung des Dokuments==
===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}}

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

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. Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.

====Löschen aus der Registry [ITI-62]====
Das Löschen von Dokumenten in ELGA erfolgt ausschließlich in folgenden Fällen: Löschen durch Bürger, Opt-Out, Ablauf der Aufbewahrungsdauer (nach 10 Jahren müssen Dokumente gelöscht werden). Das Löschen erfolgt i.d.R. "sicher", sodass die Daten nicht wiederhergestellt werden können, sowohl für Verweise als auch Dokumente. Über die Transaktion ITI-62 kann ein Dokument aus der Registry gelöscht werden. Beim Löschen werden sowohl der Registereintrag als auch das Dokument aus dem Repository gelöscht; falls das Löschen der Dokumente aufgrund anderer Verpflichtungen ausgeschlossen ist, sind nur die Verweise zu löschen. Siehe "Organisationshandbuch ELGA-Bereiche und Krankenanstalten" [8].

===Größenbeschränkung ===
ELGA schreibt keine Größenbeschränkung für registrierte Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1]]].

==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-TF3).<ref name="IHE ITI TF-3"></ref>

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:''' Sehen Sie auch die Vorschrift zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument 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 korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.

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

Die IHE hat im Rahmen des "Patient 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="IHE ITI"></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, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus Bilddaten (KOS)===
TODO:

===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'''
# 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"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" rowspan="2" |'''Metadaten Element'''
|'''Optionalität'''
| rowspan="2" |'''Beschreibung'''
| rowspan="2" |'''Que-'''

'''lle'''
|-
|'''ELGA'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''R'''
|Die Person, welche das Dokument verfasst hat
|<nowiki>-</nowiki>
|-
| rowspan="4" |
|authorInstitution
|'''R'''
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|A/K
|-
|authorPerson
|'''R2'''
|Daten der Person

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

z.B.: 55113-5 "KOSObjekte"
|A
|-
| colspan="2" |'''confidentialityCode'''
|'''R'''
|Vertraulichkeitscode. Fester Wert "N"
|A
|-
| colspan="2" |'''creationTime'''
|'''R'''
|Zeitpunkt der Dokumentenerstellung
|K
|-
| colspan="2" |'''eventCodeList'''
|'''R'''
|Liste von Codes von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''eventCodeDisplayNameList'''
|'''R2'''
|Liste von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''intendedRecipient'''
|'''X'''
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
| -
|-
| colspan="2" |'''languageCode'''
|'''R'''
|Sprachcode. Fester Wert "de-AT"
|A
|-
| colspan="2" |'''legalAuthenticator'''
|'''X'''
|Rechtlicher Unterzeichner
| -
|-
| colspan="2" |'''serviceStartTime'''
|'''R'''
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|K
|-
| colspan="2" |'''serviceStopTime'''
|'''X'''
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
| -
|-
| colspan="2" |'''sourcePatientId'''
|'''R'''
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''sourcePatientInfo'''
|'''R'''
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''Title'''
|'''R'''
|Titel des Dokuments
|A/K
|-
| colspan="2" |'''typeCode'''
|'''R'''
|Objekttyp (Unterklasse)

codierter Wert
|A
|-
| colspan="2" |'''uniqueId'''
|'''R'''
|Global eindeutige ID des Objektes

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

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

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

 



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

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

TODO: urn:ihe:iti:xds:2015:encounterId als referenceIdList Eintrag ergänzen?

{| 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 1: Legende zur Spalte "Quelle" der folgenden Tabelle''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| 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="45%" |'''Beschreibung '''|| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
|- style="background:#CBD7F1"
|'''SD9'''||'''OD10'''
|- 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)||'''R'''||'''R'''||Die Person, welche das Dokument verfasst hat||-
|- style="background:white"
| ||authorInstitution||'''R'''||'''R'''||ID der Organisation, der die Person angehört. (OID aus dem GDA-Index)||C
|- style="background:white"
| ||authorPerson||'''R'''||'''R'''||Daten der Person (Name, ID, etc.)||C
|- style="background:white"
| ||authorRole||'''R2'''||'''X'''||Rolle der Person||C
|- style="background:white"
| ||authorSpeciality||'''R2'''||'''X'''||Fachrichtung der Person||C
|- style="background:white"
| colspan="2" |'''classCode'''||'''R'''||'''R'''||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"||C
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''R'''||'''X'''||Vertraulichkeitscode des Dokuments||C
|- style="background:white"
| colspan="2" |'''creationTime'''||'''R'''||'''R'''||Zeitpunkt der Dokumentenerstellung||C
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R2'''||'''R2'''||Liste von Gesundheitsdienstleistungen||C
|-
| colspan="2" |'''formatCode'''
|'''R'''
|'''R'''
|Format des Dokumenteninhalts
|C
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O'''||'''X'''||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C
|- style="background:white"
| colspan="2" |'''languageCode'''||'''R'''||'''R'''||Sprachcode des Dokuments z.B.: "de-AT"||C
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R2'''||'''X'''||Rechtlicher Unterzeichner des Dokuments||C
|-
| colspan="2" |'''practiceSettingCode'''
|'''R'''
|'''R'''
|Fachliche Zuordnung des Dokuments
|C
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R2'''||'''O'''||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R2'''||'''O'''||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung||C
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''R'''||'''R'''||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH||C
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''X'''||'''X'''||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C
|- style="background:white"
| colspan="2" |'''Title'''||'''R'''||'''R'''||Titel des Dokuments||C
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''R'''||'''R'''||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"||C
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''R'''||'''R'''||Global eindeutige ID des Dokuments||C
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''R'''||'''O'''||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert||C
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''R'''||'''R'''||Klassifizierung des GDA
|C

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
|- style="background:white"
| colspan="2" |'''availabilityStatus'''||'''R'''||'''R'''||Gültigkeit des Dokuments||E1
|- style="background:white"
| colspan="2" |'''mimeType'''||'''R'''||'''R'''||Mime Type des Dokuments z.B.: "text/xml" für CDA||E1
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O'''||'''O'''||Verweis auf ein referenziertes Dokument||E1
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O'''||'''O'''||Typ der Relation zu dem referenzierten Dokument. z.B.: RPLC, XFRM||E1
|- style="background:white"
| colspan="2" |'''entryUUID'''||'''R'''||'''R'''||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)||E1
|- style="background:white"
| colspan="2" |'''objectType'''||'''R'''||'''R'''||Typ des DocumentEntries (SD oder ODD)||E1
|- style="background:white"
| colspan="2" |'''comments'''||'''O'''||'''O'''||Kommentar zum Dokument||E2
|- style="background:white"
| colspan="2" |'''patientId'''||'''R'''||'''R'''||Patienten-ID in der XDS Affinity Domain||E1

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|- style="background:white"
| colspan="2" |'''hash'''||'''R'''||'''X'''||Hash Wert des Dokuments. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''homeCommunityId'''||'''R'''||'''R'''||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.||A
|- style="background:white"
| colspan="2" |'''repositoryUniqueId '''||'''R'''||'''R'''||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''size'''||'''R'''||'''X'''||Größe des Dokuments in Bytes. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''URI'''14||'''-'''||'''-'''||'''Wird in XDS nicht verwendet'''||A
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|- style="background:white"
| colspan="2" |'''elgaFlag'''||'''R'''||'''R'''||Kennzeichnet ein Dokument als "ELGA-Dokument"||B
|- style="background:white"
| colspan="2" |'''elgaHash'''||'''R'''||'''R'''||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B
|}
''Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)''

9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht. 
10 OD: "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 SubmissionSets übereinstimmen. 
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. 
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein. 
14 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.


=XDS-I Metadaten für DICOM KOS Objekte=
==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

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.

{| class="wikitable"
|'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

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

'''im KOS'''
|'''Beschreibung'''
|-
| colspan="5" |author
|-
|author.authorInstitution
|R
|
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl den Namen als auch die OID der Institution im 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.
|-
| colspan="5" |Die die Studie durchführende Person ist als author anzugeben:
|-
|author.authorPerson
|R2
|(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.
|-
|
|
|'''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.
|-
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|-
|author.authorPerson
|R2
|(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.
|-
|creationTime
|R
|(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.
|-
|eventCodeList
|R
|
|
|Enthält den APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|eventCodeListDisplayNameList
|R2
|
|
|Enthält den Display Name des APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|serviceStartTime
|R
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|-
|sourcePatientId
|R
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|-
|sourcePatientInfo
|R
|(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.
|-
|title
|R
|(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".
 
|-
|uniqueId
|R
|
|(0008,0018)
|Die SOP Instance UID des KOS
|-
| colspan="4" |referenceIdList
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|-
|value mit CXi.5 =

"<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>"
|R
|(0020,000D) oder ein vergleich-bares Attribut
|(0020,000D) oder ein vergleich-bares 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 Kapitel 8.2.2.
|-
|value mit CXi.5 =

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
|O
|(0008,0050) oder ein vergleich-bares 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.
|-
|comments
|O
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

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 Radiology Technical Framework, vol2, rev. 19, "4.68.4.1.2.3.2 DocumentEntry Metadata" sowie IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. 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 kann

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

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

$id ... OID der Organisation aus dem GDA-Index

concat( 
$name,"^^^^^^^^^", 
$id 
) 
<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-TF3].
====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[[#%20ftn1|[1]]], wenn vorhanden
#*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) ----[[#%20ftnref1|[1]]] Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den DICOM Attribut Modality der Studie abgleitet werden
#*Modalität[[#%20ftn1|[2]]]: Attribut "Modality", (0008,0060)
#*Hersteller: Attribut "Manufacturer", (0008,0070)
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</nowiki>

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

$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>2323^MusterDoc^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
=====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-TF3].

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objektation 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|4.2.15]]
|}

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "[https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen hl7-austria-Dokumentenklassen]" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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 "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]".

====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 registrieren 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)
#Sollten 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''[[#%20ftn1|[3]]] berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

[[#%20ftnref1|[3]]] <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</nowiki>
====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 +(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. 20160518 in 20160518000000).

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-TF3].{{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".[[# ftn4|[4]]])
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.
----[[# ftnref4|[4]]] DICOM Austria: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten", 22.01.2020, <nowiki>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</nowiki> (zuletzt besucht am 12.3.2020)

====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 des DICOM Objektes aus den Attributen des KOS Objektes:
#*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. 20160518 in 20160518000000).

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel 3.2.12 sourcePatientId gemappt und verwendet.

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

====Spezifikation (empfohlene Variante)====
'''sourcePatientInfo''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = concat(

$patientID, "^^^&amp;",

$oid, "&amp;ISO"

)

Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO

$name = ""

$birthtime = ""

$gender = ""

$addr = "" <pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientInfo">
<ValueList>
<Value>PID-3|$id</Value>
<Value>PID-5|$name</Value>
<Value>PID-7|$birthtime</Value>
<Value>PID-8|$gender</Value>
<Value>PID-11|$addr</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modailty 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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 entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.

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 zwei unterschiedliche Einträge in referenceIdList notwendig:

#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId)
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number)

'''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="IHE ITI TF-3"></ref>

{| 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 z.B. 1.2.40.0.34.99.999

concat

(

$id, "^^^^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

"&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>^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^^^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"

====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 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 [https://tools.ietf.org/html/rfc2045 <nowiki>RFC 2045[6]</nowiki>] und RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

[6] <nowiki>http://tools.ietf.org/html/rfc2045</nowiki>

[7] <nowiki>http://tools.ietf.org/html/rfc2049</nowiki>

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das 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 "[[urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be]]" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

====Spezifikation====

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

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.

===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 weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

==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 SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description 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"

#GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
{{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 
) 
<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-TF3].

====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). Mindestens eine Person

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

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

====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 '''''[R2]'''''.
#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 '''''[R2]'''''.
#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|4.2.15]]
|}

 

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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===
Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:
##ClinicalDocument/effectiveTime
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.
#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
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-TF3].
{{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 [R2].
#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 PCC Profil definiert in Kapitel "Medical Document Bindings" Spezialbehandlungen für gewissen 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}}

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

===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 '''''[R2]'''''.

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

TODO: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.

====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] … Lokale ID des Patienten vom einbringenden System
##d[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-TF3].

===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|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 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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.
uniqueId wird als ebRIM

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===
Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommen.
{{BeginYellowBox}}
Im Rahmen von ELGA ist die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten einzubringen. Weitere andere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.
{{EndYellowBox}}

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

====Spezifikation====
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="IHE ITI TF-3"></ref>

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

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

referenceIdList wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat

(

ClinicalDocument/setId/@extension, "^^^",

ClinicalDocument/setId/@root, "^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

homeCommunityId

)

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;amp;1.2.40.0.34.99.111.1.1
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>
^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</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^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"
<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><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;2.25
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki>
&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

====Bildungsregel für den formatCodeDisplayName====
TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.

Der formatCodeDisplayName ist analog zum formatCode aus den displayNames des entsprechenden Value Sets [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS] zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels ":" (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).

'''Beispiele:'''

*'''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''
*'''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''
*'''ELGA Laborbefund, EIS Full Support v2.06+'''

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = gemäß Liste der in ELGA gültigen FormatCodes 
$codeSystem = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]
<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">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>
<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">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>

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, das das DocumentEntry repräsentiert.

Folgende Mime-Types sind für Dokumente zugelassen: 
CDA R2: '''text/xml''' 
DICOM/KOS: '''application/dicom''' 

<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 wurde ein genau entsprechendes Element 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 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 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"

====Spezifikation====

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

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.

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

<references />

==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 (2015) HL7 Implementation Guide for CDA® R2: Ärztlicher Entlassungsbrief.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.2.6], http://www.elga.gv.at

|-
|[3]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Entlassungsbrief Pflege. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.3.6], http://www.elga.gv.at
|-
| || 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

|-
|[4]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Laborbefund.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.4.6], http://www.elga.gv.at

|-
|[5]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Befund bildgebende Diagnostik.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.5.6], http://www.elga.gv.at
|-
|[6]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: e-Medikation.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.8.6], http://www.elga.gv.at

|-
|[7]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2:
|-
| || Pflegesituationsbericht (2.06) [OID 1.2.40.0.34.7.12.6], http://www.elga.gv.at

|-
|[8]|| ELGA GmbH (2015) Organisationshandbuch.
|-
| || ELGA-Bereiche und Krankenanstalten (2.2.1) [OID 1.2.40.0.34.3.1.2.1.32], http://www.elga.gv.at
|}

==Revisionsliste==
{| class="wikitable"
!Vers.
!Datum
!Änderungsgrund
|-
|0.05
|16.05.2011
|Ergebnisse aus dem technischen Online-Meeting
|-
|2.00 Beta
|12.08.2011
|Erster "Release candidate" des Dokuments für internen Review innerhalb der Arbeitsgruppe.
|-
|2.00 rc1
|30.08.2011
|Redaktionelle Überarbeitung.
|-
|2.00 FWGD
|10.10.2011
|Fertigstellung des "Final Working Group Draft". Veröffentlicht für öffentlichen Review.
|-
|2.01
|11.06.2012
|Fertigstellung der gültigen Version 2.01 "Final". Abgrenzung des Geltungsbereiches (XDSDocumentEntry), Überarbeitung "PracticeSettingCode", Hinweis zu OID eingefügt (1.2.3), Überarbeitung der "parentDocumentRelationship", Typos ausgebessert
|-
|2.01
|21.12.2012
|Layout-Anpassung
|-
|2.01a
|07.03-2013
|Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16: "dieses Dokuments" eingefügt; 363: displayNameOf($code), "Of" gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch "2"-> "Enhanced" etc.) Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt Allgemein: Typos ausgebessert
|-
|2.02
|12.08.2013
|2.3.2 Präzisierung der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessert.
|-
|2.02
|12.08.2013
|2.3.2.3 PDF/A-1a-Vorschrift hinzugefügt
|-
|2.02
|13.08.2013
|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF/A-1a-
|-
|2.02
|17.09.2013
|Typos, Formatierung und Seitenumbrüche ausgebessert
|-
|2.02a
|06.02.2014
|Beispiele in Tabelle 3 korrigiert
|-
|2.03
|26.02.2014
|Definition von ReferenceIdList eingefügt
|-
|2.03
|03.03.2014
|Definition von intendedRecipient eingefügt
|-
|2.03
|03.03.2014
|Änderungen in Tabelle 3: LegalAuthenticator – von [R] auf [R2] geändert IntendedRecipient – von "-" auf [O] geändert, für Verwendung mit XDW vorgesehen ReferenceIdList hinzugefügt Den Namen des Value Sets von "ELGA-PracticeSettingCode" auf "ELGA-PracticeSettingCode-vs" geändert
|-
|2.03.
|03.03.2014
|Anhang gelöscht: 3.1. IHE ITI-TF3, Kapitel 4.1.7 "Document Definition Metadata" 3.2. IHE PCC-TF2, Kapitel 4.1.1 "XDSDocumentEntry Metadata" 3.3. IHE XDS Data Types
|-
|2.03
|03.03.2014
|Korrekturen: ITI Version einheitlich geändert auf "(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)". 1.1.3 Hinweis auf Terminologieserver hinzugefügt Tabelle 3 angepasst: EntryUUID Beschreibung geändert patientId Beschreibung geändert
|-
|2.03
|06.03.2014
|Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId
|-
|2.03
|21.03.2014
|Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt
|-
|2.03
|26.03.2014
|Kapitel 1.4. Korrektur von Dokumentverweisen
|-
|2.03a
|28.03.2014
|Kapitel 2.1 Korrektur von Fußnotennummern
|-
|2.03a
|28.03.2014
|Kapitel 2.2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000
|-
|2.03b
|1.7.2014
|Den Namen des Value Sets von "ELGA-PracticeSetting Code-vs" auf "ELGA_Practicesetting_VS" korrigiert
|-
|2.03b
|11.07.2014
|2.3.2.5 OID in der Spezifikation ergänzt
|-
|2.03b
|11.07.2014
|2.3.6 OID in der Spezifikation ergänzt
|-
|2.03b
|05.08.2014
|2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert
|-
|2.03b
|06.08.2014
|2.1 Überblickstabelle: ParentDocumentId und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]
|-
|2.03b
|06.08.2014
|Referenzen auf CDA Implementierungsleitfäden aktualisiert
|-
| colspan="3" |Version 2.05
|-
|2.05
|03.11.2014
|EntryUUID als "ELGA-Relevant" klassifiziert. Darstellung der Übersichtstabelle geändert
|-
|2.05
|03.11.2014
|2.2.15 TypeCode: ClassificationScheme im Beispiel korrigiert von "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" (falsch) auf "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" (richtig)
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht
|-
|2.05
|19.11.2014
|2.2.2. authorPerson: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden
|-
|2.05
|19.11.2014
|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software
|-
|2.05
|24.11.2014
|2.2.1.1. Spezifikation von authorInstitution: Fall entfernt, in dem die ID des GDA unbekannt ist. Die OID des GDA ist für ELGA-CDA [M]
|-
|2.05
|26.11.2014
|2.4 ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und ELGA-Flag. Auch in 2.1 entsprechend angegeben.
|-
|2.05
|12.03.2014
|Seite 2-3: Absätze "Verbindlichkeit", "Hinweise zur Verwendung" und "Erarbeitung des Implementierungsleitfadens" hinzugefügt.
|-
| colspan="3" |Version 2.06
|-
|2.06
|19.05.2015
|1.2.2. Codesysteme und Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.
|-
|2.06
|13.10.2015
|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch
|-
|2.06
|13.10.2015
|1.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.
|-
|2.06
|07.10.2015
|1.4.3. Kapitel "Metadaten aus 'On-Demand Documents' (ODD)" eingefügt
|-
|2.06
|10.09.2015
|2.1 Tabelle 3: Beschreibung der entryUUID ergänzt
|-
|2.06
|07.10.2015
|2.1 Tabelle 3: Spalte "Optionalität IHE" gelöscht, Spalte zur Definition von On-Demand-Documents eingefügt. objectType hinzugefügt patientid als E1 "ELGA relevant" deklariert (war E2)
|-
|2.06
|30.10.2015
|2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt wird, falls mehrere ID-Elemente angegeben sind.
|-
|2.06
|19.05.2015
|2.2.5. und 2.2.15: Typos verbessert
|-
|2.06
|29.10.2015
|2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt
|-
|2.06
|21.07.2015
|2.2.10. legalAuthenticator: Hinweis, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar ist.
|-
|2.06
|08.10.2015
|2.3.7 objectType hinzugefügt
|-
| colspan="3" |'''Version 2.06.2 (Nebenversion)''' x …betrifft Implementierung (erste Spalte)
|-
|
|01.08.2016
|Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
|-
|
|18.5.2016
|1.2 Erklärung zur Verwendung von XDS Folder und SubmissionSet hinzugefügt.
|-
|
|01.08.2016
|2.1. Tabelle 3: Korrektur der Optionalität von eventCodeList auf [R2], wie im Text bei 2.2.8 angegeben
|-
|x
|14.6.2016
|creationTime, serviceStartTime, serviceStopTime: Präzisierung der Vorgaben für Datum/Zeit, sie MUSS immer entsprechen der Angabe in CDA entweder 8 oder 14-stellig angegeben werden.
|-
|
|03.08.2016
|2.2.5, 2.3.2.2, 2.3.2.5, 2.3.5, 2.3.5.1, 2.3.5.1, 2.1, 1.4, 2.2.7, 2.2.11, 2.2.15, 2.3.6, 1.4.1.2 Korrektur der Großschreibung bei normativen Vorgaben
|-
|
|05.01.2017
|2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.
|-
|
|y
|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;"
|-
|
|y
|Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
|-
|
|y
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
|-
|
|y
|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.
|-
|
|
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
|-
|
|
|Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
|-
|
|
|Kapitel "4.2.7 legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
|-
|
|
|Kapitel "4.2.4 creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
|-
|
|y
|Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
|-
|
|y
|Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
|-
|
|
|Kapitel "4.2.2.1 Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
|-
|
|y
|Kapitel "XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.
|}

ILF:XDS Metadaten (Version 3)

2021-02-10T07:53:49Z

Sjencic: /* 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)}}
{{Underconstruction}}


{{#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.7]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0
|Submitted = ELGA GmbH
|Date = Februar 2021
|Copyright = 2011-
|Status = Kommentierung
|Period = n.a.
|OID = 1.2.40.0.34.7.6.7
|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 CDA Dokumenten in der ELGA Infrastruktur notwendig sind und wie sie aus den CDA Dokumenten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden XDS-Metadaten-Guide im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für elektronische Dokumente der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti IHE ITI]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref>.

Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012), aber auch für medizinische Dokumente im österreichischen Gesundheitswesen. 
TODO: XDSi-Metadaten einfügen https://collab.dicom-austria.at/pages/viewpage.action?pageId=20709391&preview=/20709391/20709392/AnbindungBilddaten_Gesamtarchitektur.pdf

=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 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]</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]</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 [ILF:Allgemeiner_Implementierungsleitfaden_2020]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at]). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020]'''.
{{EndILFBox}}

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website TODO: [[ILF:Ambulanzbefund_Guide|Ambulanzbefund Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
* Beispieldokumente
* Schematron-Prüfregeln
* Design-Beispiele
{{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:

*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 und Hinweise===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''Hinweis:''' Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden
{{EndYellowBox}}
''Hinweis auf anderen Implementierungsleitfaden:''
{{BeginILFBox}}
'''Verweis''' Verweis auf den Allgemeinen Leitfaden:…
{{EndILFBox}}
''Themenbezogenes CDA Beispiel-Fragment im XML Format:''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>

<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"
|-
! style="text-align:left" colspan="3"| Autoren
|-
! style="text-align:left" width="10%" | Kürzel ||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person1
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Herausgeber, Projektleiter, CDA-Koordinator
|- style="background:#FFFFFF"
| SSA || ELGA GmbH || Stefan Sabutsch
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Autoren
|- style="background:#FFFFFF"
| JB|| CodeWerk Software Services and Development GmbH|| Jürgen Brandstätter
|- style="background:#FFFFFF"
| SSA|| ELGA GmbH, HL7 Austria||Stefan Sabutsch
|- style="background:#FFFFFF"
| OKU|| ELGA GmbH|| Oliver Kuttin
|- style="background:#FFFFFF"
| KHO|| Wiener Krankenanstaltenverbund|| Konrad Hölzl
|}

1 Namen ohne Titel




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

Eine IHE XDS Registry verwaltet Dokumente und macht diese 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.

Für die Registrierung von Bilddaten über XDS-I wird eine eigene Spezifikation veröffentlicht.

Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.

==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten<ref name="ALF"></ref> in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten (Metadaten der XDSDocumentEntry Objekte)
** ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 (16.9.2020) Final Text''<ref name="IHE ITI TF-3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 17.0 (2020), 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> und den "ELGA CDA Implementierungsleitfäden" erstellt.

===XDS Folder===
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
===XDS Submission Sets===
Eine weitere Profilierung des XDS SubmissionSets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.

==Hinweise zur Verwendung des Dokuments==
===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}}

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

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. Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.

====Löschen aus der Registry [ITI-62]====
Das Löschen von Dokumenten in ELGA erfolgt ausschließlich in folgenden Fällen: Löschen durch Bürger, Opt-Out, Ablauf der Aufbewahrungsdauer (nach 10 Jahren müssen Dokumente gelöscht werden). Das Löschen erfolgt i.d.R. "sicher", sodass die Daten nicht wiederhergestellt werden können, sowohl für Verweise als auch Dokumente. Über die Transaktion ITI-62 kann ein Dokument aus der Registry gelöscht werden. Beim Löschen werden sowohl der Registereintrag als auch das Dokument aus dem Repository gelöscht; falls das Löschen der Dokumente aufgrund anderer Verpflichtungen ausgeschlossen ist, sind nur die Verweise zu löschen. Siehe "Organisationshandbuch ELGA-Bereiche und Krankenanstalten" [8].

===Größenbeschränkung ===
ELGA schreibt keine Größenbeschränkung für registrierte Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1]]].

==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-TF3).<ref name="IHE ITI TF-3"></ref>

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:''' Sehen Sie auch die Vorschrift zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument 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 korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.

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

Die IHE hat im Rahmen des "Patient 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="IHE ITI"></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, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus Bilddaten (KOS)===
TODO:

===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'''
# 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"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" rowspan="2" |'''Metadaten Element'''
|'''Optionalität'''
| rowspan="2" |'''Beschreibung'''
| rowspan="2" |'''Que-'''

'''lle'''
|-
|'''ELGA'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''R'''
|Die Person, welche das Dokument verfasst hat
|<nowiki>-</nowiki>
|-
| rowspan="4" |
|authorInstitution
|'''R'''
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|A/K
|-
|authorPerson
|'''R2'''
|Daten der Person

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

z.B.: 55113-5 "KOSObjekte"
|A
|-
| colspan="2" |'''confidentialityCode'''
|'''R'''
|Vertraulichkeitscode. Fester Wert "N"
|A
|-
| colspan="2" |'''creationTime'''
|'''R'''
|Zeitpunkt der Dokumentenerstellung
|K
|-
| colspan="2" |'''eventCodeList'''
|'''R'''
|Liste von Codes von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''eventCodeDisplayNameList'''
|'''R2'''
|Liste von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''intendedRecipient'''
|'''X'''
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
| -
|-
| colspan="2" |'''languageCode'''
|'''R'''
|Sprachcode. Fester Wert "de-AT"
|A
|-
| colspan="2" |'''legalAuthenticator'''
|'''X'''
|Rechtlicher Unterzeichner
| -
|-
| colspan="2" |'''serviceStartTime'''
|'''R'''
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|K
|-
| colspan="2" |'''serviceStopTime'''
|'''X'''
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
| -
|-
| colspan="2" |'''sourcePatientId'''
|'''R'''
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''sourcePatientInfo'''
|'''R'''
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''Title'''
|'''R'''
|Titel des Dokuments
|A/K
|-
| colspan="2" |'''typeCode'''
|'''R'''
|Objekttyp (Unterklasse)

codierter Wert
|A
|-
| colspan="2" |'''uniqueId'''
|'''R'''
|Global eindeutige ID des Objektes

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

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

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

 



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

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

TODO: urn:ihe:iti:xds:2015:encounterId als referenceIdList Eintrag ergänzen?

{| 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 1: Legende zur Spalte "Quelle" der folgenden Tabelle''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| 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="45%" |'''Beschreibung '''|| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
|- style="background:#CBD7F1"
|'''SD9'''||'''OD10'''
|- 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)||'''R'''||'''R'''||Die Person, welche das Dokument verfasst hat||-
|- style="background:white"
| ||authorInstitution||'''R'''||'''R'''||ID der Organisation, der die Person angehört. (OID aus dem GDA-Index)||C
|- style="background:white"
| ||authorPerson||'''R'''||'''R'''||Daten der Person (Name, ID, etc.)||C
|- style="background:white"
| ||authorRole||'''R2'''||'''X'''||Rolle der Person||C
|- style="background:white"
| ||authorSpeciality||'''R2'''||'''X'''||Fachrichtung der Person||C
|- style="background:white"
| colspan="2" |'''classCode'''||'''R'''||'''R'''||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"||C
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''R'''||'''X'''||Vertraulichkeitscode des Dokuments||C
|- style="background:white"
| colspan="2" |'''creationTime'''||'''R'''||'''R'''||Zeitpunkt der Dokumentenerstellung||C
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R2'''||'''R2'''||Liste von Gesundheitsdienstleistungen||C
|-
| colspan="2" |'''formatCode'''
|'''R'''
|'''R'''
|Format des Dokumenteninhalts
|C
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O'''||'''X'''||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C
|- style="background:white"
| colspan="2" |'''languageCode'''||'''R'''||'''R'''||Sprachcode des Dokuments z.B.: "de-AT"||C
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R2'''||'''X'''||Rechtlicher Unterzeichner des Dokuments||C
|-
| colspan="2" |'''practiceSettingCode'''
|'''R'''
|'''R'''
|Fachliche Zuordnung des Dokuments
|C
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R2'''||'''O'''||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R2'''||'''O'''||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung||C
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''R'''||'''R'''||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH||C
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''X'''||'''X'''||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C
|- style="background:white"
| colspan="2" |'''Title'''||'''R'''||'''R'''||Titel des Dokuments||C
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''R'''||'''R'''||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"||C
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''R'''||'''R'''||Global eindeutige ID des Dokuments||C
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''R'''||'''O'''||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert||C
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''R'''||'''R'''||Klassifizierung des GDA
|C

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
|- style="background:white"
| colspan="2" |'''availabilityStatus'''||'''R'''||'''R'''||Gültigkeit des Dokuments||E1
|- style="background:white"
| colspan="2" |'''mimeType'''||'''R'''||'''R'''||Mime Type des Dokuments z.B.: "text/xml" für CDA||E1
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O'''||'''O'''||Verweis auf ein referenziertes Dokument||E1
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O'''||'''O'''||Typ der Relation zu dem referenzierten Dokument. z.B.: RPLC, XFRM||E1
|- style="background:white"
| colspan="2" |'''entryUUID'''||'''R'''||'''R'''||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)||E1
|- style="background:white"
| colspan="2" |'''objectType'''||'''R'''||'''R'''||Typ des DocumentEntries (SD oder ODD)||E1
|- style="background:white"
| colspan="2" |'''comments'''||'''O'''||'''O'''||Kommentar zum Dokument||E2
|- style="background:white"
| colspan="2" |'''patientId'''||'''R'''||'''R'''||Patienten-ID in der XDS Affinity Domain||E1

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|- style="background:white"
| colspan="2" |'''hash'''||'''R'''||'''X'''||Hash Wert des Dokuments. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''homeCommunityId'''||'''R'''||'''R'''||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.||A
|- style="background:white"
| colspan="2" |'''repositoryUniqueId '''||'''R'''||'''R'''||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''size'''||'''R'''||'''X'''||Größe des Dokuments in Bytes. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''URI'''14||'''-'''||'''-'''||'''Wird in XDS nicht verwendet'''||A
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|- style="background:white"
| colspan="2" |'''elgaFlag'''||'''R'''||'''R'''||Kennzeichnet ein Dokument als "ELGA-Dokument"||B
|- style="background:white"
| colspan="2" |'''elgaHash'''||'''R'''||'''R'''||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B
|}
''Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)''

9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht. 
10 OD: "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 SubmissionSets übereinstimmen. 
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. 
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein. 
14 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.


=XDS-I Metadaten für DICOM KOS Objekte=
==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

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.

{| class="wikitable"
|'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

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

'''im KOS'''
|'''Beschreibung'''
|-
| colspan="5" |author
|-
|author.authorInstitution
|R
|
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl den Namen als auch die OID der Institution im 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.
|-
| colspan="5" |Die die Studie durchführende Person ist als author anzugeben:
|-
|author.authorPerson
|R2
|(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.
|-
|
|
|'''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.
|-
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|-
|author.authorPerson
|R2
|(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.
|-
|creationTime
|R
|(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.
|-
|eventCodeList
|R
|
|
|Enthält den APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|eventCodeListDisplayNameList
|R2
|
|
|Enthält den Display Name des APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|serviceStartTime
|R
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|-
|sourcePatientId
|R
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|-
|sourcePatientInfo
|R
|(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.
|-
|title
|R
|(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".
 
|-
|uniqueId
|R
|
|(0008,0018)
|Die SOP Instance UID des KOS
|-
| colspan="4" |referenceIdList
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|-
|value mit CXi.5 =

"<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>"
|R
|(0020,000D) oder ein vergleich-bares Attribut
|(0020,000D) oder ein vergleich-bares 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 Kapitel 8.2.2.
|-
|value mit CXi.5 =

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
|O
|(0008,0050) oder ein vergleich-bares 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.
|-
|comments
|O
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

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 Radiology Technical Framework, vol2, rev. 19, "4.68.4.1.2.3.2 DocumentEntry Metadata" sowie IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. 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 kann

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

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

$id ... OID der Organisation aus dem GDA-Index

concat( 
$name,"^^^^^^^^^", 
$id 
) 
<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-TF3].
====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[[#%20ftn1|[1]]], wenn vorhanden
#*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) ----[[#%20ftnref1|[1]]] Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den DICOM Attribut Modality der Studie abgleitet werden
#*Modalität[[#%20ftn1|[2]]]: Attribut "Modality", (0008,0060)
#*Hersteller: Attribut "Manufacturer", (0008,0070)
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</nowiki>

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

$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>2323^MusterDoc^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
=====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-TF3].

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objektation 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|4.2.15]]
|}

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "[https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen hl7-austria-Dokumentenklassen]" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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 "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]".

====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 registrieren 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)
#Sollten 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''[[#%20ftn1|[3]]] berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

[[#%20ftnref1|[3]]] <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</nowiki>
====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 +(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. 20160518 in 20160518000000).

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-TF3].{{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".[[# ftn4|[4]]])
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.
----[[# ftnref4|[4]]] DICOM Austria: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten", 22.01.2020, <nowiki>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</nowiki> (zuletzt besucht am 12.3.2020)

====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 des DICOM Objektes aus den Attributen des KOS Objektes:
#*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. 20160518 in 20160518000000).

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel 3.2.12 sourcePatientId gemappt und verwendet.

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

====Spezifikation (empfohlene Variante)====
'''sourcePatientInfo''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = concat(

$patientID, "^^^&amp;",

$oid, "&amp;ISO"

)

Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO

$name = ""

$birthtime = ""

$gender = ""

$addr = "" <pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientInfo">
<ValueList>
<Value>PID-3|$id</Value>
<Value>PID-5|$name</Value>
<Value>PID-7|$birthtime</Value>
<Value>PID-8|$gender</Value>
<Value>PID-11|$addr</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modailty 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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 entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.

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 zwei unterschiedliche Einträge in referenceIdList notwendig:

#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId)
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number)

'''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="IHE ITI TF-3"></ref>

{| 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 z.B. 1.2.40.0.34.99.999

concat

(

$id, "^^^^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

"&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>^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^^^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"

====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 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 [https://tools.ietf.org/html/rfc2045 <nowiki>RFC 2045[6]</nowiki>] und RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

[6] <nowiki>http://tools.ietf.org/html/rfc2045</nowiki>

[7] <nowiki>http://tools.ietf.org/html/rfc2049</nowiki>

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das 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 "[[urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be]]" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

====Spezifikation====

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

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.

===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 weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

==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 SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description 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"

#GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
{{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 
) 
<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-TF3].

====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). Mindestens eine Person

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

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

====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 '''''[R2]'''''.
#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 '''''[R2]'''''.
#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|4.2.15]]
|}

 

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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===
Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:
##ClinicalDocument/effectiveTime
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.
#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
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-TF3].
{{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 Service-Events wie folgt abgelegt:
##ClinicalDocument/documentationOf/serviceEvent
#Mehrere dieser Service-Events können durch beliebig viele "documentationOf" Elemente ausgedrückt werden.
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines Service-Events verpflichtend, wenn bekannt [R2].
#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 Service Event 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 PCC Profil definiert in Kapitel "Medical Document Bindings" Spezialbehandlungen für gewissen 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}}

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

===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 '''''[R2]'''''.

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

TODO: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.

====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] … Lokale ID des Patienten vom einbringenden System
##d[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-TF3].

===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|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 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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.
uniqueId wird als ebRIM

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===
Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommen.
{{BeginYellowBox}}
Im Rahmen von ELGA ist die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten einzubringen. Weitere andere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.
{{EndYellowBox}}

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

====Spezifikation====
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="IHE ITI TF-3"></ref>

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

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

referenceIdList wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat

(

ClinicalDocument/setId/@extension, "^^^",

ClinicalDocument/setId/@root, "^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

homeCommunityId

)

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;amp;1.2.40.0.34.99.111.1.1
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>
^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</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^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"
<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><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;2.25
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki>
&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

====Bildungsregel für den formatCodeDisplayName====
TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.

Der formatCodeDisplayName ist analog zum formatCode aus den displayNames des entsprechenden Value Sets [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS] zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels ":" (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).

'''Beispiele:'''

*'''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''
*'''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''
*'''ELGA Laborbefund, EIS Full Support v2.06+'''

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = gemäß Liste der in ELGA gültigen FormatCodes 
$codeSystem = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]
<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">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>
<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">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>

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, das das DocumentEntry repräsentiert.

Folgende Mime-Types sind für Dokumente zugelassen: 
CDA R2: '''text/xml''' 
DICOM/KOS: '''application/dicom''' 

<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 wurde ein genau entsprechendes Element 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 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 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"

====Spezifikation====

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

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.

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

<references />

==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 (2015) HL7 Implementation Guide for CDA® R2: Ärztlicher Entlassungsbrief.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.2.6], http://www.elga.gv.at

|-
|[3]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Entlassungsbrief Pflege. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.3.6], http://www.elga.gv.at
|-
| || 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

|-
|[4]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Laborbefund.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.4.6], http://www.elga.gv.at

|-
|[5]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Befund bildgebende Diagnostik.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.5.6], http://www.elga.gv.at
|-
|[6]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: e-Medikation.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.8.6], http://www.elga.gv.at

|-
|[7]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2:
|-
| || Pflegesituationsbericht (2.06) [OID 1.2.40.0.34.7.12.6], http://www.elga.gv.at

|-
|[8]|| ELGA GmbH (2015) Organisationshandbuch.
|-
| || ELGA-Bereiche und Krankenanstalten (2.2.1) [OID 1.2.40.0.34.3.1.2.1.32], http://www.elga.gv.at
|}

==Revisionsliste==
{| class="wikitable"
!Vers.
!Datum
!Änderungsgrund
|-
|0.05
|16.05.2011
|Ergebnisse aus dem technischen Online-Meeting
|-
|2.00 Beta
|12.08.2011
|Erster "Release candidate" des Dokuments für internen Review innerhalb der Arbeitsgruppe.
|-
|2.00 rc1
|30.08.2011
|Redaktionelle Überarbeitung.
|-
|2.00 FWGD
|10.10.2011
|Fertigstellung des "Final Working Group Draft". Veröffentlicht für öffentlichen Review.
|-
|2.01
|11.06.2012
|Fertigstellung der gültigen Version 2.01 "Final". Abgrenzung des Geltungsbereiches (XDSDocumentEntry), Überarbeitung "PracticeSettingCode", Hinweis zu OID eingefügt (1.2.3), Überarbeitung der "parentDocumentRelationship", Typos ausgebessert
|-
|2.01
|21.12.2012
|Layout-Anpassung
|-
|2.01a
|07.03-2013
|Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16: "dieses Dokuments" eingefügt; 363: displayNameOf($code), "Of" gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch "2"-> "Enhanced" etc.) Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt Allgemein: Typos ausgebessert
|-
|2.02
|12.08.2013
|2.3.2 Präzisierung der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessert.
|-
|2.02
|12.08.2013
|2.3.2.3 PDF/A-1a-Vorschrift hinzugefügt
|-
|2.02
|13.08.2013
|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF/A-1a-
|-
|2.02
|17.09.2013
|Typos, Formatierung und Seitenumbrüche ausgebessert
|-
|2.02a
|06.02.2014
|Beispiele in Tabelle 3 korrigiert
|-
|2.03
|26.02.2014
|Definition von ReferenceIdList eingefügt
|-
|2.03
|03.03.2014
|Definition von intendedRecipient eingefügt
|-
|2.03
|03.03.2014
|Änderungen in Tabelle 3: LegalAuthenticator – von [R] auf [R2] geändert IntendedRecipient – von "-" auf [O] geändert, für Verwendung mit XDW vorgesehen ReferenceIdList hinzugefügt Den Namen des Value Sets von "ELGA-PracticeSettingCode" auf "ELGA-PracticeSettingCode-vs" geändert
|-
|2.03.
|03.03.2014
|Anhang gelöscht: 3.1. IHE ITI-TF3, Kapitel 4.1.7 "Document Definition Metadata" 3.2. IHE PCC-TF2, Kapitel 4.1.1 "XDSDocumentEntry Metadata" 3.3. IHE XDS Data Types
|-
|2.03
|03.03.2014
|Korrekturen: ITI Version einheitlich geändert auf "(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)". 1.1.3 Hinweis auf Terminologieserver hinzugefügt Tabelle 3 angepasst: EntryUUID Beschreibung geändert patientId Beschreibung geändert
|-
|2.03
|06.03.2014
|Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId
|-
|2.03
|21.03.2014
|Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt
|-
|2.03
|26.03.2014
|Kapitel 1.4. Korrektur von Dokumentverweisen
|-
|2.03a
|28.03.2014
|Kapitel 2.1 Korrektur von Fußnotennummern
|-
|2.03a
|28.03.2014
|Kapitel 2.2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000
|-
|2.03b
|1.7.2014
|Den Namen des Value Sets von "ELGA-PracticeSetting Code-vs" auf "ELGA_Practicesetting_VS" korrigiert
|-
|2.03b
|11.07.2014
|2.3.2.5 OID in der Spezifikation ergänzt
|-
|2.03b
|11.07.2014
|2.3.6 OID in der Spezifikation ergänzt
|-
|2.03b
|05.08.2014
|2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert
|-
|2.03b
|06.08.2014
|2.1 Überblickstabelle: ParentDocumentId und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]
|-
|2.03b
|06.08.2014
|Referenzen auf CDA Implementierungsleitfäden aktualisiert
|-
| colspan="3" |Version 2.05
|-
|2.05
|03.11.2014
|EntryUUID als "ELGA-Relevant" klassifiziert. Darstellung der Übersichtstabelle geändert
|-
|2.05
|03.11.2014
|2.2.15 TypeCode: ClassificationScheme im Beispiel korrigiert von "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" (falsch) auf "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" (richtig)
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht
|-
|2.05
|19.11.2014
|2.2.2. authorPerson: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden
|-
|2.05
|19.11.2014
|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software
|-
|2.05
|24.11.2014
|2.2.1.1. Spezifikation von authorInstitution: Fall entfernt, in dem die ID des GDA unbekannt ist. Die OID des GDA ist für ELGA-CDA [M]
|-
|2.05
|26.11.2014
|2.4 ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und ELGA-Flag. Auch in 2.1 entsprechend angegeben.
|-
|2.05
|12.03.2014
|Seite 2-3: Absätze "Verbindlichkeit", "Hinweise zur Verwendung" und "Erarbeitung des Implementierungsleitfadens" hinzugefügt.
|-
| colspan="3" |Version 2.06
|-
|2.06
|19.05.2015
|1.2.2. Codesysteme und Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.
|-
|2.06
|13.10.2015
|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch
|-
|2.06
|13.10.2015
|1.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.
|-
|2.06
|07.10.2015
|1.4.3. Kapitel "Metadaten aus 'On-Demand Documents' (ODD)" eingefügt
|-
|2.06
|10.09.2015
|2.1 Tabelle 3: Beschreibung der entryUUID ergänzt
|-
|2.06
|07.10.2015
|2.1 Tabelle 3: Spalte "Optionalität IHE" gelöscht, Spalte zur Definition von On-Demand-Documents eingefügt. objectType hinzugefügt patientid als E1 "ELGA relevant" deklariert (war E2)
|-
|2.06
|30.10.2015
|2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt wird, falls mehrere ID-Elemente angegeben sind.
|-
|2.06
|19.05.2015
|2.2.5. und 2.2.15: Typos verbessert
|-
|2.06
|29.10.2015
|2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt
|-
|2.06
|21.07.2015
|2.2.10. legalAuthenticator: Hinweis, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar ist.
|-
|2.06
|08.10.2015
|2.3.7 objectType hinzugefügt
|-
| colspan="3" |'''Version 2.06.2 (Nebenversion)''' x …betrifft Implementierung (erste Spalte)
|-
|
|01.08.2016
|Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
|-
|
|18.5.2016
|1.2 Erklärung zur Verwendung von XDS Folder und SubmissionSet hinzugefügt.
|-
|
|01.08.2016
|2.1. Tabelle 3: Korrektur der Optionalität von eventCodeList auf [R2], wie im Text bei 2.2.8 angegeben
|-
|x
|14.6.2016
|creationTime, serviceStartTime, serviceStopTime: Präzisierung der Vorgaben für Datum/Zeit, sie MUSS immer entsprechen der Angabe in CDA entweder 8 oder 14-stellig angegeben werden.
|-
|
|03.08.2016
|2.2.5, 2.3.2.2, 2.3.2.5, 2.3.5, 2.3.5.1, 2.3.5.1, 2.1, 1.4, 2.2.7, 2.2.11, 2.2.15, 2.3.6, 1.4.1.2 Korrektur der Großschreibung bei normativen Vorgaben
|-
|
|05.01.2017
|2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.
|-
|
|y
|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;"
|-
|
|y
|Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
|-
|
|y
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
|-
|
|y
|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.
|-
|
|
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
|-
|
|
|Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
|-
|
|
|Kapitel "4.2.7 legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
|-
|
|
|Kapitel "4.2.4 creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
|-
|
|y
|Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
|-
|
|y
|Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
|-
|
|
|Kapitel "4.2.2.1 Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
|-
|
|y
|Kapitel "XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.
|}

ILF:XDS Metadaten (Version 3)

2021-02-10T07:46:27Z

Sjencic: /* 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)}}
{{Underconstruction}}


{{#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.7]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0
|Submitted = ELGA GmbH
|Date = Februar 2021
|Copyright = 2011-
|Status = Kommentierung
|Period = n.a.
|OID = 1.2.40.0.34.7.6.7
|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 CDA Dokumenten in der ELGA Infrastruktur notwendig sind und wie sie aus den CDA Dokumenten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden XDS-Metadaten-Guide im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für elektronische Dokumente der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti IHE ITI]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref>.

Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012), aber auch für medizinische Dokumente im österreichischen Gesundheitswesen. 
TODO: XDSi-Metadaten einfügen https://collab.dicom-austria.at/pages/viewpage.action?pageId=20709391&preview=/20709391/20709392/AnbindungBilddaten_Gesamtarchitektur.pdf

=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 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]</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]</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 [ILF:Allgemeiner_Implementierungsleitfaden_2020]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at]). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020]'''.
{{EndILFBox}}

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website TODO: [[ILF:Ambulanzbefund_Guide|Ambulanzbefund Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
* Beispieldokumente
* Schematron-Prüfregeln
* Design-Beispiele
{{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:

*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 und Hinweise===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''Hinweis:''' Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden
{{EndYellowBox}}
''Hinweis auf anderen Implementierungsleitfaden:''
{{BeginILFBox}}
'''Verweis''' Verweis auf den Allgemeinen Leitfaden:…
{{EndILFBox}}
''Themenbezogenes CDA Beispiel-Fragment im XML Format:''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>

<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"
|-
! style="text-align:left" colspan="3"| Autoren
|-
! style="text-align:left" width="10%" | Kürzel ||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person1
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Herausgeber, Projektleiter, CDA-Koordinator
|- style="background:#FFFFFF"
| SSA || ELGA GmbH || Stefan Sabutsch
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Autoren
|- style="background:#FFFFFF"
| JB|| CodeWerk Software Services and Development GmbH|| Jürgen Brandstätter
|- style="background:#FFFFFF"
| SSA|| ELGA GmbH, HL7 Austria||Stefan Sabutsch
|- style="background:#FFFFFF"
| OKU|| ELGA GmbH|| Oliver Kuttin
|- style="background:#FFFFFF"
| KHO|| Wiener Krankenanstaltenverbund|| Konrad Hölzl
|}

1 Namen ohne Titel




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

Eine IHE XDS Registry verwaltet Dokumente und macht diese 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.

Für die Registrierung von Bilddaten über XDS-I wird eine eigene Spezifikation veröffentlicht.

Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.

==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten<ref name="ALF"></ref> in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten (Metadaten der XDSDocumentEntry Objekte)
** ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 (16.9.2020) Final Text''<ref name="IHE ITI TF-3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 17.0 (2020), 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> und den "ELGA CDA Implementierungsleitfäden" erstellt.

===XDS Folder===
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
===XDS Submission Sets===
Eine weitere Profilierung des XDS SubmissionSets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.

==Hinweise zur Verwendung des Dokuments==
===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}}

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

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. Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.

====Löschen aus der Registry [ITI-62]====
Das Löschen von Dokumenten in ELGA erfolgt ausschließlich in folgenden Fällen: Löschen durch Bürger, Opt-Out, Ablauf der Aufbewahrungsdauer (nach 10 Jahren müssen Dokumente gelöscht werden). Das Löschen erfolgt i.d.R. "sicher", sodass die Daten nicht wiederhergestellt werden können, sowohl für Verweise als auch Dokumente. Über die Transaktion ITI-62 kann ein Dokument aus der Registry gelöscht werden. Beim Löschen werden sowohl der Registereintrag als auch das Dokument aus dem Repository gelöscht; falls das Löschen der Dokumente aufgrund anderer Verpflichtungen ausgeschlossen ist, sind nur die Verweise zu löschen. Siehe "Organisationshandbuch ELGA-Bereiche und Krankenanstalten" [8].

===Größenbeschränkung ===
ELGA schreibt keine Größenbeschränkung für registrierte Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1]]].

==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-TF3).<ref name="IHE ITI TF-3"></ref>

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:''' Sehen Sie auch die Vorschrift zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument 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 korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.

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

Die IHE hat im Rahmen des "Patient 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="IHE ITI"></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, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus Bilddaten (KOS)===
TODO:

===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'''
# 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"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" rowspan="2" |'''Metadaten Element'''
|'''Optionalität'''
| rowspan="2" |'''Beschreibung'''
| rowspan="2" |'''Que-'''

'''lle'''
|-
|'''ELGA'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''R'''
|Die Person, welche das Dokument verfasst hat
|<nowiki>-</nowiki>
|-
| rowspan="4" |
|authorInstitution
|'''R'''
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|A/K
|-
|authorPerson
|'''R2'''
|Daten der Person

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

z.B.: 55113-5 "KOSObjekte"
|A
|-
| colspan="2" |'''confidentialityCode'''
|'''R'''
|Vertraulichkeitscode. Fester Wert "N"
|A
|-
| colspan="2" |'''creationTime'''
|'''R'''
|Zeitpunkt der Dokumentenerstellung
|K
|-
| colspan="2" |'''eventCodeList'''
|'''R'''
|Liste von Codes von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''eventCodeDisplayNameList'''
|'''R2'''
|Liste von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''intendedRecipient'''
|'''X'''
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
| -
|-
| colspan="2" |'''languageCode'''
|'''R'''
|Sprachcode. Fester Wert "de-AT"
|A
|-
| colspan="2" |'''legalAuthenticator'''
|'''X'''
|Rechtlicher Unterzeichner
| -
|-
| colspan="2" |'''serviceStartTime'''
|'''R'''
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|K
|-
| colspan="2" |'''serviceStopTime'''
|'''X'''
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
| -
|-
| colspan="2" |'''sourcePatientId'''
|'''R'''
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''sourcePatientInfo'''
|'''R'''
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''Title'''
|'''R'''
|Titel des Dokuments
|A/K
|-
| colspan="2" |'''typeCode'''
|'''R'''
|Objekttyp (Unterklasse)

codierter Wert
|A
|-
| colspan="2" |'''uniqueId'''
|'''R'''
|Global eindeutige ID des Objektes

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

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

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

 



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

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

TODO: urn:ihe:iti:xds:2015:encounterId als referenceIdList Eintrag ergänzen?

{| 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 1: Legende zur Spalte "Quelle" der folgenden Tabelle''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| 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="45%" |'''Beschreibung '''|| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
|- style="background:#CBD7F1"
|'''SD9'''||'''OD10'''
|- 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)||'''R'''||'''R'''||Die Person, welche das Dokument verfasst hat||-
|- style="background:white"
| ||authorInstitution||'''R'''||'''R'''||ID der Organisation, der die Person angehört. (OID aus dem GDA-Index)||C
|- style="background:white"
| ||authorPerson||'''R'''||'''R'''||Daten der Person (Name, ID, etc.)||C
|- style="background:white"
| ||authorRole||'''R2'''||'''X'''||Rolle der Person||C
|- style="background:white"
| ||authorSpeciality||'''R2'''||'''X'''||Fachrichtung der Person||C
|- style="background:white"
| colspan="2" |'''classCode'''||'''R'''||'''R'''||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"||C
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''R'''||'''X'''||Vertraulichkeitscode des Dokuments||C
|- style="background:white"
| colspan="2" |'''creationTime'''||'''R'''||'''R'''||Zeitpunkt der Dokumentenerstellung||C
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R2'''||'''R2'''||Liste von Gesundheitsdienstleistungen||C
|-
| colspan="2" |'''formatCode'''
|'''R'''
|'''R'''
|Format des Dokumenteninhalts
|C
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O'''||'''X'''||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C
|- style="background:white"
| colspan="2" |'''languageCode'''||'''R'''||'''R'''||Sprachcode des Dokuments z.B.: "de-AT"||C
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R2'''||'''X'''||Rechtlicher Unterzeichner des Dokuments||C
|-
| colspan="2" |'''practiceSettingCode'''
|'''R'''
|'''R'''
|Fachliche Zuordnung des Dokuments
|C
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R2'''||'''O'''||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R2'''||'''O'''||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung||C
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''R'''||'''R'''||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH||C
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''X'''||'''X'''||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C
|- style="background:white"
| colspan="2" |'''Title'''||'''R'''||'''R'''||Titel des Dokuments||C
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''R'''||'''R'''||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"||C
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''R'''||'''R'''||Global eindeutige ID des Dokuments||C
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''R'''||'''O'''||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert||C
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''R'''||'''R'''||Klassifizierung des GDA
|C

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
|- style="background:white"
| colspan="2" |'''availabilityStatus'''||'''R'''||'''R'''||Gültigkeit des Dokuments||E1
|- style="background:white"
| colspan="2" |'''mimeType'''||'''R'''||'''R'''||Mime Type des Dokuments z.B.: "text/xml" für CDA||E1
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O'''||'''O'''||Verweis auf ein referenziertes Dokument||E1
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O'''||'''O'''||Typ der Relation zu dem referenzierten Dokument. z.B.: RPLC, XFRM||E1
|- style="background:white"
| colspan="2" |'''entryUUID'''||'''R'''||'''R'''||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)||E1
|- style="background:white"
| colspan="2" |'''objectType'''||'''R'''||'''R'''||Typ des DocumentEntries (SD oder ODD)||E1
|- style="background:white"
| colspan="2" |'''comments'''||'''O'''||'''O'''||Kommentar zum Dokument||E2
|- style="background:white"
| colspan="2" |'''patientId'''||'''R'''||'''R'''||Patienten-ID in der XDS Affinity Domain||E1

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|- style="background:white"
| colspan="2" |'''hash'''||'''R'''||'''X'''||Hash Wert des Dokuments. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''homeCommunityId'''||'''R'''||'''R'''||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.||A
|- style="background:white"
| colspan="2" |'''repositoryUniqueId '''||'''R'''||'''R'''||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''size'''||'''R'''||'''X'''||Größe des Dokuments in Bytes. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''URI'''14||'''-'''||'''-'''||'''Wird in XDS nicht verwendet'''||A
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|- style="background:white"
| colspan="2" |'''elgaFlag'''||'''R'''||'''R'''||Kennzeichnet ein Dokument als "ELGA-Dokument"||B
|- style="background:white"
| colspan="2" |'''elgaHash'''||'''R'''||'''R'''||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B
|}
''Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)''

9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht. 
10 OD: "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 SubmissionSets übereinstimmen. 
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. 
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein. 
14 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.


=XDS-I Metadaten für DICOM KOS Objekte=
==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

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.

{| class="wikitable"
|'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

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

'''im KOS'''
|'''Beschreibung'''
|-
| colspan="5" |author
|-
|author.authorInstitution
|R
|
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl den Namen als auch die OID der Institution im 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.
|-
| colspan="5" |Die die Studie durchführende Person ist als author anzugeben:
|-
|author.authorPerson
|R2
|(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.
|-
|
|
|'''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.
|-
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|-
|author.authorPerson
|R2
|(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.
|-
|creationTime
|R
|(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.
|-
|eventCodeList
|R
|
|
|Enthält den APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|eventCodeListDisplayNameList
|R2
|
|
|Enthält den Display Name des APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|serviceStartTime
|R
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|-
|sourcePatientId
|R
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|-
|sourcePatientInfo
|R
|(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.
|-
|title
|R
|(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".
 
|-
|uniqueId
|R
|
|(0008,0018)
|Die SOP Instance UID des KOS
|-
| colspan="4" |referenceIdList
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|-
|value mit CXi.5 =

"<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>"
|R
|(0020,000D) oder ein vergleich-bares Attribut
|(0020,000D) oder ein vergleich-bares 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 Kapitel 8.2.2.
|-
|value mit CXi.5 =

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
|O
|(0008,0050) oder ein vergleich-bares 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.
|-
|comments
|O
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

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 Radiology Technical Framework, vol2, rev. 19, "4.68.4.1.2.3.2 DocumentEntry Metadata" sowie IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. 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 kann

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

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

$id ... OID der Organisation aus dem GDA-Index

concat( 
$name,"^^^^^^^^^", 
$id 
) 
<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-TF3].
====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[[#%20ftn1|[1]]], wenn vorhanden
#*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) ----[[#%20ftnref1|[1]]] Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den DICOM Attribut Modality der Studie abgleitet werden
#*Modalität[[#%20ftn1|[2]]]: Attribut "Modality", (0008,0060)
#*Hersteller: Attribut "Manufacturer", (0008,0070)
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</nowiki>

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

$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>2323^MusterDoc^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
=====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-TF3].

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objektation 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|4.2.15]]
|}

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "[https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen hl7-austria-Dokumentenklassen]" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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 "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]".

====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 registrieren 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)
#Sollten 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''[[#%20ftn1|[3]]] berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

[[#%20ftnref1|[3]]] <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</nowiki>
====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 +(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. 20160518 in 20160518000000).

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-TF3].{{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".[[# ftn4|[4]]])
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.
----[[# ftnref4|[4]]] DICOM Austria: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten", 22.01.2020, <nowiki>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</nowiki> (zuletzt besucht am 12.3.2020)

====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 des DICOM Objektes aus den Attributen des KOS Objektes:
#*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. 20160518 in 20160518000000).

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel 3.2.12 sourcePatientId gemappt und verwendet.

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

====Spezifikation (empfohlene Variante)====
'''sourcePatientInfo''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = concat(

$patientID, "^^^&amp;",

$oid, "&amp;ISO"

)

Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO

$name = ""

$birthtime = ""

$gender = ""

$addr = "" <pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientInfo">
<ValueList>
<Value>PID-3|$id</Value>
<Value>PID-5|$name</Value>
<Value>PID-7|$birthtime</Value>
<Value>PID-8|$gender</Value>
<Value>PID-11|$addr</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modailty 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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 entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.

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 zwei unterschiedliche Einträge in referenceIdList notwendig:

#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId)
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number)

'''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="IHE ITI TF-3"></ref>

{| 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 z.B. 1.2.40.0.34.99.999

concat

(

$id, "^^^^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

"&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>^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^^^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"

====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 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 [https://tools.ietf.org/html/rfc2045 <nowiki>RFC 2045[6]</nowiki>] und RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

[6] <nowiki>http://tools.ietf.org/html/rfc2045</nowiki>

[7] <nowiki>http://tools.ietf.org/html/rfc2049</nowiki>

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das 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 "[[urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be]]" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

====Spezifikation====

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

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.

===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 weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

==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 SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description 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"

#GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
{{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 
) 
<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-TF3].

====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). Mindestens eine Person

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

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

====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 '''''[R2]'''''.
#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 '''''[R2]'''''.
#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|4.2.15]]
|}

 

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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===
Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:
##ClinicalDocument/effectiveTime
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.
#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
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-TF3].
{{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 Service-Events wie folgt abgelegt:
##ClinicalDocument/documentationOf/serviceEvent
#Mehrere dieser Service-Events können durch beliebig viele "documentationOf" Elemente ausgedrückt werden.
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines Service-Events verpflichtend, wenn bekannt [R2].
#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 Service Event 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 PCC Profil definiert in Kapitel "Medical Document Bindings" Spezialbehandlungen für gewissen 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}}

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

===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 '''''[R2]'''''.

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

TODO: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.

====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] … Lokale ID des Patienten vom einbringenden System
##d[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-TF3].

===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|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 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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.
uniqueId wird als ebRIM

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===
Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommen.
{{BeginYellowBox}}
Im Rahmen von ELGA ist die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten einzubringen. Weitere andere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.
{{EndYellowBox}}

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

====Spezifikation====
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="IHE ITI TF-3"></ref>

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

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

referenceIdList wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat

(

ClinicalDocument/setId/@extension, "^^^",

ClinicalDocument/setId/@root, "^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

homeCommunityId

)

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;amp;1.2.40.0.34.99.111.1.1
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>
^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</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^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"
<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><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;2.25
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki>
&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

====Bildungsregel für den formatCodeDisplayName====
TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.

Der formatCodeDisplayName ist analog zum formatCode aus den displayNames des entsprechenden Value Sets [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS] zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels ":" (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).

'''Beispiele:'''

*'''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''
*'''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''
*'''ELGA Laborbefund, EIS Full Support v2.06+'''

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = gemäß Liste der in ELGA gültigen FormatCodes 
$codeSystem = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]
<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">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>
<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">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>

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, das das DocumentEntry repräsentiert.

Folgende Mime-Types sind für Dokumente zugelassen: 
CDA R2: '''text/xml''' 
DICOM/KOS: '''application/dicom''' 

<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 wurde ein genau entsprechendes Element 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 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 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"

====Spezifikation====

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

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.

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

<references />

==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 (2015) HL7 Implementation Guide for CDA® R2: Ärztlicher Entlassungsbrief.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.2.6], http://www.elga.gv.at

|-
|[3]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Entlassungsbrief Pflege. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.3.6], http://www.elga.gv.at
|-
| || 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

|-
|[4]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Laborbefund.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.4.6], http://www.elga.gv.at

|-
|[5]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Befund bildgebende Diagnostik.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.5.6], http://www.elga.gv.at
|-
|[6]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: e-Medikation.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.8.6], http://www.elga.gv.at

|-
|[7]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2:
|-
| || Pflegesituationsbericht (2.06) [OID 1.2.40.0.34.7.12.6], http://www.elga.gv.at

|-
|[8]|| ELGA GmbH (2015) Organisationshandbuch.
|-
| || ELGA-Bereiche und Krankenanstalten (2.2.1) [OID 1.2.40.0.34.3.1.2.1.32], http://www.elga.gv.at
|}

==Revisionsliste==
{| class="wikitable"
!Vers.
!Datum
!Änderungsgrund
|-
|0.05
|16.05.2011
|Ergebnisse aus dem technischen Online-Meeting
|-
|2.00 Beta
|12.08.2011
|Erster "Release candidate" des Dokuments für internen Review innerhalb der Arbeitsgruppe.
|-
|2.00 rc1
|30.08.2011
|Redaktionelle Überarbeitung.
|-
|2.00 FWGD
|10.10.2011
|Fertigstellung des "Final Working Group Draft". Veröffentlicht für öffentlichen Review.
|-
|2.01
|11.06.2012
|Fertigstellung der gültigen Version 2.01 "Final". Abgrenzung des Geltungsbereiches (XDSDocumentEntry), Überarbeitung "PracticeSettingCode", Hinweis zu OID eingefügt (1.2.3), Überarbeitung der "parentDocumentRelationship", Typos ausgebessert
|-
|2.01
|21.12.2012
|Layout-Anpassung
|-
|2.01a
|07.03-2013
|Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16: "dieses Dokuments" eingefügt; 363: displayNameOf($code), "Of" gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch "2"-> "Enhanced" etc.) Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt Allgemein: Typos ausgebessert
|-
|2.02
|12.08.2013
|2.3.2 Präzisierung der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessert.
|-
|2.02
|12.08.2013
|2.3.2.3 PDF/A-1a-Vorschrift hinzugefügt
|-
|2.02
|13.08.2013
|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF/A-1a-
|-
|2.02
|17.09.2013
|Typos, Formatierung und Seitenumbrüche ausgebessert
|-
|2.02a
|06.02.2014
|Beispiele in Tabelle 3 korrigiert
|-
|2.03
|26.02.2014
|Definition von ReferenceIdList eingefügt
|-
|2.03
|03.03.2014
|Definition von intendedRecipient eingefügt
|-
|2.03
|03.03.2014
|Änderungen in Tabelle 3: LegalAuthenticator – von [R] auf [R2] geändert IntendedRecipient – von "-" auf [O] geändert, für Verwendung mit XDW vorgesehen ReferenceIdList hinzugefügt Den Namen des Value Sets von "ELGA-PracticeSettingCode" auf "ELGA-PracticeSettingCode-vs" geändert
|-
|2.03.
|03.03.2014
|Anhang gelöscht: 3.1. IHE ITI-TF3, Kapitel 4.1.7 "Document Definition Metadata" 3.2. IHE PCC-TF2, Kapitel 4.1.1 "XDSDocumentEntry Metadata" 3.3. IHE XDS Data Types
|-
|2.03
|03.03.2014
|Korrekturen: ITI Version einheitlich geändert auf "(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)". 1.1.3 Hinweis auf Terminologieserver hinzugefügt Tabelle 3 angepasst: EntryUUID Beschreibung geändert patientId Beschreibung geändert
|-
|2.03
|06.03.2014
|Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId
|-
|2.03
|21.03.2014
|Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt
|-
|2.03
|26.03.2014
|Kapitel 1.4. Korrektur von Dokumentverweisen
|-
|2.03a
|28.03.2014
|Kapitel 2.1 Korrektur von Fußnotennummern
|-
|2.03a
|28.03.2014
|Kapitel 2.2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000
|-
|2.03b
|1.7.2014
|Den Namen des Value Sets von "ELGA-PracticeSetting Code-vs" auf "ELGA_Practicesetting_VS" korrigiert
|-
|2.03b
|11.07.2014
|2.3.2.5 OID in der Spezifikation ergänzt
|-
|2.03b
|11.07.2014
|2.3.6 OID in der Spezifikation ergänzt
|-
|2.03b
|05.08.2014
|2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert
|-
|2.03b
|06.08.2014
|2.1 Überblickstabelle: ParentDocumentId und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]
|-
|2.03b
|06.08.2014
|Referenzen auf CDA Implementierungsleitfäden aktualisiert
|-
| colspan="3" |Version 2.05
|-
|2.05
|03.11.2014
|EntryUUID als "ELGA-Relevant" klassifiziert. Darstellung der Übersichtstabelle geändert
|-
|2.05
|03.11.2014
|2.2.15 TypeCode: ClassificationScheme im Beispiel korrigiert von "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" (falsch) auf "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" (richtig)
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht
|-
|2.05
|19.11.2014
|2.2.2. authorPerson: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden
|-
|2.05
|19.11.2014
|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software
|-
|2.05
|24.11.2014
|2.2.1.1. Spezifikation von authorInstitution: Fall entfernt, in dem die ID des GDA unbekannt ist. Die OID des GDA ist für ELGA-CDA [M]
|-
|2.05
|26.11.2014
|2.4 ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und ELGA-Flag. Auch in 2.1 entsprechend angegeben.
|-
|2.05
|12.03.2014
|Seite 2-3: Absätze "Verbindlichkeit", "Hinweise zur Verwendung" und "Erarbeitung des Implementierungsleitfadens" hinzugefügt.
|-
| colspan="3" |Version 2.06
|-
|2.06
|19.05.2015
|1.2.2. Codesysteme und Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.
|-
|2.06
|13.10.2015
|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch
|-
|2.06
|13.10.2015
|1.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.
|-
|2.06
|07.10.2015
|1.4.3. Kapitel "Metadaten aus 'On-Demand Documents' (ODD)" eingefügt
|-
|2.06
|10.09.2015
|2.1 Tabelle 3: Beschreibung der entryUUID ergänzt
|-
|2.06
|07.10.2015
|2.1 Tabelle 3: Spalte "Optionalität IHE" gelöscht, Spalte zur Definition von On-Demand-Documents eingefügt. objectType hinzugefügt patientid als E1 "ELGA relevant" deklariert (war E2)
|-
|2.06
|30.10.2015
|2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt wird, falls mehrere ID-Elemente angegeben sind.
|-
|2.06
|19.05.2015
|2.2.5. und 2.2.15: Typos verbessert
|-
|2.06
|29.10.2015
|2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt
|-
|2.06
|21.07.2015
|2.2.10. legalAuthenticator: Hinweis, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar ist.
|-
|2.06
|08.10.2015
|2.3.7 objectType hinzugefügt
|-
| colspan="3" |'''Version 2.06.2 (Nebenversion)''' x …betrifft Implementierung (erste Spalte)
|-
|
|01.08.2016
|Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
|-
|
|18.5.2016
|1.2 Erklärung zur Verwendung von XDS Folder und SubmissionSet hinzugefügt.
|-
|
|01.08.2016
|2.1. Tabelle 3: Korrektur der Optionalität von eventCodeList auf [R2], wie im Text bei 2.2.8 angegeben
|-
|x
|14.6.2016
|creationTime, serviceStartTime, serviceStopTime: Präzisierung der Vorgaben für Datum/Zeit, sie MUSS immer entsprechen der Angabe in CDA entweder 8 oder 14-stellig angegeben werden.
|-
|
|03.08.2016
|2.2.5, 2.3.2.2, 2.3.2.5, 2.3.5, 2.3.5.1, 2.3.5.1, 2.1, 1.4, 2.2.7, 2.2.11, 2.2.15, 2.3.6, 1.4.1.2 Korrektur der Großschreibung bei normativen Vorgaben
|-
|
|05.01.2017
|2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.
|-
|
|y
|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;"
|-
|
|y
|Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
|-
|
|y
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
|-
|
|y
|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.
|-
|
|
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
|-
|
|
|Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
|-
|
|
|Kapitel "4.2.7 legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
|-
|
|
|Kapitel "4.2.4 creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
|-
|
|y
|Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
|-
|
|y
|Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
|-
|
|
|Kapitel "4.2.2.1 Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
|-
|
|y
|Kapitel "XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.
|}

ILF:XDS Metadaten (Version 3)

2021-02-10T07:43:47Z

Sjencic: /* 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)}}
{{Underconstruction}}


{{#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.7]
|Short = XDS Metadaten
|Namespace = elga-cdaxds-2.06.2
|Type = Implementierungsleitfaden
|Version = 3.0.0
|Submitted = ELGA GmbH
|Date = Februar 2021
|Copyright = 2011-
|Status = Kommentierung
|Period = n.a.
|OID = 1.2.40.0.34.7.6.7
|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 CDA Dokumenten in der ELGA Infrastruktur notwendig sind und wie sie aus den CDA Dokumenten auszulesen sind. Die Beschreibung richtet sich primär an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden XDS-Metadaten-Guide im Vorfeld und die referenzieren Architekturdokumente der ELGA GmbH zu lesen.
{{EndYellowBox}}
Dieser Implementierungsleitfaden beschreibt die Struktur- und Formatvorgaben für elektronische Dokumente der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012). Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards IHE ITI Cross-enterprise Document Sharing<ref name="IHE ITI">IHE IT Infrastructure Technical Framework Cross-enterprise Document Sharing [https://www.ihe.net/resources/technical_frameworks/#iti IHE ITI]</ref> und ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) <ref name="CDA">HL7 Standards: Clinical Document Architecture [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7 HL7 CDA]</ref>.

Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012), aber auch für medizinische Dokumente im österreichischen Gesundheitswesen. 
TODO: XDSi-Metadaten einfügen https://collab.dicom-austria.at/pages/viewpage.action?pageId=20709391&preview=/20709391/20709392/AnbindungBilddaten_Gesamtarchitektur.pdf

=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 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]</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]</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 [ILF:Allgemeiner_Implementierungsleitfaden_2020]</ref> definiert.
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at]). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
{{BeginILFBox}}
Dieser Leitfaden basiert auf den Vorgaben des '''[https://wiki.hl7.at/index.php?title=ILF:Allgemeiner_Leitfaden_Guide Allgemeinen Implementierungsleitfadens 2020]'''.
{{EndILFBox}}

==Wichtige unterstützende Materialien==
{{BeginYellowBox}}
Auf der Website TODO: [[ILF:Ambulanzbefund_Guide|Ambulanzbefund Guide]] werden unter anderem folgende Materialien zur Verfügung gestellt:
* die PDF-Version dieses Leitfadens
* Beispieldokumente
* Schematron-Prüfregeln
* Design-Beispiele
{{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:

*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 und Hinweise===
''Themenbezogene Hinweise zur besonderen Beachtung:''
{{BeginYellowBox}}
'''Hinweis:''' Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden
{{EndYellowBox}}
''Hinweis auf anderen Implementierungsleitfaden:''
{{BeginILFBox}}
'''Verweis''' Verweis auf den Allgemeinen Leitfaden:…
{{EndILFBox}}
''Themenbezogenes CDA Beispiel-Fragment im XML Format:''
<pre class="ilfbox_code">
<BEISPIEL>
<languageCode code="de-AT" />
</pre>

<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"
|-
! style="text-align:left" colspan="3"| Autoren
|-
! style="text-align:left" width="10%" | Kürzel ||style="text-align:left" width="40%" | Organisation ||style="text-align:left" width="60%" | Person1
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Herausgeber, Projektleiter, CDA-Koordinator
|- style="background:#FFFFFF"
| SSA || ELGA GmbH || Stefan Sabutsch
|- style="background:#FFEBAD"
| style="text-align:left" colspan="3" | Autoren
|- style="background:#FFFFFF"
| JB|| CodeWerk Software Services and Development GmbH|| Jürgen Brandstätter
|- style="background:#FFFFFF"
| SSA|| ELGA GmbH, HL7 Austria||Stefan Sabutsch
|- style="background:#FFFFFF"
| OKU|| ELGA GmbH|| Oliver Kuttin
|- style="background:#FFFFFF"
| KHO|| Wiener Krankenanstaltenverbund|| Konrad Hölzl
|}

1 Namen ohne Titel




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

Eine IHE XDS Registry verwaltet Dokumente und macht diese 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.

Für die Registrierung von Bilddaten über XDS-I wird eine eigene Spezifikation veröffentlicht.

Die Vorgaben für die XDS Registrierungstransaktionen (entsprechend ebXML Registry-Package) ''sind nicht Teil'' dieser Spezifikation.

==Gegenstand dieses Dokuments==
Dieses Dokument definiert die Metadaten beim Einbringen von CDA-Dokumenten<ref name="ALF"></ref> in die österreichische ELGA Infrastruktur über das IHE Profil Cross-Enterprise Document Sharing (XDS)<ref name="IHE ITI"></ref>. Die hier definierten Regeln sind von den folgenden "Technical Frameworks" der IHE abgeleitet und wurden mit den Arbeitsgruppen für die ELGA-CDA-Implementierungsleitfäden abgestimmt:
* Grundlegende Spezifikation der Metadaten in einem XDS System, gültig für alle Dokumentarten (Metadaten der XDSDocumentEntry Objekte)
** ''IT Infrastructure Technical Framwork (ITI), Volume 3, Rev. 17.0 (16.9.2020) Final Text''<ref name="IHE ITI TF-3">IHE ITI TF-3 Cross-Transaction Specifications and Content Specifications, Revision 17.0 (2020), 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> und den "ELGA CDA Implementierungsleitfäden" erstellt.

===XDS Folder===
Die Verwendung von XDS Foldern ist für ELGA nicht vorgesehen.
===XDS Submission Sets===
Eine weitere Profilierung des XDS SubmissionSets gegenüber dem XDS Standard wird in ELGA nicht vorgenommen.

==Hinweise zur Verwendung des Dokuments==
===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}}

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

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. Diese Aktion ist nur in bestimmten Ausnahmefällen zulässig, wie z.B. wenn ein Dokument für einen falschen Patienten angelegt wurde.

====Löschen aus der Registry [ITI-62]====
Das Löschen von Dokumenten in ELGA erfolgt ausschließlich in folgenden Fällen: Löschen durch Bürger, Opt-Out, Ablauf der Aufbewahrungsdauer (nach 10 Jahren müssen Dokumente gelöscht werden). Das Löschen erfolgt i.d.R. "sicher", sodass die Daten nicht wiederhergestellt werden können, sowohl für Verweise als auch Dokumente. Über die Transaktion ITI-62 kann ein Dokument aus der Registry gelöscht werden. Beim Löschen werden sowohl der Registereintrag als auch das Dokument aus dem Repository gelöscht; falls das Löschen der Dokumente aufgrund anderer Verpflichtungen ausgeschlossen ist, sind nur die Verweise zu löschen. Siehe "Organisationshandbuch ELGA-Bereiche und Krankenanstalten" [8].

===Größenbeschränkung ===
ELGA schreibt keine Größenbeschränkung für registrierte Objekte vor, es wird allerdings EMPFOHLEN, diese in Bezug auf Anzahl und Speicherbedarf so klein wie möglich zu halten. Es liegt in der Verantwortung des Erstellers und des ELGA Bereiches, die Größe der über ELGA bereitgestellten CDA-Dateien auf eine sinnvolle und angemessene Größe zu beschränken. Siehe [[ILF:Allgemeiner Implementierungsleitfaden_2020#Gr.C3.B6.C3.9Fenbeschr.C3.A4nkung_von_eingebetteten_Objekten|Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [1]]].

==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-TF3).<ref name="IHE ITI TF-3"></ref>

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:''' Sehen Sie auch die Vorschrift zur Befüllung der Dokument-Metadaten aus Dokumenten des IHE IT Infrastructure Technical Framworks(ITI), Volume 3, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus unstrukturierten Dokumenten===
Im Falle von unstrukturierten Dokumenten (PDF, Bilder, etc.) können Metadaten nicht automatisiert aus dem Dokument 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 korrekt beschreiben, da sonst Suchergebnisse im XDS Dokumentenregister verfälscht werden. Für ELGA sind daher keine unstrukturierten Dokumente vorgesehen.

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

Die IHE hat im Rahmen des "Patient 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="IHE ITI"></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, Rev. 17.0 Final Text.<ref name="IHE ITI TF-3"></ref>

===Metadaten aus Bilddaten (KOS)===
TODO:

===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'''
# 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"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 3: Überblick XDS-I Metadaten und deren Quellen (alphabetisch)''
{| class="wikitable"
| colspan="2" rowspan="2" |'''Metadaten Element'''
|'''Optionalität'''
| rowspan="2" |'''Beschreibung'''
| rowspan="2" |'''Que-'''

'''lle'''
|-
|'''ELGA'''
|-
| colspan="2" |'''author''' (besteht aus den folgenden Komponenten)
|'''R'''
|Die Person, welche das Dokument verfasst hat
|<nowiki>-</nowiki>
|-
| rowspan="4" |
|authorInstitution
|'''R'''
|ID der Organisation, der die Person angehört (OID aus dem GDA-Index)
|A/K
|-
|authorPerson
|'''R2'''
|Daten der Person

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

z.B.: 55113-5 "KOSObjekte"
|A
|-
| colspan="2" |'''confidentialityCode'''
|'''R'''
|Vertraulichkeitscode. Fester Wert "N"
|A
|-
| colspan="2" |'''creationTime'''
|'''R'''
|Zeitpunkt der Dokumentenerstellung
|K
|-
| colspan="2" |'''eventCodeList'''
|'''R'''
|Liste von Codes von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''eventCodeDisplayNameList'''
|'''R2'''
|Liste von Gesundheitsdienstleistungen
|A/K
|-
| colspan="2" |'''intendedRecipient'''
|'''X'''
|Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung
| -
|-
| colspan="2" |'''languageCode'''
|'''R'''
|Sprachcode. Fester Wert "de-AT"
|A
|-
| colspan="2" |'''legalAuthenticator'''
|'''X'''
|Rechtlicher Unterzeichner
| -
|-
| colspan="2" |'''serviceStartTime'''
|'''R'''
|Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Untersuchung
|K
|-
| colspan="2" |'''serviceStopTime'''
|'''X'''
|Ende-Datum der Gesundheitsdienstleistung, z.B.: Ende der Untersuchung
| -
|-
| colspan="2" |'''sourcePatientId'''
|'''R'''
|Patienten ID im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''sourcePatientInfo'''
|'''R'''
|Demographische Daten des Patienten im Informationssystem des GDA, z.B.: im RIS
|K
|-
| colspan="2" |'''Title'''
|'''R'''
|Titel des Dokuments
|A/K
|-
| colspan="2" |'''typeCode'''
|'''R'''
|Objekttyp (Unterklasse)

codierter Wert
|A
|-
| colspan="2" |'''uniqueId'''
|'''R'''
|Global eindeutige ID des Objektes

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

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

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

 



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

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

TODO: urn:ihe:iti:xds:2015:encounterId als referenceIdList Eintrag ergänzen?

{| 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 1: Legende zur Spalte "Quelle" der folgenden Tabelle''

{| class="wikitable" width="100%"
|-
! style="text-align:left" |Code|| style="text-align:left" |Bedeutung
|- style="background:CBD7F1"
|R||Verpflichtend ("Required")
|- style="background:white"
|R2||Verpflichtend wenn bekannt ("Required if Known")
|- style="background:white"
|O||Optional
|- style="background:white"
|X||Wird nicht unterstützt – wird bei der Registrierung nicht eingetragen
|}
''Tabelle 2: Legende zur Spalte "Optionalität" der folgenden Tabelle ''

{| 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="45%" |'''Beschreibung '''|| rowspan="2" style="text-align:left" width="5%" |'''Quelle'''
|- style="background:#CBD7F1"
|'''SD9'''||'''OD10'''
|- 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)||'''R'''||'''R'''||Die Person, welche das Dokument verfasst hat||-
|- style="background:white"
| ||authorInstitution||'''R'''||'''R'''||ID der Organisation, der die Person angehört. (OID aus dem GDA-Index)||C
|- style="background:white"
| ||authorPerson||'''R'''||'''R'''||Daten der Person (Name, ID, etc.)||C
|- style="background:white"
| ||authorRole||'''R2'''||'''X'''||Rolle der Person||C
|- style="background:white"
| ||authorSpeciality||'''R2'''||'''X'''||Fachrichtung der Person||C
|- style="background:white"
| colspan="2" |'''classCode'''||'''R'''||'''R'''||Dokumentenklasse (Oberklasse) z.B.: 18842-5 "Entlassungsbrief"||C
|- style="background:white"
| colspan="2" |'''confidentialityCode'''||'''R'''||'''X'''||Vertraulichkeitscode des Dokuments||C
|- style="background:white"
| colspan="2" |'''creationTime'''||'''R'''||'''R'''||Zeitpunkt der Dokumentenerstellung||C
|- style="background:white"
| colspan="2" |'''eventCodeList'''||'''R2'''||'''R2'''||Liste von Gesundheitsdienstleistungen||C
|-
| colspan="2" |'''formatCode'''
|'''R'''
|'''R'''
|Format des Dokumenteninhalts
|C
|- style="background:white"
| colspan="2" |'''intendedRecipient'''||'''O'''||'''X'''||Für Verwendung mit XDW vorgesehen. Derzeit nicht in Verwendung.||C
|- style="background:white"
| colspan="2" |'''languageCode'''||'''R'''||'''R'''||Sprachcode des Dokuments z.B.: "de-AT"||C
|- style="background:white"
| colspan="2" |'''legalAuthenticator'''||'''R2'''||'''X'''||Rechtlicher Unterzeichner des Dokuments||C
|-
| colspan="2" |'''practiceSettingCode'''
|'''R'''
|'''R'''
|Fachliche Zuordnung des Dokuments
|C
|- style="background:white"
| colspan="2" |'''serviceStartTime'''||'''R2'''||'''O'''||Beginn-Datum der Gesundheitsdienstleistung, z.B.: Datum der Aufnahme||C
|- style="background:white"
| colspan="2" |'''serviceStopTime'''||'''R2'''||'''O'''||Ende-Datum der Gesundheitsdienstleistung, z.B.: Datum der Entlassung||C
|- style="background:white"
| colspan="2" |'''sourcePatientId'''||'''R'''||'''R'''||Patienten ID im Informationssystem des GDA, z.B.: im KIS des KH||C
|- style="background:white"
| colspan="2" |'''sourcePatientInfo'''||'''X'''||'''X'''||Demographische Daten des Patienten im Informationssystem des GDA (z.B.: im KIS einer Krankenanstalt)||C
|- style="background:white"
| colspan="2" |'''Title'''||'''R'''||'''R'''||Titel des Dokuments||C
|- style="background:white"
| colspan="2" |'''typeCode'''11||'''R'''||'''R'''||Dokumententyp (Unterklasse) codierter Wert, z.B.: 11490-0, "Entlassungsbrief aus stationärer Behandlung (Arzt)"||C
|- style="background:white"
| colspan="2" |'''uniqueId'''||'''R'''||'''R'''||Global eindeutige ID des Dokuments||C
|- style="background:white"
| colspan="2" |'''referenceIdList'''||'''R'''||'''O'''||Liste von Identifikatoren. Die Semantik der jeweiligen Identifier ist in dem Data Typ CXi codiert||C
|- style="background:white"
| colspan="2" |'''healthcareFacilityTypeCode'''||'''R'''||'''R'''||Klassifizierung des GDA
|C

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Explizit zu setzende Metadaten'''''
|- style="background:white"
| colspan="2" |'''availabilityStatus'''||'''R'''||'''R'''||Gültigkeit des Dokuments||E1
|- style="background:white"
| colspan="2" |'''mimeType'''||'''R'''||'''R'''||Mime Type des Dokuments z.B.: "text/xml" für CDA||E1
|- style="background:white"
| colspan="2" |'''parentDocumentId'''12||'''O'''||'''O'''||Verweis auf ein referenziertes Dokument||E1
|- style="background:white"
| colspan="2" |'''parentDocumentRelationship'''13||'''O'''||'''O'''||Typ der Relation zu dem referenzierten Dokument. z.B.: RPLC, XFRM||E1
|- style="background:white"
| colspan="2" |'''entryUUID'''||'''R'''||'''R'''||UUID des Metadaten-Records des Dokuments (XDS DocumentEntry)||E1
|- style="background:white"
| colspan="2" |'''objectType'''||'''R'''||'''R'''||Typ des DocumentEntries (SD oder ODD)||E1
|- style="background:white"
| colspan="2" |'''comments'''||'''O'''||'''O'''||Kommentar zum Dokument||E2
|- style="background:white"
| colspan="2" |'''patientId'''||'''R'''||'''R'''||Patienten-ID in der XDS Affinity Domain||E1

|- style="background:white"
| colspan="6" style="text-align:center" |'''''Von Registry oder Repository automatisch gesetzte Metadaten'''''
|- style="background:white"
| colspan="2" |'''hash'''||'''R'''||'''X'''||Hash Wert des Dokuments. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''homeCommunityId'''||'''R'''||'''R'''||Gemäß ITI XCA: Eine eindeutige Identifikation (OID) für eine "Community", die in weiterer Folge dazu verwendet wird, den entsprechenden WebService Endpoint (URI des/der XCA Responding Gateway(s)) zu erhalten.||A
|- style="background:white"
| colspan="2" |'''repositoryUniqueId '''||'''R'''||'''R'''||Die eindeutige Identifikation (OID) des Document Repositories, in welchem das Dokument abgelegt ist. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''size'''||'''R'''||'''X'''||Größe des Dokuments in Bytes. Wird vom Repository befüllt.||A
|- style="background:white"
| colspan="2" |'''URI'''14||'''-'''||'''-'''||'''Wird in XDS nicht verwendet'''||A
|- style="background:white"
| colspan="6" style="text-align:center" |'''''Vom ELGA-Berechtigungssteuerungssystem automatisch gesetzte Metadaten (non-IHE)'''''
|- style="background:white"
| colspan="2" |'''elgaFlag'''||'''R'''||'''R'''||Kennzeichnet ein Dokument als "ELGA-Dokument"||B
|- style="background:white"
| colspan="2" |'''elgaHash'''||'''R'''||'''R'''||Prüfkennzeichen für Integrität und Authentizität des XDS-Metadatensatzes||B
|}
''Tabelle 3: Überblick XDS Metadaten und deren Quellen (alphabetisch)''

9 SD: "Stable Document": Stabiles Dokument, das als Datei gespeichert und registriert zur Verfügung steht. 
10 OD: "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 SubmissionSets übereinstimmen. 
12 MUSS vorhanden sein, wenn eine "parentDocumentRelationship" existiert. 
13 MUSS gemeinsam mit einer "parentDocumentId" angegeben sein. 
14 Dieses Element wird von XDS nicht verwendet und ist nur der Vollständigkeit halber angegeben.


=XDS-I Metadaten für DICOM KOS Objekte=
==XDS Metadaten 1: aus dem DICOM KOS Objekt abgeleitet==

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.

{| class="wikitable"
|'''XDS-I Metadaten Element'''
|'''Opt.'''
|'''Attribut in'''

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

'''im KOS'''
|'''Beschreibung'''
|-
| colspan="5" |author
|-
|author.authorInstitution
|R
|
|(0008,0080)
|Identifiziert die Institution, in deren Gültigkeitsbereich die Studie erzeugt wurde.

ELGA schreibt vor, hier sowohl den Namen als auch die OID der Institution im 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.
|-
| colspan="5" |Die die Studie durchführende Person ist als author anzugeben:
|-
|author.authorPerson
|R2
|(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.
|-
|
|
|'''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.
|-
| colspan="5" |Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät als author angegeben werden:
|-
|author.authorPerson
|R2
|(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.
|-
|creationTime
|R
|(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.
|-
|eventCodeList
|R
|
|
|Enthält den APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|eventCodeListDisplayNameList
|R2
|
|
|Enthält den Display Name des APPC

siehe [https://collab.dicom-austria.at/download/attachments/17268741/DICOM Austria - Ermittlung und Speicherung des APPC in DICOM Daten %282020%29.pdf?version=1&modificationDate=1580371536150&api=v2 Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten]
|-
|serviceStartTime
|R
|(0008,0020) + (0008,0030)
|(0008,0020) + (0008,0030)
|Study Date und Study Time
|-
|sourcePatientId
|R
|(0010,0020)
|(0010,0020)
|Die Patient ID im eigenen Informationssystem
|-
|sourcePatientInfo
|R
|(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.
|-
|title
|R
|(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".
 
|-
|uniqueId
|R
|
|(0008,0018)
|Die SOP Instance UID des KOS
|-
| colspan="4" |referenceIdList
|Die referenceIdList enthält mindestens die beiden folgenden Attribute und darüber hinaus noch weitere Elemente
|-
|value mit CXi.5 =

"<nowiki>urn:elga:iti:xds:2014:OwnDocument_setId</nowiki>"
|R
|(0020,000D) oder ein vergleich-bares Attribut
|(0020,000D) oder ein vergleich-bares 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 Kapitel 8.2.2.
|-
|value mit CXi.5 =

"<nowiki>urn:ihe:iti:xds:2013:accession</nowiki>"
|O
|(0008,0050) oder ein vergleich-bares 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.
|-
|comments
|O
|(0008,1030)
|(0008,1030)
|Optionale Angaben zur Studie; diese können z.B. aus der Study Description abgeleitet werden.
|}

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 Radiology Technical Framework, vol2, rev. 19, "4.68.4.1.2.3.2 DocumentEntry Metadata" sowie IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

===author===
Die Personen und/oder Maschinen, die das Dokument erstellt haben. 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 kann

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

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

$id ... OID der Organisation aus dem GDA-Index

concat( 
$name,"^^^^^^^^^", 
$id 
) 
<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-TF3].
====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[[#%20ftn1|[1]]], wenn vorhanden
#*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) ----[[#%20ftnref1|[1]]] Im Datentyp SQ befindet sich Identifikator im Attribut (0008,0100) Code in (0040,1101) Person Identification Code Sequence
#Falls die durchführende Person nicht ermittelt werden kann, soll das Gerät aus den DICOM Attribut Modality der Studie abgleitet werden
#*Modalität[[#%20ftn1|[2]]]: Attribut "Modality", (0008,0060)
#*Hersteller: Attribut "Manufacturer", (0008,0070)
#*Modellname: Attribut " Manufacturer's Model Name", (0008,1090) ----[[#%20ftnref1|[2]]] Erlaubte Werte siehe <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.3.html#sect_C.7.3.1.1.1</nowiki>

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

$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>2323^MusterDoc^&amp;1.2.40.0.34.99.4613.3.3&amp;ISO
</Value>
</ValueList>
</Slot>
</Classification></pre>
Dies entspricht einer Transformation auf den HL7 v2 XCN Datentyp gemäß [IHE ITI-TF3].
=====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-TF3].

====authorRole====
Das ''authorRole'' Element beschreibt die Rolle, die der inhaltliche Autor (bzw. das erstellende Gerät) zum Zeitpunkt der KOS-Objektation 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|4.2.15]]
|}

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "[https://termpub.gesundheit.gv.at/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=HL7-at_XDS-Dokumentenklassen hl7-austria-Dokumentenklassen]" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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 "[https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_Confidentiality ELGA_Confidentiality]".

====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 registrieren 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)
#Sollten 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''[[#%20ftn1|[3]]] berücksichtigt werden, falls angegeben:

*Timezone Offset From UTC (0008,0201)
*Es DÜRFEN NUR folgende Datumsformen verwendet werden:
*#YYYYMMDD
*#YYYYMMDDhhmmss

[[#%20ftnref1|[3]]] <nowiki>http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.12.html#sect_C.12.1.1.8</nowiki>
====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 +(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. 20160518 in 20160518000000).

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-TF3].{{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".[[# ftn4|[4]]])
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.
----[[# ftnref4|[4]]] DICOM Austria: "Leitfaden zur Ermittlung und Speicherung des APPC in DICOM Daten", 22.01.2020, <nowiki>https://collab.dicom-austria.at/display/OBD/Leitfaden+zur+Ermittlung+und+Speicherung+des+APPC+in+DICOM+Daten</nowiki> (zuletzt besucht am 12.3.2020)

====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 des DICOM Objektes aus den Attributen des KOS Objektes:
#*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. 20160518 in 20160518000000).

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

===sourcePatientInfo===
Das ''sourcePatientInfo'' Element beschreibt die demographischen Daten des Patienten. Die Patienten ID wird wie in Kapitel 3.2.12 sourcePatientId gemappt und verwendet.

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

====Spezifikation (empfohlene Variante)====
'''sourcePatientInfo''' wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

$id = concat(

$patientID, "^^^&amp;",

$oid, "&amp;ISO"

)

Bsp: 4711^^^&1.2.3.4.5.6.7.8.9&ISO

$name = ""

$birthtime = ""

$gender = ""

$addr = "" <pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be">
<Slot name="sourcePatientInfo">
<ValueList>
<Value>PID-3|$id</Value>
<Value>PID-5|$name</Value>
<Value>PID-7|$birthtime</Value>
<Value>PID-8|$gender</Value>
<Value>PID-11|$addr</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

===title===
Das ''title'' Element beschreibt den lesbaren Titel des registrierten Objektes.

Im Fall eines KOS-Objektes gilt folgende Verknüpfung mit den Metadaten:

#Wenn die Informationen aus der Studie verfügbar sind: Study Description
#*(0008,0060) Modality (Modality Codes aus der DICOM Studie) +
#*(0008,1030) Study Description, Datentyp LO
#Wenn mehrere Modailty 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Objektklasse und den Objekttyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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 entweder vom Document Source Actor erzeugt oder im Fall eines evtl. verwendeten Adapters vom Informationssystem des GDA übernommen.

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 zwei unterschiedliche Einträge in referenceIdList notwendig:

#Versionsklammer über die zusammengehörenden Versionen (ownDocument_setId)
#Verlinkung zwischen e-Befunden (CDA) und DICOM Studien über KOS-Objekte (Accession Number)

'''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="IHE ITI TF-3"></ref>

{| 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 z.B. 1.2.40.0.34.99.999

concat

(

$id, "^^^^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

"&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>^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^^^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"

====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 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 [https://tools.ietf.org/html/rfc2045 <nowiki>RFC 2045[6]</nowiki>] und RFC 2049.<ref name="RFC2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>

Im Fall von KOS-Objekten ist der Mime Type immer fix "application/dicom".

[6] <nowiki>http://tools.ietf.org/html/rfc2045</nowiki>

[7] <nowiki>http://tools.ietf.org/html/rfc2049</nowiki>

====Spezifikation====

'''mimeType''' wird im Attribut @mimeType des ebRIM ExtrinsicObject abgebildet, das 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 "[[urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be]]" für "Stable Document" vorgegeben:
<pre class="ilfbox_code">
<ExtrinsicObject mimeType="text/xml"
objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1"
status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved"
id="urn:uuid:1e2ede82-8570-4be2-bd46-de986a4333be"/>
</pre>

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

====Spezifikation====

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

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.

===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 weiter eingeschränkte Metadaten sind nicht angeführt. Für diese gelten die generellen Vorgaben wie in IHE IT Infrastructure Technical Framework, vol3, rev. 17, "Table 4.2.3.2-1 DocumentEntry Metadata Attribute Definition" angeführt.

==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 SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description 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"

#GDAs, in dessen Gültigkeitsbereich Dokumente erstellt werden können sind seitens der Basiskomponente "GDA Index" mit einer eindeutigen OID ausgestattet.
#Falls mehrere ID-Elemente angegeben sind, ist id[1] (die erste ID) zu verwenden.
{{BeginYellowBox}}
Das AuthorInstitution-Element ist von besonderer Wichtigkeit, da sie vom ELGA Berechtigungssystem bei Registrierung geprüft wird.
{{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 
) 
<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-TF3].

====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). Mindestens eine Person

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

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

====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 '''''[R2]'''''.
#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 '''''[R2]'''''.
#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|4.2.15]]
|}

 

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

In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).

===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===
Das creationTime Element beschreibt den Zeitpunkt der Dokumentenerstellung. Das XDS Profil schreibt vor, dass sämtliche Zeiten in UTC vorliegen MÜSSEN.

Im Fall eines CDA R2 Dokuments gilt folgende Verknüpfung mit den CDA Header Elementen:

#Im CDA wird der Zeitpunkt der Dokumentenerstellung wie folgt abgelegt:
##ClinicalDocument/effectiveTime
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe des Dokumentendatums ein verpflichtendes Element.
#Im CDA wird jeweils das medizinisch zutreffendste Datum angeführt. Die Bedeutung des Datums ist für jede einzelne Dokumentenklasse im zugehörigen speziellen Leitfaden separat definiert werden.
#Ein einfaches Zeitelement (HL7 TS) in CDA beinhaltet unter anderem die folgenden Attribute:
#@value … enthält das Datum in folgenden möglichen Formen
##YYYYMMDD
##YYYYMMDDhhmmss[+/-]HHMM (Zeitzone)
###Bsp: 20081224082015+0100
###Für: 24.12.2008, 08:20:14, Zeitzone GMT+1
{{BeginYellowBox}}
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-TF3].
{{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 Service-Events wie folgt abgelegt:
##ClinicalDocument/documentationOf/serviceEvent
#Mehrere dieser Service-Events können durch beliebig viele "documentationOf" Elemente ausgedrückt werden.
#Laut Vorgabe der ELGA Gesundheitsdaten ist die Angabe mindestens eines Service-Events verpflichtend, wenn bekannt [R2].
#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 Service Event 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 PCC Profil definiert in Kapitel "Medical Document Bindings" Spezialbehandlungen für gewissen 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}}

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

===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 '''''[R2]'''''.

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

TODO: '''Welches serviceEvent''' für das Mapping verwendet wird, muss im Speziellen Leitfaden angegeben sein.

====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] … Lokale ID des Patienten vom einbringenden System
##d[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-TF3].

===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|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 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>
{{BeginYellowBox}}
In Registries, die nicht ausschließlich für ELGA Verwendung finden (z.B. auch für andere eHealth-Anwendungen) sollten ebenfalls einheitliche Codes für die Dokumentenklasse und den Dokumententyp angewendet werden. Eine entsprechende Liste "hl7-austria-Dokumentenklassen" OID {1.2.40.0.34.10.86} wird von der HL7 Austria standardisiert (http://www.hl7.at).
{{EndYellowBox}}

====submissionSet.contentTypeCode====
Der contentTypeCode des SubmissionSets 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.
uniqueId wird als ebRIM

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===
Um eine eindeutige Identifikation aller Dokumente eines Dokumentenstammes (vorhergehende und auch zukünftige Versionen) innerhalb der XDS-Metadaten zu ermöglichen, ist die Verwendung eines gemeinsamen Identifikators notwendig.

Das referenceIdList Element stellt eine Liste von internen oder externen Identifiern dar. Dieses Element ist im IHE_ITI_TF_Vol3 (27 September 2013) Dokument neu hinzugekommen.
{{BeginYellowBox}}
Im Rahmen von ELGA ist die ClinicalDocument/SetId als ein Eintrag in der referenceIdList in den XDS Metadaten einzubringen. Weitere andere Einträge in der referenceIdList sind möglich, aber derzeit nicht Bestandteil der ELGA Vorgaben.
{{EndYellowBox}}

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

====Spezifikation====
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="IHE ITI TF-3"></ref>

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

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

referenceIdList wird wird als ebRIM Slot gemäß folgender Vorschrift zusammengesetzt:

concat

(

ClinicalDocument/setId/@extension, "^^^",

ClinicalDocument/setId/@root, "^",

"urn:elga:iti:xds:2014:ownDocument_setId", "^",

homeCommunityId

)

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;amp;1.2.40.0.34.99.111.1.1
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId</nowiki>
^&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</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^^^</nowiki>&amp;2.25&amp;ISO^urn:elga:iti:xds:2014:ownDocument_setId^&amp;1.2.40.0.34.99.999&amp;ISO"
<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><nowiki>urn:uuid:19FEE6C3-6B35-4C5B-B1CC-B2B5B4001AB2^^^</nowiki></nowiki><nowiki>&</nowiki>amp;amp;2.25
<nowiki>&</nowiki>amp;amp;ISO^<nowiki>urn:elga:iti:xds:2014:ownDocument_setId^</nowiki>
&amp;amp;1.2.40.0.34.99.999&amp;amp;ISO</Value>
</ValueList>
</Slot>
</ExtrinsicObject>
</pre>

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

====Bildungsregel für den formatCodeDisplayName====
TODO: Prüfen, ob diese Bildungsregel noch gültig ist. Weiters ist FormatCodeDisplayName ist nicht Teil des CDA, allerdings 1..1 M nach IHE XDS.

Der formatCodeDisplayName ist analog zum formatCode aus den displayNames des entsprechenden Value Sets [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS] zu bilden, auch bei der Bildung der Zusätze (Das Format MUSS mittels ":" (Doppelpunkt) am Ende angefügt werden, das Plus-Zeichen am Ende des FormatcodeDisplayNames).

'''Beispiele:'''

*'''ELGA Entlassungsbrief Ärztlich, EIS Basic v2.06:PDF'''
*'''ELGA Entlassungsbrief Pflege, EIS Enhanced v2.06+'''
*'''ELGA Laborbefund, EIS Full Support v2.06+'''

====Spezifikation====
'''formatCode (und formatCodeDisplayName) '''wird als ebRIM Classification gemäß folgender Vorschrift zusammengesetzt: 
$code = ClinicalDocument/hl7at:formatCode/@code 
$displayName = gemäß Liste der in ELGA gültigen FormatCodes 
$codeSystem = OID der Liste der in ELGA gültigen FormatCodes, fixiert mit OID 1.2.40.0.34.5.37 von [https://termpub.gesundheit.gv.at:443/TermBrowser/gui/main/main.zul?loadType=ValueSet&loadName=ELGA_FormatCode_VS ELGA_FormatCode_VS]
<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">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [http://tools.ietf.org/html/rfc2045 IETF RFC 2045]</ref>
<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">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples [http://tools.ietf.org/html/rfc2049 IETF RFC 2049]</ref>

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, das das DocumentEntry repräsentiert.

Folgende Mime-Types sind für Dokumente zugelassen: 
CDA R2: '''text/xml''' 
DICOM/KOS: '''application/dicom''' 

<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 wurde ein genau entsprechendes Element 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 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 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"

====Spezifikation====

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

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.

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

<references />

==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 (2015) HL7 Implementation Guide for CDA® R2: Ärztlicher Entlassungsbrief.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.2.6], http://www.elga.gv.at

|-
|[3]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Entlassungsbrief Pflege. ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.3.6], http://www.elga.gv.at
|-
| || 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

|-
|[4]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Laborbefund.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.4.6], http://www.elga.gv.at

|-
|[5]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: Befund bildgebende Diagnostik.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.5.6], http://www.elga.gv.at
|-
|[6]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2: e-Medikation.
|-
| || ELGA CDA Implementierungsleitfäden (2.06) [OID 1.2.40.0.34.7.8.6], http://www.elga.gv.at

|-
|[7]|| ELGA GmbH (2015) HL7 Implementation Guide for CDA® R2:
|-
| || Pflegesituationsbericht (2.06) [OID 1.2.40.0.34.7.12.6], http://www.elga.gv.at

|-
|[8]|| ELGA GmbH (2015) Organisationshandbuch.
|-
| || ELGA-Bereiche und Krankenanstalten (2.2.1) [OID 1.2.40.0.34.3.1.2.1.32], http://www.elga.gv.at
|}

==Revisionsliste==
{| class="wikitable"
!Vers.
!Datum
!Änderungsgrund
|-
|0.05
|16.05.2011
|Ergebnisse aus dem technischen Online-Meeting
|-
|2.00 Beta
|12.08.2011
|Erster "Release candidate" des Dokuments für internen Review innerhalb der Arbeitsgruppe.
|-
|2.00 rc1
|30.08.2011
|Redaktionelle Überarbeitung.
|-
|2.00 FWGD
|10.10.2011
|Fertigstellung des "Final Working Group Draft". Veröffentlicht für öffentlichen Review.
|-
|2.01
|11.06.2012
|Fertigstellung der gültigen Version 2.01 "Final". Abgrenzung des Geltungsbereiches (XDSDocumentEntry), Überarbeitung "PracticeSettingCode", Hinweis zu OID eingefügt (1.2.3), Überarbeitung der "parentDocumentRelationship", Typos ausgebessert
|-
|2.01
|21.12.2012
|Layout-Anpassung
|-
|2.01a
|07.03-2013
|Zeile: 5: "und" eingefügt; 14: "diesem" eingefügt; 16: "dieses Dokuments" eingefügt; 363: displayNameOf($code), "Of" gelöscht; 364: "aus" eingefügt; 814 und 818: ELGA-Interoperabilitätslevel -> Interoperabilitätsstufe (auch "2"-> "Enhanced" etc.) Tabelle ab 357: classcode/typeCode "Spalte" eingefügt und erste Zeile eingefügt Allgemein: Typos ausgebessert
|-
|2.02
|12.08.2013
|2.3.2 Präzisierung der gültigen Value Sets mit OID, EIS Structured hinzugefügt, Formulierung in Text und Überschriften verbessert.
|-
|2.02
|12.08.2013
|2.3.2.3 PDF/A-1a-Vorschrift hinzugefügt
|-
|2.02
|13.08.2013
|Eingefügt: Kapitel 1.3 – Allgemeines zu Dokumenten in ELGA (Dokumentenlebenszyklus, XDS-Transaktionen, Größenbeschränkung, Vorschrift für PDF/A-1a-
|-
|2.02
|17.09.2013
|Typos, Formatierung und Seitenumbrüche ausgebessert
|-
|2.02a
|06.02.2014
|Beispiele in Tabelle 3 korrigiert
|-
|2.03
|26.02.2014
|Definition von ReferenceIdList eingefügt
|-
|2.03
|03.03.2014
|Definition von intendedRecipient eingefügt
|-
|2.03
|03.03.2014
|Änderungen in Tabelle 3: LegalAuthenticator – von [R] auf [R2] geändert IntendedRecipient – von "-" auf [O] geändert, für Verwendung mit XDW vorgesehen ReferenceIdList hinzugefügt Den Namen des Value Sets von "ELGA-PracticeSettingCode" auf "ELGA-PracticeSettingCode-vs" geändert
|-
|2.03.
|03.03.2014
|Anhang gelöscht: 3.1. IHE ITI-TF3, Kapitel 4.1.7 "Document Definition Metadata" 3.2. IHE PCC-TF2, Kapitel 4.1.1 "XDSDocumentEntry Metadata" 3.3. IHE XDS Data Types
|-
|2.03
|03.03.2014
|Korrekturen: ITI Version einheitlich geändert auf "(ITI) Technical Frameworks Volume 3, Revision 10.0 – Final Text (27. 09.2013)". 1.1.3 Hinweis auf Terminologieserver hinzugefügt Tabelle 3 angepasst: EntryUUID Beschreibung geändert patientId Beschreibung geändert
|-
|2.03
|06.03.2014
|Eigene URN für die ReferenceId eingefügt: urn:elga:iti:xds:2014:ownDocument_setId
|-
|2.03
|21.03.2014
|Kapitel 1.3.1.2 Korrektur: Versionierung wird mit ITI-41 durchgeführt
|-
|2.03
|26.03.2014
|Kapitel 1.4. Korrektur von Dokumentverweisen
|-
|2.03a
|28.03.2014
|Kapitel 2.1 Korrektur von Fußnotennummern
|-
|2.03a
|28.03.2014
|Kapitel 2.2.7 und 2.2.11: Korrektur des Textes zur Konvertierung von Datumsformaten in UTC: Lokalzeit 20100511193000+0200 wird zu UTC 20100511173000
|-
|2.03b
|1.7.2014
|Den Namen des Value Sets von "ELGA-PracticeSetting Code-vs" auf "ELGA_Practicesetting_VS" korrigiert
|-
|2.03b
|11.07.2014
|2.3.2.5 OID in der Spezifikation ergänzt
|-
|2.03b
|11.07.2014
|2.3.6 OID in der Spezifikation ergänzt
|-
|2.03b
|05.08.2014
|2.3.2.2 FormatCode: Angabe des Codesystems ELGA_FormatCode präzisiert
|-
|2.03b
|06.08.2014
|2.1 Überblickstabelle: ParentDocumentId und ParentDocumentRelationship sind nur vorhanden, wenn eine Vorversion vorliegt, daher Optionalität [R2]
|-
|2.03b
|06.08.2014
|Referenzen auf CDA Implementierungsleitfäden aktualisiert
|-
| colspan="3" |Version 2.05
|-
|2.05
|03.11.2014
|EntryUUID als "ELGA-Relevant" klassifiziert. Darstellung der Übersichtstabelle geändert
|-
|2.05
|03.11.2014
|2.2.15 TypeCode: ClassificationScheme im Beispiel korrigiert von "urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" (falsch) auf "urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" (richtig)
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: XFRM gelöscht
|-
|2.05
|19.11.2014
|2.2.2. authorPerson: Beschreibung präzisiert und den Fall beschrieben, wenn die ID des Autors mit NullFlavor angegeben ist.
|-
|2.05
|19.11.2014
|2.3.5. parentDocumentId, parentDocumentRelationship: präzisiert, dass Dokumentenbeziehungen in XDS über Associations geregelt werden
|-
|2.05
|19.11.2014
|2.2.2. authorPerson erweitert für das Mapping von Dokumenterstellenden Geräten oder Software
|-
|2.05
|24.11.2014
|2.2.1.1. Spezifikation von authorInstitution: Fall entfernt, in dem die ID des GDA unbekannt ist. Die OID des GDA ist für ELGA-CDA [M]
|-
|2.05
|26.11.2014
|2.4 ELGA-spezifische Erweiterungen hinzugeügt: ELGA-Hash und ELGA-Flag. Auch in 2.1 entsprechend angegeben.
|-
|2.05
|12.03.2014
|Seite 2-3: Absätze "Verbindlichkeit", "Hinweise zur Verwendung" und "Erarbeitung des Implementierungsleitfadens" hinzugefügt.
|-
| colspan="3" |Version 2.06
|-
|2.06
|19.05.2015
|1.2.2. Codesysteme und Value Sets: Hinweis zum richtigen Umgang mit Codes und DisplayNames hinzugefügt.
|-
|2.06
|13.10.2015
|1.3.1 Löschen von Dokumenten neu geschrieben mit Verweis auf das Organisationshandbuch
|-
|2.06
|13.10.2015
|1.3.2 Größenbeschränkung: Verweis auf den Allgemeinen Leitfaden aufgenommen.
|-
|2.06
|07.10.2015
|1.4.3. Kapitel "Metadaten aus 'On-Demand Documents' (ODD)" eingefügt
|-
|2.06
|10.09.2015
|2.1 Tabelle 3: Beschreibung der entryUUID ergänzt
|-
|2.06
|07.10.2015
|2.1 Tabelle 3: Spalte "Optionalität IHE" gelöscht, Spalte zur Definition von On-Demand-Documents eingefügt. objectType hinzugefügt patientid als E1 "ELGA relevant" deklariert (war E2)
|-
|2.06
|30.10.2015
|2.2.1 AuthorInstiitution: Präzisiert, dass id[1] gemappt wird, falls mehrere ID-Elemente angegeben sind.
|-
|2.06
|19.05.2015
|2.2.5. und 2.2.15: Typos verbessert
|-
|2.06
|29.10.2015
|2.3.2.5. Fehlende Bildungsregel für den formatCodeDisplayName hinzugefügt
|-
|2.06
|21.07.2015
|2.2.10. legalAuthenticator: Hinweis, dass bei automatisch freigegebenen Dokumenten (ODD) kein legalAuthenticator verfügbar ist.
|-
|2.06
|08.10.2015
|2.3.7 objectType hinzugefügt
|-
| colspan="3" |'''Version 2.06.2 (Nebenversion)''' x …betrifft Implementierung (erste Spalte)
|-
|
|01.08.2016
|Kapitel Verbindlichkeit: Definition der Angabe verbindlicher Vorgaben.
|-
|
|18.5.2016
|1.2 Erklärung zur Verwendung von XDS Folder und SubmissionSet hinzugefügt.
|-
|
|01.08.2016
|2.1. Tabelle 3: Korrektur der Optionalität von eventCodeList auf [R2], wie im Text bei 2.2.8 angegeben
|-
|x
|14.6.2016
|creationTime, serviceStartTime, serviceStopTime: Präzisierung der Vorgaben für Datum/Zeit, sie MUSS immer entsprechen der Angabe in CDA entweder 8 oder 14-stellig angegeben werden.
|-
|
|03.08.2016
|2.2.5, 2.3.2.2, 2.3.2.5, 2.3.5, 2.3.5.1, 2.3.5.1, 2.1, 1.4, 2.2.7, 2.2.11, 2.2.15, 2.3.6, 1.4.1.2 Korrektur der Großschreibung bei normativen Vorgaben
|-
|
|05.01.2017
|2.2.15.2. submissionSet.contentTypeCode – Kapitel hinzugefügt. Der contentTypeCode [R] des SubmissionSets soll wie der typeCode befüllt werden.
|-
|
|y
|Korrektur der Strukturierung von "&" innerhalb der XML Beispiel-Snippets zu "&amp;"
|-
|
|y
|Kapitel 4.2.14 "referenceIdList": Anpassung des Beispiels bei Verwendung einer UUID in ClinicalDocument/setId
|-
|
|y
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalitäten von "parentDocumentId" und "parentDocumentRelationship" zu O angepasst.
|-
|
|y
|Kapitel 1.11.1 "Spezifikation": Verbot von CR und LF hinzugefügt.
|-
|
|
|Kapitel 4.1 "Überblickstabelle der XDS Metadaten": Optionalität von "sourcePatientInfo" zu X angepasst.
|-
|
|
|Kapitel "4.2.10 sourcePatientInfo" angepasst. Name, Geschlecht, Geburtsdatum und Adressdaten sind für die Nutzung der XDS Metadaten nicht erforderlich
|-
|
|
|Kapitel "4.2.7 legalAuthenticator" angepasst. Es wird immer das erste Vorkommen von ClinicalDocument/legalAuthenticator[1] in die XDS-Metadaten übernommen.
|-
|
|
|Kapitel "4.2.4 creationTime": Bedeutung von ClinicalDocument.effectiveTime präzisiert
|-
|
|y
|Kapitel "4.3.3 healthcareFacilityTypeCode (und healthcareFacilityTypeCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "healthCareFacility" hinzugefügt.
|-
|
|y
|Kapitel "4.3.2 formatCode (und formatCodeDisplayName)": Ableitungsvorschrift aus dem CDA-Header Element "hl7at:formatCode" hinzugefügt.
|-
|
|
|Kapitel "4.2.2.1 Spezifikation": Ableitungsvorschrift aus dem CDA-Header Element "ClinicalDocument/code/translation" für XDS DocumentEntry.classCode hinzugefügt.
|-
|
|y
|Kapitel "XDS-I Metadaten für DICOM KOS Objekte" hinzugefügt.
|}