|
|
Zeile 5: |
Zeile 5: |
| =Template ''atcdabbr_header_DocumentationOfServiceEvent''= | | =Template ''atcdabbr_header_DocumentationOfServiceEvent''= |
| ==Beschreibung== | | ==Beschreibung== |
− | <p>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 | + | <p>Dokumentation der Gesundheitsdienstleistung. |
− | kann die dokumentierte Gesundheitsdienstleistung näher spezifiziert werden. Dies darf natürlich nicht im Widerspruch zum Dokumententyp stehen.TODO SSA: für alle Elemente, die in die XDS-Metadaten übernommen werden sollen/können/müssen: Hinweis im Template (?!)</p> | + | 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. |
| + | 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 (rein) medizinischen Informationen zum Dokument im 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 |
| + | |
| + | -> Sollte eine wertvolle Information sein (für den Behandler!) |
| + | |
| + | |
| + | TODO SSA: für alle Elemente, die in die XDS-Metadaten übernommen werden sollen/können/müssen: Hinweis im Template (?!)</p> |
| ==Aktuelle Version== | | ==Aktuelle Version== |
| {{:{{BASEPAGENAME}}/dynamic}} | | {{:{{BASEPAGENAME}}/dynamic}} |
Version vom 12. Juni 2019, 04:31 Uhr
|
Diese Seite wird automatisch mittels eines Bots (ADbot) aus ART-DECOR extrahiert.
Manuelle Änderungen dieser Seite sind wirkungslos. |
|
Bitte beachten:
- Diese Seite enthält Unterseiten in der Form /static-YYY-MM-DD, die die einzelnen statischen Versionen des Templates widerspiegeln. Diese Seite ist transklusionsfähig.
- Eine Unterseite /dymamic weist auf die letzte aktuelle Version. Diese Seite ist transklusionsfähig.
- Die zugehörigen Beschreibungen sind zurzeit nur in Deutsch verfügbar.
|
Weitere Informationen sind zusammengefasst im Hilfe-Beitrag Templates.
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.
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 (rein) medizinischen Informationen zum Dokument im 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
-> Sollte eine wertvolle Information sein (für den Behandler!)
TODO SSA: für alle Elemente, die in die XDS-Metadaten übernommen werden sollen/können/müssen: Hinweis im Template (?!)
1.2 Aktuelle Version
Id | 1.2.40.0.34.6.0.11.1.17 ref at-cda-bbr- | Gültigkeit | 2021‑02‑19 11:06:35Andere Versionen mit dieser Id: - atcdabbr_header_DocumentationOfServiceEvent vom 2019‑03‑14 15:08:34
|
---|
Status | Aktiv | Versions-Label | 1.0.0+20210219 |
---|
Name | atcdabbr_header_DocumentationOfServiceEvent | Bezeichnung | Documentation Of Service Event |
---|
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!
|
|
Klassifikation | CDA Header Level Template |
---|
Offen/Geschlossen | Geschlossen (nur definierte Elemente sind erlaubt) |
---|
Assoziiert mit | Assoziiert mit 4 Konzepte | Id | Name | Datensatz |
---|
at-cda-bbr-dataelement-44 | Gesundheitsdienstleistung | Dataset A Allgemeiner Leitfaden | at-cda-bbr-dataelement-45 | Code | Dataset A Allgemeiner Leitfaden | at-cda-bbr-dataelement-46 | Zeitraum der Gesundheitsdienstleistung | Dataset A Allgemeiner Leitfaden | at-cda-bbr-dataelement-47 | Durchführende Entität | Dataset A Allgemeiner Leitfaden |
|
|
---|
Benutzt | Benutzt 2 Templates | Benutzt | als | Name | Version |
---|
1.2.40.0.34.6.0.11.9.15 | Inklusion | 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.17 Documentation Of Service Event (2019‑03‑14 15:08:34) ref at-cda-bbr- |
---|
Beispiel | Strukturbeispiel Koloskopie | <documentationOf typeCode="DOC"> <serviceEvent classCode="ACT" moodCode="EVN"> <code code="KOL" displayName="Koloskopie" codeSystem="2.16.840.1.2.3.4.5.6.7.8.9" codeSystemName="Name des Codesystems"/> <effectiveTime> <low value="20190611102209+0200"/> <high value="20190611132209+0200"/> </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"> <code code="300" displayName="Hämatologie" codeSystem="1.2.40.0.34.5.11" codeSystemName="ELGA_LaborparameterErgaenzung"/> <effectiveTime> <low value="20190611102209+0200"/> <high value="20190611132209+0200"/> </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 |
---|
| | | | Komponente für die Gesundheitsdienstleistung.
| (atc...ent) | | | at-cda-bbr-dataelement-44 | Gesundheitsdienstleistung | Dataset A Allgemeiner Leitfaden |
| | @typeCode
|
| cs | 0 … 1 | F | DOC | | hl7:serviceEvent
|
| | 1 … 1 | M | Gesundheitsdienstleistung. Verweis auf speziellen Implementierungsleitfaden: Ob eine Gesundheitsdienstleistung angegeben werden muss, und welche Bedeutung dieses Element hat, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
| (atc...ent) | | | @classCode
|
| cs | 0 … 1 | F | ACT | | | @moodCode
|
| cs | 0 … 1 | F | EVN | | | hl7:id
|
| II | 0 … 1 | | | (atc...ent) | Auswahl | 1 … 1 | | Elemente in der Auswahl:- hl7:code[not(@nullFlavor)]
- hl7:code[@nullFlavor='UNK']
| | CE | 0 … 1 | | Code der Gesundheitsdienstleistung. Zugelassene nullFlavor: UNK
Verweis auf speziellen Implementierungsleitfaden: Welche Codierung angewandt werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
↔ Hinweis zum
XDS-Mapping: Dieses Element wird ins XDS-Attribut eventCodeList gemappt.
| (atc...ent) | wo [not(@nullFlavor)] | | | | at-cda-bbr-dataelement-45 | Code | Dataset A Allgemeiner Leitfaden |
| | cs | 1 … 1 | R | | | oid | 1 … 1 | R | | | st | 1 … 1 | R | | | CE | 0 … 1 | | | (atc...ent) | wo [@nullFlavor='UNK'] | | | cs | 1 … 1 | F | UNK | | | 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
| (atc...ent) | | | at-cda-bbr-dataelement-46 | Zeitraum der Gesundheitsdienstleistung | Dataset A Allgemeiner Leitfaden |
| Eingefügt | | | von 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC) | Auswahl | 1 … 1 | | Elemente in der Auswahl:- hl7:low[@value]
- hl7:low[@nullFlavor='UNK']
| | TS.AT.TZ | 0 … 1 | | | (atc...ent) | wo [@value] | | | TS.AT.TZ | 0 … 1 | | | (atc...ent) | wo [@nullFlavor='UNK'] | | | cs | 1 … 1 | F | UNK | Auswahl | 1 … 1 | | Elemente in der Auswahl:- hl7:high[@value]
- hl7:high[@nullFlavor='UNK']
| | TS.AT.TZ | 0 … 1 | | | (atc...ent) | wo [@value] | | | TS.AT.TZ | 0 … 1 | | | (atc...ent) | wo [@nullFlavor='UNK'] | | | cs | 1 … 1 | F | UNK | | | hl7:performer
|
| | 0 … * | R | Person oder Organisation, die die Gesundheitsdienstleistung durchführt. Verweis auf speziellen Implementierungsleitfaden: Ob und welche durchführende Entität eingetragen werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
| (atc...ent) | | 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) |
| | CE | 0 … 1 | R | Funktionscode | (atc...ent) | | CONF | Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC) |
| | 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
| (atc...ent) | Eingefügt | | | von 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC) | Auswahl | 1 … 1 | | Elemente in der Auswahl:- hl7:low[@value]
- hl7:low[@nullFlavor='UNK']
| | TS.AT.TZ | 0 … 1 | | | (atc...ent) | wo [@value] | | | TS.AT.TZ | 0 … 1 | | | (atc...ent) | wo [@nullFlavor='UNK'] | | | cs | 1 … 1 | F | UNK | Auswahl | 1 … 1 | | Elemente in der Auswahl:- hl7:high[@value]
- hl7:high[@nullFlavor='UNK']
| | TS.AT.TZ | 0 … 1 | | | (atc...ent) | wo [@value] | | | TS.AT.TZ | 0 … 1 | | | (atc...ent) | wo [@nullFlavor='UNK'] | | | cs | 1 … 1 | F | UNK | | | 1 … 1 | M | | (atc...ent) | | | at-cda-bbr-dataelement-47 | Durchführende Entität | Dataset A Allgemeiner Leitfaden |
| Eingefügt | 1 … 1 | M | von 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC) | | 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
| | II | 0 … * | | | (atc...ent) | wo [not(@nullFlavor)] | | | II | 0 … 1 | | | (atc...ent) | wo [@nullFlavor='NI'] | | | cs | 1 … 1 | F | NI | | II | 0 … 1 | | | (atc...ent) | wo [@nullFlavor='UNK'] | | | 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']
| | | 0 … 1 | | Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) | (atc...ent) | wo [not(@nullFlavor)] | | | | 0 … 1 | | | (atc...ent) | wo [@nullFlavor='UNK'] | | | cs | 1 … 1 | F | UNK | | TEL.AT | 1 … 1 | M |
Beliebig viele Kontakt-Elemente der Person der Entität.
Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.
| (atc...ent) | wo [not(@nullFlavor)] | | | 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"
| | 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.
| | | 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) | (atc...ent) | | | | | 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) | (atc...ent) |
|
1.3 Zusammenstellung aller Versionen dieses Templates
(bisher keine weiteren Angaben)