Back To Index << Back To Templates

# Template Documentation Of Service Event - Outpatient Report

Aus Publikation für Projekt ELGA Ambulanzbefund | Release 4.25.0+20260427-1.3.1 vom 2026‑04‑27 08:05:23 | | | HTML erstellt am 2026‑04‑27 08:20:12

Id | 1.2.40.0.34.6.0.11.1.33 | Gültigkeit ab | 2021‑02‑19 08:45:51 Andere Versionen mit dieser Id: elgagab_header_DocumentationOfServiceEventOutpatientReport vom 2019‑11‑22 10:21:08
Status | Aktiv | Versions-Label | 1.0.0+20201105
Name | elgagab_header_DocumentationOfServiceEventOutpatientReport | Bezeichnung | Documentation Of Service Event - Outpatient Report
Beschreibung
Dokumentation der Gesundheitsdienstleistung. Mit der Assoziation documentationOf/serviceEvent wird die eigentliche Gesundheitsdienstleistung repräsentiert, die in dem Dokument dokumentiert wird (z.B. eine Koloskopie, Appendektomie, etc.). Dies ist in engem Zusammenhang mit dem Dokumententyp zu sehen, der in ClinicalDocument/code wiedergegeben ist. Mit der documentationOf Beziehung kann die dokumentierte Gesundheitsdienstleistung näher spezifiziert werden. Dies darf natürlich nicht im Widerspruch zum Dokumententyp stehen. WICHTIG: Im Zuge der Einstellung eines Ambulanzbefundes wird durch die XDS-Metadaten dargestellt, welche Sektionen in gegenständlichen Ambulanzbefund enthalten sind und in welcher Ausprägung (maschinenlesbar oder nicht). Daher MUSS der jeweilige section/code als serviceEvent/code als auch die section/templateId (OID Bereich: 1.2.40.0.34.6.0.11.2.X) der Sektion als serviceEvent/id@root-Element angegeben werden. ↔ Hinweis zum XDS-Mapping: Da diese Informationen in die XDS-Metadaten übernommen werden, ergeben sich folgende Implikationen: Die Zeitangaben des ersten documentationOf/serviceEvent-Elements werden in die Dokument-Metadaten übernommen Die ServiceEvents stellen eine wertvolle Information zum Suchen und Filtern in den Dokument-Metadaten dar!
Klassifikation | CDA Header Level Template
Offen/Geschlossen | Geschlossen (nur definierte Elemente sind erlaubt)
Benutzt von / Benutzt |
Benutzt von 1 Transaction und 6 Templates, Benutzt 2 Templates
Benutzt von | als | Name | Version
--- | --- | --- | ---
elgaambbef-transaction-3 | Transaktion | Ambulanzbefund (v1) | 2023‑05‑09 07:32:49
1.2.40.0.34.6.0.11.0.5 | Inklusion | Ambulanzbefund (1.3.1+20220603) | 2022‑06‑07 10:53:37
1.2.40.0.34.6.0.11.0.5 | Inklusion | Ambulanzbefund (1.3.1+20220603) | 2022‑06‑03 10:49:13
1.2.40.0.34.6.0.11.0.5 | Inklusion | Ambulanzbefund (1.3.0+20220209) | 2021‑10‑27 13:18:25
1.2.40.0.34.6.0.11.0.5 | Inklusion | Ambulanzbefund (1.2.0+20210304) | 2021‑02‑08 13:01:55
1.2.40.0.34.6.0.11.0.5 | Inklusion | Ambulanzbefund (2020.1) | 2020‑10‑09 11:29:46
1.2.40.0.34.6.0.11.0.5 | Inklusion | Ambulanzbefund (2020) | 2019‑05‑10 09:04:27
Benutzt | als | Name | Version
1.2.40.0.34.6.0.11.9.15 | Containment | Time Interval Information minimal (1.0.1+20210628) | DYNAMIC
1.2.40.0.34.6.0.11.9.22 | Inklusion | Assigned Entity (1.0.2+20230717) | DYNAMIC
Beziehung | Version: Template 1.2.40.0.34.6.0.11.1.33 Documentation Of Service Event - Outpatient Report (2019‑11‑22 10:21:08) Adaptation: Template 1.2.40.0.34.6.0.11.1.17 Documentation Of Service Event (2019‑03‑14 15:08:34) ref at-cda-bbr- Version: Template 1.2.40.0.34.11.20010 (2017‑07‑21 11:18:58) Version: Template 1.2.40.0.34.11.20010 HeaderServiceEvent (2011‑12‑19) ref elgabbr-
Beispiel |
Strukturbeispiel Koloskopie
<documentationOf typeCode="DOC"> <serviceEvent classCode="ACT" moodCode="EVN"> <id root="1.2.40.0.34.6.0.11.2.1"/> <code code="11369-6" displayName="HISTORY OF IMMUNIZATIONS" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> <effectiveTime> <low value="20190611102209+02:00"/> <high value="20190611132209+02:00"/> </effectiveTime> <performer typeCode="PRF"> <assignedEntity> <!-- include template 1.2.40.0.34.6.0.11.9.22 'Assigned Entity' (dynamic) 1..1 M --> </assignedEntity> </performer> </serviceEvent></documentationOf>
Beispiel |
Strukturbeispiel Hämatologie
<documentationOf typeCode="DOC"> <serviceEvent classCode="ACT" moodCode="EVN"> <id root="1.2.40.0.34.6.0.11.2.53"/> <code code="11369-6" displayName="History of Immunization Narrative" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> <effectiveTime> <low value="20190611102209+02:00"/> <high value="20190611132209+02:00"/> </effectiveTime> <performer typeCode="PRF"> <time> <low nullFlavor="UNK" value="20190611132209+02:00"/> <high nullFlavor="UNK" value="20190611132209+02:00"/> </time> <assignedEntity> <!-- include template 1.2.40.0.34.6.0.11.9.22 'Assigned Entity' (dynamic) 1..1 M --> </assignedEntity> </performer> </serviceEvent></documentationOf>
Item | DT | Kard | Konf | Beschreibung | Label
--- | --- | --- | --- | --- | ---
hl7:documentationOf |  |  |  | Komponente für die Gesundheitsdienstleistung. |
@typeCode | cs | 0 … 1 | F | DOC
hl7:serviceEvent |  | 1 … 1 | M | Die serviceEvents in den ELGA Ambulanzbefunden MÜSSEN die section/code-Elemente wiedergeben als auch die section/template-id. Diese Informationen werden über eine Mapping-Vorschrift in die XDS-Metadaten übernommen und ermöglichen einem ELGA-Teilnehmer zu erkennen, welche Sektionen beinhaltet sind und in welchem Kodierungsgrad diese vorliegen. Daher muss für jede Sektion, welche medizinische Information enthält (Ausnahmen sind "Brieftext" und "Abschließende Bemerkungen"), ein documentationOf/serviceEvent codiert werden. |
@classCode | cs | 0 … 1 | F | ACT
@moodCode | cs | 0 … 1 | F | EVN
hl7:id | II | 1 … 1 | M |  |
@extension | st | 0 | NP | NP/nicht anwesend
@root | uid | 1 … 1 | R | In das serviceEvent/id@root Attribute MUSS die section/templateId@root geschrieben werden. Im Falle von mehreren section/templateIds MUSS jene gewählt werden, welche in dem OID-Bereich 1.2.40.0.34.6.0.11.2.X zu finden ist.
hl7:code | CE | 1 … 1 | R | Code der Gesundheitsdienstleistung. Zugelassene nullFlavor: UNK ↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut eventCodeList gemappt. |
@code | cs | 1 … 1 | R |
@codeSystem | oid | 1 … 1 | R |
@codeSystemName | st | 0 … 1 |  |
@displayName | st | 1 … 1 | R |
| CONF |
Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.360 ​ELGA_SectionsServiceEvents (DYNAMIC)
hl7:effectiveTime | IVL_TS | 1 … 1 | M | Zeitraum der Gesundheitsdienstleistung, Die semantische Bedeutung dieser Zeitpunkte wird in den speziellen Implementierungsleitfäden festgelegt. ↔ Hinweis zum XDS-Mapping: Dieses Element wird in die XDS-Attribute serviceStartTime und serviceStopTime gemappt. Für die automatisierte Datenübernahme aus dem CDA-Dokument in die XDS-Dokumentmetadaten ist stets ein Zeitintervall anzugeben. ACHTUNG: Die Zeitangaben der jeweils ersten Gesundheitsdienstleistung (erstes documentationOf/serviceEvent-Element) werden in die Dokument-Metadaten übernommen! Die Bedeutung der Dokument-Metadaten-Elemente lautet daher wie folgt: serviceStartTime: Beginn des ersten documentationOf/serviceEvent-Elements serviceStopTime: Ende des ersten documentationOf/serviceEvent-Elements Beinhaltet 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC) |
hl7:performer |  | 0 … * |  | Durchführende Entität(en) der Gesundheitsdienstleistung. |
@typeCode | cs | 1 … 1 | R | Zulässige Werte gemäß Value-Set „ELGA_ServiceEventPerformer“
| CONF |
Der Wert von @typeCode MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.43 ELGA_ServiceEventPerformer (DYNAMIC)
hl7:functionCode | CE | 0 … 1 | R |  |
| CONF |
Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)
hl7:time | IVL_TS | 0 … 1 |  | Zeit, in der der Performer mit der Gesundheitsdienstleistung beschäftigt war (wenn abweichend von EffectiveTime im Act). Grundsätzlich sind die Vorgaben gemäß „Zeit-Elemente“ zu befolgen. Zugelassene nullFlavor: UNK |
hl7:low | TS.AT.TZ | 1 … 1 | R |  |
@nullFlavor | cs | 0 … 1 | F | UNK
hl7:high | TS.AT.TZ | 1 … 1 | R |  |
@nullFlavor | cs | 0 … 1 | F | UNK
hl7:assignedEntity |  | 1 … 1 | M |  |
Eingefügt | 1 … 1 | M | von 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC)
@classCode | cs | 0 … 1 | F | ASSIGNED
Auswahl | 1 … 1 |  | Mindestens eine ID der Person der Entität Elemente in der Auswahl: hl7:id[not(@nullFlavor)] hl7:id[@nullFlavor='NI'] hl7:id[@nullFlavor='UNK']
| Constraint | Zugelassene nullFlavor: NI … Die Person der Entität hat keine Identifikationsnummer UNK … Die Person der Entität hat eine Identifikationsnummer, diese ist jedoch unbekannt
hl7:id | II | 0 … * |  |  |
wo [not(@nullFlavor)] |
hl7:id | II | 0 … 1 |  |  |
wo [@nullFlavor='NI'] |
@nullFlavor | cs | 1 … 1 | F | NI
hl7:id | II | 0 … 1 |  |  |
wo [@nullFlavor='UNK'] |
@nullFlavor | cs | 1 … 1 | F | UNK
Auswahl | 1 … 1 |  | Elemente in der Auswahl: hl7:addr[not(@nullFlavor)] welches enthält Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:addr[@nullFlavor='UNK']
hl7:addr |  | 0 … 1 |  | Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) |
wo [not(@nullFlavor)] |
hl7:addr |  | 0 … 1 |  |  |
wo [@nullFlavor='UNK'] |
@nullFlavor | cs | 1 … 1 | F | UNK
hl7:telecom | TEL.AT | 1 … 1 | M | Beliebig viele Kontakt-Elemente der Person der Entität. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen. |
wo [not(@nullFlavor)] |
@value | url | 1 … 1 | R | Die Kontaktadresse (Telefonnummer, Email, etc.). Es gelten die ELGA Formatkonventionen für Telekom-Daten, z.B. tel:+43.1.1234567 Zulässige Werteliste für telecom Präfixe gemäß Value Set "ELGA_URLScheme"
@use | cs | 0 … 1 |  | Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP. Zulässige Werte gemäß Value Set "ELGA_TelecomAddressUse"
| Constraint | Werden mehrere gleichartige "telecom"-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
hl7:assignedPerson |  | 1 … 1 | M | Personendaten der Person der Entität. Grundsätzlich sind die Vorgaben gemäß „Personen-Element“ zu befolgen. Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) |
hl7:representedOrganization |  | 1 … 1 | M | Organisationsdaten der Entität. Grundsätzlich sind die Vorgaben gemäß „Organisations-Element“ zu befolgen. Beinhaltet 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) |