1.2.40.0.34.6.0.11.1.33

Weitere Informationen sind zusammengefasst im Hilfe-Beitrag Templates.

1 Template elgagab_header_DocumentationOfServiceEventOutpatientReport

1.1 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. ↔ Hinweis zum XDS-Mapping:  Da diese Informationen in die XDS-Metadaten übernommen werden, ergeben sich folgende Implikationen: Es SOLL mindestens eine Gesundheitsdienstleistung als documentationOf/serviceEvent-Element angegeben werden Es können beliebig viele weitere Gesundheitsdienstleistungen als weitere documentationOf/serviceEvent-Elemente angegeben werden. Die serviceEvents sind die einzigen medizinischen Informationen zum Dokument im XDS-Dokumentenregister Können daher als Such-/Filterkriterium verwendet werden und scheinen ggf. in den Ergebnissen der Suchabfragen auf 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! 

1.2 Aktuelle Version

Id	1.2.40.0.34.6.0.11.1.33	Gültigkeit	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	Benutzt 2 Templates 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) ref elgaambbef- 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. (elg...ort) @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. (elg...ort) @classCode cs 0 … 1 F ACT @moodCode cs 0 … 1 F EVN hl7:id II 1 … 1 M (elg...ort) @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. (elg...ort) @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 elgagab_SectionsServiceEvent_VS (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) (elg...ort) hl7:performer 0 … * Durchführende Entität(en) der Gesundheitsdienstleistung. (elg...ort) @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 (elg...ort)   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 (elg...ort) hl7:low TS.AT.TZ 1 … 1 R (elg...ort) @nullFlavor cs 0 … 1 F UNK hl7:high TS.AT.TZ 1 … 1 R (elg...ort) @nullFlavor cs 0 … 1 F UNK hl7:assignedEntity 1 … 1 M (elg...ort) 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 … * (elg...ort) wo [not(@nullFlavor)] hl7:id II 0 … 1 (elg...ort) wo [@nullFlavor='NI'] @nullFlavor cs 1 … 1 F NI hl7:id II 0 … 1 (elg...ort) 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) (elg...ort) wo [not(@nullFlavor)] hl7:addr 0 … 1 (elg...ort) 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. (elg...ort) 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:assigned​Person 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) (elg...ort) hl7:represented​Organization 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) (elg...ort)

1.3 Zusammenstellung aller Versionen dieses Templates

(bisher keine weiteren Angaben)