ILF:EMS Labor Arzt: Unterschied zwischen den Versionen

Aus HL7 Austria MediaWiki
Wechseln zu: Navigation, Suche
[unmarkierte Version][unmarkierte Version]
K (CDA Templates)
(Entry Templates)
 
(22 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 52: Zeile 52:
  
 
=Zusammenfassung=
 
=Zusammenfassung=
 +
Der gegenständliche Leitfaden spezifiziert die Inhaltselemente und die Struktur, welche im Rahmen der Meldung von meldepflichtigen Krankheiten für Österreich benötigt werden. Akteure im Kontext dieser Meldung können Ärzte oder Labore sein, welche an das für Gesundheit zuständige Bundesministerium melden. Der Leitfaden spezifiziert z.T. unterschiedliche Inhaltselement, je nachdem ob es sich um eine Arzt- oder Labormeldung handelt. Erstere kann mehr Informationen über den Gesundheitszustand und das soziale Umfeld des Patienten beinhalten, da dieser in Kontakt mit dem meldenden Arzt steht. Die Labormeldung kann im Gegenzug und abseits der Meldung eines Erregers und der resultierenden Krankheit auch noch weitere Laborparameter bereitstellen. Die Strukturierung und Kodierung dieser steht im engen Zusammenhang mit dem ELGA Leitfaden für Labordokumente. Allgemein gilt: auch wenn dieser Leitfaden und die entstehenden CDA Dokumente KEINE ELGA eBefunde sind, dass bei der Spezifikation darauf Wert gelegt wurde, möglichst schon vorhandene CDA Dokumentenelement zu nutzen bzw. auf diesen aufzubauen.
  
 
=Informationen über dieses Dokument=
 
=Informationen über dieses Dokument=
Zeile 60: Zeile 61:
 
Mit der Version 1 dieses Leitfadens wurde die Labormeldung publiziert. Folgend wurde die Arztmeldung fachlich ausgearbeitet und da es sowohl fachlich und auch aus Gründen des Investitionsschutzes für Softwarehersteller sinnvoll ist beide Meldungen auf den gleichen Grundlagen aufzubauen, wurde die Arztmeldung mit der Version 2 integriert. Die vorliegende Version beinhaltet somit sowohl die Labor- als auch die Arztmeldung. Die jeweils notwendigen Teile sind im Leitfaden entsprechend beschrieben und gekennzeichnet.
 
Mit der Version 1 dieses Leitfadens wurde die Labormeldung publiziert. Folgend wurde die Arztmeldung fachlich ausgearbeitet und da es sowohl fachlich und auch aus Gründen des Investitionsschutzes für Softwarehersteller sinnvoll ist beide Meldungen auf den gleichen Grundlagen aufzubauen, wurde die Arztmeldung mit der Version 2 integriert. Die vorliegende Version beinhaltet somit sowohl die Labor- als auch die Arztmeldung. Die jeweils notwendigen Teile sind im Leitfaden entsprechend beschrieben und gekennzeichnet.
  
'''Dieses Dokument spezifiziert den Aufbau einer Labor bzw. Arztmeldung an das epidemiologische Meldesystem des für Gesundheit zuständige Bundesministeriums. Die Strukturvorgaben in dieser Spezifikation sind z.T. generisch. Dies trifft im Speziellen die ''EMS Parameter'' welche für die Labormeldung benötigt werden. Welche Parameter für welche zu meldende Krankheit herangezogen werden können bzw. müssen ist NICHT in diesem Leitfaden geregelt. Die Information hierzu finden Sie im vom für Gesundheit zuständigen Bundesministeriums veröffentlichen [https://cloud.technikum-wien.at/s/z5c77RQGBKCpAHP XML-Dokument]'''
+
'''Dieses Dokument spezifiziert den Aufbau einer Labor- bzw. Arztmeldung an das epidemiologische Meldesystem des für Gesundheit zuständige Bundesministeriums. Die Strukturvorgaben in dieser Spezifikation sind z.T. generisch. Dies trifft im Speziellen die ''EMS Parameter'' welche für die Labormeldung benötigt werden. Welche Parameter für welche zu meldende Krankheit herangezogen werden können bzw. müssen ist NICHT in diesem Leitfaden geregelt. Die Information hierzu finden Sie im vom für Gesundheit zuständigen Bundesministeriums veröffentlichen [https://cloud.technikum-wien.at/s/z5c77RQGBKCpAHP XML-Dokument]'''
  
'''Der gegenständlich Implementierungsleitfaden versucht weitest möglichst schon in ELGA definierte Bestandteile (templates) wiederzuverwenden. Zu beachten ist, dass eventuell nicht alle Inhaltselemente vom EMS benötigt werden. Ziel ist es, dass die Implementierung dieses CDA Implementierungsleitfadens möglichst schon einmal umgesetzte Elemente erneut verwendet werden können.'''
+
{{BeginYellowBox}}
 +
'''Hinweis:'''<br />Sollten Sie beobachten, dass Divergenzen zwischen den Inhalten am Terminologieserver und dem XML-Dokument des Bundesministeriums bestehen, bitte diese an [mailto:cda@technikum-wien.at cda@technikum-wien.at] melden. Weiters zu beachten: Der Datenimport des Bundesministeriums basiert auf den Daten im XML-Dokument. Somit ist davon auszugehen, dass das XML-Dokument den aktuelleren Datenstand besitzt
 +
{{EndYellowBox}}
 +
 
 +
Der gegenständlich Implementierungsleitfaden versucht weitestgehend schon in ELGA definierte Bestandteile (templates) wiederzuverwenden. Zu beachten ist, dass eventuell nicht alle Inhaltselemente vom EMS benötigt werden.  
  
  
Zeile 122: Zeile 127:
 
Es zeigt sich jedoch, dass die elektronische Meldung meldepflichtiger Krankheiten zum einen durchaus einen Bedarf an zusätzlichen Spezialdaten (z.B. geografische Informationen) aufweist und zum anderen die Anforderung an die Darstellung natürlich von denen eines Befundes abweichen.  
 
Es zeigt sich jedoch, dass die elektronische Meldung meldepflichtiger Krankheiten zum einen durchaus einen Bedarf an zusätzlichen Spezialdaten (z.B. geografische Informationen) aufweist und zum anderen die Anforderung an die Darstellung natürlich von denen eines Befundes abweichen.  
 
Daher schränkt vorliegender Leitfaden die bestehenden Definitionen weiter ein bzw. erweitert diese um entsprechende Teile zur Abbildung der Spezifika der EMS Meldung. Insbesondere betrifft das die in Tabelle 1 dargestellten Daten. Die entsprechende ELGA Kompatibilität ist in den jeweiligen Kapiteln angegeben.
 
Daher schränkt vorliegender Leitfaden die bestehenden Definitionen weiter ein bzw. erweitert diese um entsprechende Teile zur Abbildung der Spezifika der EMS Meldung. Insbesondere betrifft das die in Tabelle 1 dargestellten Daten. Die entsprechende ELGA Kompatibilität ist in den jeweiligen Kapiteln angegeben.
Der tatsächliche Inhalt und Umfang der EMS Meldung ist abhängig vom Typ der Meldung (Labor oder Arzt) und vom gemeldeten Erreger bzw. der gemeldeten Krankheit. Grundsätzlich immer verpflichtend zu übermitteln sind somit gefundene Erreger bzw. dadurch ausgelöste Krankheiten. Davon ausgehend ergeben sich unter Umständen zusätzliche verpflichtende Daten (TODO Refernez zu Kapitel erstellen). Weitere Daten können jederzeit optional im Dokument enthalten sein.
+
Der tatsächliche Inhalt und Umfang der EMS Meldung ist abhängig vom Typ der Meldung (Labor oder Arzt) und vom gemeldeten Erreger bzw. der gemeldeten Krankheit. Grundsätzlich immer verpflichtend zu übermitteln sind somit gefundene Erreger bzw. dadurch ausgelöste Krankheiten. Davon ausgehend ergeben sich unter Umständen zusätzliche verpflichtende Daten (siehe Kapitel [[#Übersicht über die medizinischen Inhalte (CDA-Body)|Übersicht über die medizinischen Inhalte (CDA-Body)]]). Weitere Daten können jederzeit optional im Dokument enthalten sein.
  
 
=Einleitung=
 
=Einleitung=
Zeile 143: Zeile 148:
  
 
==Autoren und Mitwirkende==
 
==Autoren und Mitwirkende==
Der vorliegende Leitfaden wurde unter der Leitung der Fachhochschule Technikum Wien erstellt und Inhalte dieses Leitfadens wurden gemeinsam mit ELGA GmbH an bestehende und künftige andere Leitfäden angegelichen. Vom für Gesundheit zuständigen Bundesministeriums wurden durch Herrn Dr. Weninger und Herrn Pokorny die Erstellung des Leitfadens begleitet.
+
Der vorliegende Leitfaden wurde unter der Leitung der Fachhochschule Technikum Wien erstellt und Inhalte dieses Leitfadens wurden gemeinsam mit ELGA GmbH an bestehende und künftige andere Leitfäden angegelichen. Vom für Gesundheit zuständigen Bundesministeriums wurde die Erstellung des Leitfadens durch Herrn Dr. Weninger und Herrn Pokorny begleitet.
  
 
===Autoren===
 
===Autoren===
Zeile 174: Zeile 179:
 
Die gegenständliche Spezifikation, basierend auf den aus den Use-cases abgeleiteten Anforderungen, hat KEINE Anforderungen bezüglich der Bildschirmdarstellung, da eine "menschliche" Betrachtung des Dokuments (auf Empfängerseite) nicht vorgesehen ist. Die allgemeine Anforderungen, dass maschinenlesbare Inhalte auch menschenlesbar sein soll, ist zu beachten. Jedoch gibt es keine formalen Anforderungen bezüglich der Strukturierung und Darstellung der Inhalte.
 
Die gegenständliche Spezifikation, basierend auf den aus den Use-cases abgeleiteten Anforderungen, hat KEINE Anforderungen bezüglich der Bildschirmdarstellung, da eine "menschliche" Betrachtung des Dokuments (auf Empfängerseite) nicht vorgesehen ist. Die allgemeine Anforderungen, dass maschinenlesbare Inhalte auch menschenlesbar sein soll, ist zu beachten. Jedoch gibt es keine formalen Anforderungen bezüglich der Strukturierung und Darstellung der Inhalte.
  
Ein Vorschlag zur Strukturierung kann Kapitel [[#Übersicht über die medizinischen Inhalte (CDA-Body)]] liefern.
+
Es wird empfohlen, dass der Level 2 Text (''section/text'') mit Hilfe zur Verfügung stehender Formatierungswerkzeuge (z.B.: ''paragraph'') strukturiert wird. Hierzu kann die grobe Struktur des CDA-Bodys, wie in Kapitel [[#Übersicht über die medizinischen Inhalte (CDA-Body)|Übersicht über die medizinischen Inhalte (CDA-Body)]] ersichtlich, herangezogen werden.
 +
 
 +
==Dokumenten-Metadaten (XDS-Metadaten)==
 +
Arzt und Labormeldungen im Kontext des epidemiologischen Meldesystems werden zum jetzigen Zeitpunkt NICHT in die ELGA – Infrastruktur oder ein anderes IHE XDS-basierendes Gesamtsystem eingebracht. Die EMS Meldung wird gerichtet an das für Gesundheit zuständige Bundesministerium übermittelt. Hierbei folgt es jedoch NICHT vorhanden IHE Spezifikationen für den gerichteten Dokumentenaustausch (IHE XDR) und es werden KEINE Metadaten benötigt (weder für eine Registrierung noch für eine maschinelle Interpretation eines dezidierten Empfängers).
 +
 
 +
Sollten dieser Leitfaden Angaben zum Mapping der CDA Daten in die XDS-Metadaten enthalten, ist dies der Tatsache geschuldet, dass Element (inkl. deren Beschreibung) aus dem ELGA Kontext wiederverwendet werden. Für die Implementierung einer EMS Arzt- bzw. Labormeldung können diese ignoriert werden.
  
 
=User Storys ("Anwendungsfälle")=
 
=User Storys ("Anwendungsfälle")=
  
 
==Anwendungsfall EMS01: Labormeldung "automatische Schnittstelle"==
 
==Anwendungsfall EMS01: Labormeldung "automatische Schnittstelle"==
* In einem Labor wird ein meldungspflichtiger Keim gefunden
+
* In einer Laborprobe wird ein meldepflichtiger Keim gefunden
 
* Labor: Datenaufbereitung durch die Labor-EDV: Erzeugen des CDA-Dokuments
 
* Labor: Datenaufbereitung durch die Labor-EDV: Erzeugen des CDA-Dokuments
 
Labor: Automatisierte Übermittlung des erzeugten CDA-Dokuments (mit vorheriger Authentifizierung) an das entsprechende EMS-Webservice. Als Response erhält der Absender die Information ob ein neuer Fall angelegt wurde oder ob die gesendete Meldung zu einem bestehenden Fall hinzugefügt wurde sowie die Fall-Id.   
 
Labor: Automatisierte Übermittlung des erzeugten CDA-Dokuments (mit vorheriger Authentifizierung) an das entsprechende EMS-Webservice. Als Response erhält der Absender die Information ob ein neuer Fall angelegt wurde oder ob die gesendete Meldung zu einem bestehenden Fall hinzugefügt wurde sowie die Fall-Id.   
Zeile 187: Zeile 197:
 
**Fall anlegen oder bestehenden Fall ergänzen
 
**Fall anlegen oder bestehenden Fall ergänzen
 
**EMS: Ggf. Signalisierung
 
**EMS: Ggf. Signalisierung
**EMS: Ggf. Nachbearbeitung durch Bearbeiter (BMGF) bzw. Bezirksverwaltungsbehörde
+
**EMS: Ggf. Nachbearbeitung durch Bearbeiter (zuständiges Ministerium) bzw. Bezirksverwaltungsbehörde
  
 
==Anwendungsfall EMS02: Labormeldung "Gatewayapplikation"==
 
==Anwendungsfall EMS02: Labormeldung "Gatewayapplikation"==
Zeile 203: Zeile 213:
 
**Fall anlegen oder bestehenden Fall ergänzen
 
**Fall anlegen oder bestehenden Fall ergänzen
 
**EMS: Ggf. Signalisierung
 
**EMS: Ggf. Signalisierung
**EMS: Ggf. Nachbearbeitung durch Bearbeiter (BMGF) bzw. Bezirksverwaltungsbehörde
+
**EMS: Ggf. Nachbearbeitung durch Bearbeiter (zuständiges Ministerium) bzw. Bezirksverwaltungsbehörde
  
 
==Anwendungsfall EMS03: Labormeldung Referenzlabor==
 
==Anwendungsfall EMS03: Labormeldung Referenzlabor==
Zeile 232: Zeile 242:
  
 
==Anwendungsfall EMS06: Arztmeldung automatisiert intramural ==
 
==Anwendungsfall EMS06: Arztmeldung automatisiert intramural ==
*Ein Arzt / eine Ärztin stellt bei einem Patienten/einer Patientin, der/die intramural ambulant oder stationär behandelt wird eine meldepflichtige Erkrankung fest oder hat einen begründeten Verdacht auf eine solche.
+
*Ein Arzt stellt bei einem Patienten, der intramural ambulant oder stationär behandelt wird eine meldepflichtige Erkrankung fest oder hat einen begründeten Verdacht auf eine solche.
*Der Arzt/Die Ärztin erfasst die erforderlichen Daten im Krankenhausinformationssystem.
+
*Der Arzt erfasst die erforderlichen Daten im Krankenhausinformationssystem.
*Datenaufbereitung durch Krankenhausinformationssystem: Erzeugen des CDA-Dokuments und automatisierte Übermittlung des erzeugten CDA-Dokuments (mit vorheriger Authentifizierung über X.509 Zertifikate) an das entsprechende EMS-Webservice (analog Anwendungsfall EMS01). Als Response erhält der Absender die Information ob ein neuer Fall angelegt wurde oder ob die gesendete Meldung zu einem bestehenden Fall hinzugefügt wurde sowie die Fall-Id.  
+
*Datenaufbereitung durch Krankenhausinformationssystem: Erzeugen des CDA-Dokuments und automatisierte Übermittlung des erzeugten CDA-Dokuments (mit vorheriger Authentifizierung) an das entsprechende EMS-Webservice (analog Anwendungsfall EMS01). Als Response erhält der Absender die Information ob ein neuer Fall angelegt wurde oder ob die gesendete Meldung zu einem bestehenden Fall hinzugefügt wurde sowie die Fall-Id.  
 
*EMS-Webservice: Übernahme der Daten mit Datenprüfung  
 
*EMS-Webservice: Übernahme der Daten mit Datenprüfung  
 
*Weiterverarbeitung der Daten:
 
*Weiterverarbeitung der Daten:
Zeile 240: Zeile 250:
 
**Fall anlegen oder bestehenden Fall ergänzen
 
**Fall anlegen oder bestehenden Fall ergänzen
 
**EMS: Ggf. Signalisierung
 
**EMS: Ggf. Signalisierung
*EMS: Ggf. Nachbearbeitung durch Bearbeiter (BMGF) bzw. Bezirksverwaltungsbehörde
+
*EMS: Ggf. Nachbearbeitung durch Bearbeiter (zuständiges Ministerium) bzw. Bezirksverwaltungsbehörde
  
 
==Anwendungsfall EMS07: Arztmeldung automatisiert niedergelassener Bereich ==
 
==Anwendungsfall EMS07: Arztmeldung automatisiert niedergelassener Bereich ==
*Ein niedergelassener Arzt/eine niedergelassene Ärztin stellt bei einem Patienten/einer Patientin eine meldungspflichtige Erkrankung fest oder hat einen begründeten Verdacht auf diese
+
*Ein niedergelassener Arzt stellt bei einem Patienten eine meldungspflichtige Erkrankung fest oder hat einen begründeten Verdacht auf diese
*Der Arzt/Die Ärztin erfasst die erforderlichen Daten über ein entsprechendes Eingabeformular im Arztinformationssystem
+
*Der Arzt erfasst die erforderlichen Daten über ein entsprechendes Eingabeformular im Arztpraxis-Informationssystem
*Datenaufbereitung durch Arztinformationssystem: Erzeugen des CDA-Dokuments und automatisierte Übermittlung des erzeugten CDA-Dokuments (mit vorheriger Authentifizierung über X.509 Zertifikate) an das entsprechende EMS-Webservice. Als Response erhält der Absender die Information ob ein neuer Fall angelegt wurde oder ob die gesendete Meldung zu einem bestehenden Fall hinzugefügt wurde sowie die Fall-Id.   
+
*Datenaufbereitung durch Arztpraxis-Informationssystem: Erzeugen des CDA-Dokuments und automatisierte Übermittlung des erzeugten CDA-Dokuments (mit vorheriger Authentifizierung) an das entsprechende EMS-Webservice. Als Response erhält der Absender die Information ob ein neuer Fall angelegt wurde oder ob die gesendete Meldung zu einem bestehenden Fall hinzugefügt wurde sowie die Fall-Id.   
 
*EMS-Webservice: Übernahme der Daten mit Datenprüfung  
 
*EMS-Webservice: Übernahme der Daten mit Datenprüfung  
 
*Weiterverarbeitung der Daten:
 
*Weiterverarbeitung der Daten:
Zeile 251: Zeile 261:
 
**Fall anlegen oder bestehenden Fall ergänzen
 
**Fall anlegen oder bestehenden Fall ergänzen
 
**EMS: Ggf. Signalisierung
 
**EMS: Ggf. Signalisierung
**EMS: Ggf. Nachbearbeitung durch Bearbeiter (BMGF) bzw. Bezirksverwaltungsbehörde
+
**EMS: Ggf. Nachbearbeitung durch Bearbeiter (zuständiges Ministerium) bzw. Bezirksverwaltungsbehörde
  
 
==Anwendungsfall EMS08: Arztmeldung "Gatewayapplikation" ==
 
==Anwendungsfall EMS08: Arztmeldung "Gatewayapplikation" ==
 
Die Gateway-Applikation (GA) dient zum Erfassen von Arztmeldungen in einem Web-GUI und anschließender Übermittlung der Daten in Form von CDA-Dokumenten an das EMS-Interface. D.h. die GA verwendet dieselbe Schnittstelle wie die Primärinformationssysteme (Arzt- bzw. Krankenhausinformationssystem).
 
Die Gateway-Applikation (GA) dient zum Erfassen von Arztmeldungen in einem Web-GUI und anschließender Übermittlung der Daten in Form von CDA-Dokumenten an das EMS-Interface. D.h. die GA verwendet dieselbe Schnittstelle wie die Primärinformationssysteme (Arzt- bzw. Krankenhausinformationssystem).
  
*Arzt/Ärztin  stellt bei einem Patienten/einer Patientin eine meldungspflichtige Erkrankung fest oder hat einen begründeten Verdacht auf diese.
+
*Arzt stellt bei einem Patienten eine meldungspflichtige Erkrankung fest oder hat einen begründeten Verdacht auf diese.
*Arzt/Ärztin ruft die Gatewayapplikation auf bzw. die GA wird aus dem Primärsystem aufgerufen – Authentifizierung des GDA und Arztes/Ärztin.  
+
*Arzt ruft die Gatewayapplikation auf bzw. die GA wird aus dem Primärsystem aufgerufen – Authentifizierung des GDA und Arztes.  
*Arzt/Ärztin: Erfassen einer Arztmeldung durch den User über ein Web-GUI, bestehend aus folgenden Schritten:
+
*Arzt: Erfassen einer Arztmeldung durch den User über ein Web-GUI, bestehend aus folgenden Schritten:
 
**Eingabe der Kopfdaten der Meldung: Dokumenten-ID, Datum, Patientendaten, Daten zu „Author“, „Informant“, „Custodian“ und „Authenticator“  
 
**Eingabe der Kopfdaten der Meldung: Dokumenten-ID, Datum, Patientendaten, Daten zu „Author“, „Informant“, „Custodian“ und „Authenticator“  
 
**Auswahl der zu meldenden Erkrankung
 
**Auswahl der zu meldenden Erkrankung
Zeile 268: Zeile 278:
 
**Fall anlegen oder bestehenden Fall ergänzen
 
**Fall anlegen oder bestehenden Fall ergänzen
 
**EMS: Ggf. Signalisierung
 
**EMS: Ggf. Signalisierung
**EMS: Ggf. Nachbearbeitung durch Bearbeiter (BMGF) bzw. Bezirksverwaltungsbehörde
+
**EMS: Ggf. Nachbearbeitung durch Bearbeiter (zuständiges Ministerium) bzw. Bezirksverwaltungsbehörde
  
 
=Technische Spezifikation=
 
=Technische Spezifikation=
Zeile 298: Zeile 308:
 
|-
 
|-
 
|Empfänger
 
|Empfänger
|In der Regel das für Gesundheit zustündige Bundesministerium (als Betreiber des EMS)
+
|Betreiber des EMS (in der Regel das für Gesundheit zuständige Bundesministerium)
 
|X
 
|X
 
|X
 
|X
Zeile 707: Zeile 717:
 
Aufgrund der Tatsache, dass sich die Struktur und die CDA Umsetzung der EMS Meldungen an dem Implementierungsleitfaden für ELGA Laborbefunde orientiert gibt es für die Meldung relevante Informationen welche nicht durch einen Laborbefund abgedeckt wird. Aus diesem Grund wird eine eigene Befundgruppe (umgesetzt mit Hilfe des CDA-Organizer-Elements) eingeführt, mit Hilfe derer Informationen, welche nicht in anderen Laborsektionen unterge-bracht werden können, codiert werden können. In diese Gruppe können EMS spezifische Parameter maschinenlesbar codiert werden.
 
Aufgrund der Tatsache, dass sich die Struktur und die CDA Umsetzung der EMS Meldungen an dem Implementierungsleitfaden für ELGA Laborbefunde orientiert gibt es für die Meldung relevante Informationen welche nicht durch einen Laborbefund abgedeckt wird. Aus diesem Grund wird eine eigene Befundgruppe (umgesetzt mit Hilfe des CDA-Organizer-Elements) eingeführt, mit Hilfe derer Informationen, welche nicht in anderen Laborsektionen unterge-bracht werden können, codiert werden können. In diese Gruppe können EMS spezifische Parameter maschinenlesbar codiert werden.
  
<div class="landscape"> ... </div>
+
<div class="landscape">
 +
 
 
==CDA Templates==
 
==CDA Templates==
 
===Header Templates===
 
===Header Templates===
Zeile 791: Zeile 802:
 
====Notification Organizer EMS Arztmeldung====
 
====Notification Organizer EMS Arztmeldung====
 
{{:1.2.40.0.34.6.0.11.3.56/dynamic}}
 
{{:1.2.40.0.34.6.0.11.3.56/dynamic}}
 +
 +
====Notification Condition====
 +
{{:1.3.6.1.4.1.19376.1.3.1.1.1/dynamic}}
  
 
====EMS Case Identification Arztmeldung====
 
====EMS Case Identification Arztmeldung====
Zeile 917: Zeile 931:
 
{{:1.2.40.0.34.6.0.11.9.14/dynamic}}
 
{{:1.2.40.0.34.6.0.11.9.14/dynamic}}
  
 +
</div>
 
=Anhang=
 
=Anhang=
  
 
==Literaturverzeichnis==
 
==Literaturverzeichnis==

Aktuelle Version vom 3. Juli 2020, 09:22 Uhr




Inhaltsverzeichnis

1 Zusammenfassung

Der gegenständliche Leitfaden spezifiziert die Inhaltselemente und die Struktur, welche im Rahmen der Meldung von meldepflichtigen Krankheiten für Österreich benötigt werden. Akteure im Kontext dieser Meldung können Ärzte oder Labore sein, welche an das für Gesundheit zuständige Bundesministerium melden. Der Leitfaden spezifiziert z.T. unterschiedliche Inhaltselement, je nachdem ob es sich um eine Arzt- oder Labormeldung handelt. Erstere kann mehr Informationen über den Gesundheitszustand und das soziale Umfeld des Patienten beinhalten, da dieser in Kontakt mit dem meldenden Arzt steht. Die Labormeldung kann im Gegenzug und abseits der Meldung eines Erregers und der resultierenden Krankheit auch noch weitere Laborparameter bereitstellen. Die Strukturierung und Kodierung dieser steht im engen Zusammenhang mit dem ELGA Leitfaden für Labordokumente. Allgemein gilt: auch wenn dieser Leitfaden und die entstehenden CDA Dokumente KEINE ELGA eBefunde sind, dass bei der Spezifikation darauf Wert gelegt wurde, möglichst schon vorhandene CDA Dokumentenelement zu nutzen bzw. auf diesen aufzubauen.

2 Informationen über dieses Dokument

Der vorliegende Leitfaden wurde unter der Leitung des Bundeministeriums für Soziales, Gesundheit, Pflege und Konsumentenschutz (BMSGPF, ehemals Bundesministerium für Gesundheit), im Folgenden, als das für Gesundheit zuständige Ministerium bezeichnet, erstellt und basiert auf den Definitionen der ELGA Leitfäden für das österreichische Gesundheitswesen, welche von der HL7 Austria einem Abstimmungsverfahren (Ballot) unterzogen wurden. Ebenso wurde dieses Dokument in der vorliegenden Form durch die HL7 Austria ballotiert. Das für Gesundheit zuständige Ministerium genehmigt ausdrücklich die Anwendung des Leitfadens ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente und weist darauf hin, dass dies mit dem Einverständnis aller Mitwirkenden erfolgt. Der Umfang der Codelisten und Valuesets, welche in diesem Leitfaden angeführt werden, sind aufgrund von Vorgaben und Richtlinien des europäischen Systems zur Überwachung von Infektionskrankheiten (The European Surveillance Sytem, TESSy) regelmäßigen Anpassungen unterworfen. Die aktuellen Versionen der Codelisten und Valuesets sind auf der Homepage des für Gesundheit zuständige Ministerium bekanntgegeben und veröffentlicht. Zukünftig ist eine Bereitstellung am Terminologieserver für das österreichische Gesundheitswesen für die Recherche und den automatisierten Download vorgesehen.

Mit der Version 1 dieses Leitfadens wurde die Labormeldung publiziert. Folgend wurde die Arztmeldung fachlich ausgearbeitet und da es sowohl fachlich und auch aus Gründen des Investitionsschutzes für Softwarehersteller sinnvoll ist beide Meldungen auf den gleichen Grundlagen aufzubauen, wurde die Arztmeldung mit der Version 2 integriert. Die vorliegende Version beinhaltet somit sowohl die Labor- als auch die Arztmeldung. Die jeweils notwendigen Teile sind im Leitfaden entsprechend beschrieben und gekennzeichnet.

Dieses Dokument spezifiziert den Aufbau einer Labor- bzw. Arztmeldung an das epidemiologische Meldesystem des für Gesundheit zuständige Bundesministeriums. Die Strukturvorgaben in dieser Spezifikation sind z.T. generisch. Dies trifft im Speziellen die EMS Parameter welche für die Labormeldung benötigt werden. Welche Parameter für welche zu meldende Krankheit herangezogen werden können bzw. müssen ist NICHT in diesem Leitfaden geregelt. Die Information hierzu finden Sie im vom für Gesundheit zuständigen Bundesministeriums veröffentlichen XML-Dokument


Hinweis:
Sollten Sie beobachten, dass Divergenzen zwischen den Inhalten am Terminologieserver und dem XML-Dokument des Bundesministeriums bestehen, bitte diese an cda@technikum-wien.at melden. Weiters zu beachten: Der Datenimport des Bundesministeriums basiert auf den Daten im XML-Dokument. Somit ist davon auszugehen, dass das XML-Dokument den aktuelleren Datenstand besitzt


Der gegenständlich Implementierungsleitfaden versucht weitestgehend schon in ELGA definierte Bestandteile (templates) wiederzuverwenden. Zu beachten ist, dass eventuell nicht alle Inhaltselemente vom EMS benötigt werden.


2.1 Impressum

Medieneigentümer, Herausgeber, Hersteller, Verleger:
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: 01. 2127050.
Internet: www.elga.gv.at Email: cda@elga.gv.at.
Geschäftsführer: DI Dr. Günter Rauchegger, DI(FH) Dr. Franz Leisch

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

Abbildungen: © ELGA GmbH

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

Download unter www.gesundheit.gv.at und www.elga.gv.at/cda

2.2 Haftungsausschluss

Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht. Die ELGA GmbH weist ausdrücklich darauf hin, dass es sich bei dem vorliegenden Leitfaden um unverbindliche Arbeitsergebnisse handelt, die zur Anwendung empfohlen werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls unerwünscht und von den Erstellern des Dokumentes nicht beabsichtigt.

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

2.3 Sprachliche Gleichbehandlung

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

2.4 Lizenzinformationen

Die von HL7 Austria erarbeiteten Standards und die Bearbeitungen der Standards von HL7 International stellen Werke im Sinne des österreichischen Urheberrechtsgesetzes dar und unterliegen daher urheberrechtlichem Schutz.

HL7 Austria genehmigt die Verwendung dieser Standards 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.

Die vollständige oder teilweise Veröffentlichung der Standards (zum Beispiel in Spezifikationen, Publikationen oder Schulungsunterlagen) ist nur mit einer ausdrücklichen Genehmigung der HL7 Austria gestattet. Mitglieder von HL7 Austria sind berechtigt, die Standards vollständig oder in Auszügen ausschließlich organisationsintern zu publizieren, zu vervielfältigen oder zu verteilen. Die Veröffentlichung eigener Anpassungen der HL7-Spezifikationen (im Sinne von Lokalisierungen) oder eigener Leitfäden erfordert eine formale Vereinbarung mit der HL7 Austria.

Die vollständigen Lizenzinformationen finden sich unter https://hl7.at/nutzungsbedingungen-und-lizenzinformationen/

Die Lizenzbedingungen von HL7 International finden sich unter http://www.HL7.org/legal/ippolicy.cfm

2.5 Verwendete Grundlagen und Bezug zu anderen Standards

Zu beachten ist, dass der vorliegende Leitfaden unter Verwendung der nachstehend beschriebenen Dokumente erstellt wurde. Das Urheberrecht an allen genannten Dokumenten wird im vollen Umfang respektiert.

Dieser Leitfaden basiert auf Inhalten des Implementierungsleitfaden für ELGA Laborbefunde Version 2.0 (ELGA Homepage) und damit implizit auf dem Allgemeinen Implementierungsleitfaden für CDA Dokumente im österreichischen Gesundheitswesen. Zum einfacheren Verständnis werden CDA-Strukturbeispiele, inhaltliche Spezifikationen sowie Beschreibungen aus dem Allgemeinen Implementierungsleitfaden übernommen und in diesem Leitfaden angeführt.

Teile dieses Leitfadens beruhen auf der Spezifikation "HL7 Clinical Document Architecture, Release 2.0", für die das Copyright © von Health Level Seven International gilt. HL7 Standards können über die HL7 Anwendergruppe Österreich, die offizielle nationale Gruppierung von Health Level Seven International in Österreich, bezogen werden (HL7 Austria). Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifkationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.

Der vorliegende Leitfaden in der Version 2.x umfasst sowohl die Labormeldung als auch die Arztmeldung. Er beruht auf den Definitionen des Allgemeinen Implementierungsleitfaden für ELGA CDA Dokumente[1] und insbesondere auf dem ELGA Implementierungsleitfaden „HL7 Implementation Guide for CDA® R2: Laborbefund“ zur Anwendung im österreichischen Gesundheitswesen[2], welcher wiederum auf Basis der internationalen Definitionen der IHE (Integrating the Healthcare Enterprise) erstellt wurde [3]. Unbeschadet der Tatsache, dass eine EMS Meldung natürlich kein Befund ist, beruhen doch beide Dokumente auf der gleichen Datenbasis eines Labors und die Darstellung in CDA Dokumenten mit gleichen Strukturen und zumindest teilweisen semantischen Inhalten erleichtert die Umsetzung für die Softwarehersteller. Es zeigt sich jedoch, dass die elektronische Meldung meldepflichtiger Krankheiten zum einen durchaus einen Bedarf an zusätzlichen Spezialdaten (z.B. geografische Informationen) aufweist und zum anderen die Anforderung an die Darstellung natürlich von denen eines Befundes abweichen. Daher schränkt vorliegender Leitfaden die bestehenden Definitionen weiter ein bzw. erweitert diese um entsprechende Teile zur Abbildung der Spezifika der EMS Meldung. Insbesondere betrifft das die in Tabelle 1 dargestellten Daten. Die entsprechende ELGA Kompatibilität ist in den jeweiligen Kapiteln angegeben. Der tatsächliche Inhalt und Umfang der EMS Meldung ist abhängig vom Typ der Meldung (Labor oder Arzt) und vom gemeldeten Erreger bzw. der gemeldeten Krankheit. Grundsätzlich immer verpflichtend zu übermitteln sind somit gefundene Erreger bzw. dadurch ausgelöste Krankheiten. Davon ausgehend ergeben sich unter Umständen zusätzliche verpflichtende Daten (siehe Kapitel Übersicht über die medizinischen Inhalte (CDA-Body)). Weitere Daten können jederzeit optional im Dokument enthalten sein.

3 Einleitung

3.1 Ausgangslage und Motivation

Um die EU-weite Situation betreffend Infektionskrankheiten realistisch darzustellen, ist es notwendig, vergleichbare Daten zu sammeln. Daher wurden Falldefinitionen entwickelt und im Rahmen einer Entscheidung der Kommission verbindlich festgelegt. Die Implementierung dieser Falldefinitionen bedeutete für viele EU-Länder eine Änderung des Meldesystems, da die Übermittlung von aggregierten Daten nicht mehr ausreicht und somit Einzelfallmeldungen erforderlich sind. Die ideale Lösung zur Akzeptanz dieser Systemumstellung war die gleichzeitige Implementierung eines elektronischen Meldesystems. Der Aufbau eines „Epidemiologischen Meldesystems“ (EMS) war außerdem notwendig, um ein automationsunterstütztes einheitliches Meldewesen der zuständigen Behörden für die epidemiologische Überwachung, Prävention und Bekämpfung von übertragbaren Krankheiten beim Menschen gewährleisten zu können. Die Notwendigkeit des einheitlichen Meldewesens ergab sich aufgrund der Anforderungen nachfolgender Organisationen bzw. Institutionen

  • Vollziehende Bezirksverwaltungsbehörden
  • Landes- und Bundesgesundheitsbehörden
  • Nationale Referenzzentralen

und der legistischen Vorgaben der

  • EU
  • Weltgesundheitsorganisation (WHO)
  • Des für Gesundheit zuständige Bundesministerium

Vom für Gesundheit zuständige Bundesministerium wurde bereits ein entsprechendes Pflichtenheft erstellt, welches die Anforderungen und den Umfang der Konzeption sowie der Umsetzung für ein „Epidemiologisches Meldesystem“ festlegt. Mit diesem „Epidemiologischen Meldesystem“ ist es möglich, auf elektronischem Wege Meldungsdaten zu erfassen, zu verwalten und in geeigneter Form wieder zur Verfügung zu stellen

4 Harmonisierung

4.1 Autoren und Mitwirkende

Der vorliegende Leitfaden wurde unter der Leitung der Fachhochschule Technikum Wien erstellt und Inhalte dieses Leitfadens wurden gemeinsam mit ELGA GmbH an bestehende und künftige andere Leitfäden angegelichen. Vom für Gesundheit zuständigen Bundesministeriums wurde die Erstellung des Leitfadens durch Herrn Dr. Weninger und Herrn Pokorny begleitet.

4.1.1 Autoren

Das Redaktionsteam bestand aus folgenden Personen:

Name Organisation Rolle
FH-Prof. Matthias Frohner PhD, MSc Fachhochschule Technikum Wien Autor
FH-Prof. DI Alexander Mense Fachhochschule Technikum Wien Autor
Nikolaus Krondraf, BSc Technikum Wien GmbH Autor
Mag. Dr. Stefan Sabutsch ELGA GmbH, HL7 Austria Autor

5 Funktionale Anforderungen

5.1 Darstellung

Die gegenständliche Spezifikation, basierend auf den aus den Use-cases abgeleiteten Anforderungen, hat KEINE Anforderungen bezüglich der Bildschirmdarstellung, da eine "menschliche" Betrachtung des Dokuments (auf Empfängerseite) nicht vorgesehen ist. Die allgemeine Anforderungen, dass maschinenlesbare Inhalte auch menschenlesbar sein soll, ist zu beachten. Jedoch gibt es keine formalen Anforderungen bezüglich der Strukturierung und Darstellung der Inhalte.

Es wird empfohlen, dass der Level 2 Text (section/text) mit Hilfe zur Verfügung stehender Formatierungswerkzeuge (z.B.: paragraph) strukturiert wird. Hierzu kann die grobe Struktur des CDA-Bodys, wie in Kapitel Übersicht über die medizinischen Inhalte (CDA-Body) ersichtlich, herangezogen werden.

5.2 Dokumenten-Metadaten (XDS-Metadaten)

Arzt und Labormeldungen im Kontext des epidemiologischen Meldesystems werden zum jetzigen Zeitpunkt NICHT in die ELGA – Infrastruktur oder ein anderes IHE XDS-basierendes Gesamtsystem eingebracht. Die EMS Meldung wird gerichtet an das für Gesundheit zuständige Bundesministerium übermittelt. Hierbei folgt es jedoch NICHT vorhanden IHE Spezifikationen für den gerichteten Dokumentenaustausch (IHE XDR) und es werden KEINE Metadaten benötigt (weder für eine Registrierung noch für eine maschinelle Interpretation eines dezidierten Empfängers).

Sollten dieser Leitfaden Angaben zum Mapping der CDA Daten in die XDS-Metadaten enthalten, ist dies der Tatsache geschuldet, dass Element (inkl. deren Beschreibung) aus dem ELGA Kontext wiederverwendet werden. Für die Implementierung einer EMS Arzt- bzw. Labormeldung können diese ignoriert werden.

6 User Storys ("Anwendungsfälle")

6.1 Anwendungsfall EMS01: Labormeldung "automatische Schnittstelle"

  • In einer Laborprobe wird ein meldepflichtiger Keim gefunden
  • Labor: Datenaufbereitung durch die Labor-EDV: Erzeugen des CDA-Dokuments

Labor: Automatisierte Übermittlung des erzeugten CDA-Dokuments (mit vorheriger Authentifizierung) an das entsprechende EMS-Webservice. Als Response erhält der Absender die Information ob ein neuer Fall angelegt wurde oder ob die gesendete Meldung zu einem bestehenden Fall hinzugefügt wurde sowie die Fall-Id.

  • EMS-Webservice: Übernahme der Daten mit Datenprüfung
  • Weiterverarbeitung der Daten:
    • Labormeldung generieren
    • Fall anlegen oder bestehenden Fall ergänzen
    • EMS: Ggf. Signalisierung
    • EMS: Ggf. Nachbearbeitung durch Bearbeiter (zuständiges Ministerium) bzw. Bezirksverwaltungsbehörde

6.2 Anwendungsfall EMS02: Labormeldung "Gatewayapplikation"

Die Gateway-Applikation dient zum Erfassen von Labormeldungen in einem Web-GUI und anschließender Übermittlung der Daten in Form von CDA-Dokumenten an das EMS-Interface. D.h. die GA verwendet dieselbe Schnittstelle wie Laborsysteme.

  • Labor: Authentifizierung, Identifikation: Entspricht einem Login des Labors an der Applikation.
  • Labor: Erfassen einer Labormeldung durch den User über ein Web-GUI, bestehend aus folgenden Schritten:
    • Eingabe der Kopfdaten der Meldung: Dokumenten-ID, Datum, Patientendaten, Daten zu „Author“, „Informant“, „Custodian“ und „Authenticator“
    • Auswahl der zu meldenden Erkrankung
    • Erfassung der krankheitsspezifischen Datenfelder
  • Gateway-Applikation: Aus den eingegebenen Daten wird durch die Gateway-Applikation ein CDA-Dokument generiert und an das EMS übermittelt
  • EMS-Webservice: Übernahme der Daten mit Datenprüfung
  • Weiterverarbeitung der Daten:
    • Labormeldung generieren
    • Fall anlegen oder bestehenden Fall ergänzen
    • EMS: Ggf. Signalisierung
    • EMS: Ggf. Nachbearbeitung durch Bearbeiter (zuständiges Ministerium) bzw. Bezirksverwaltungsbehörde

6.3 Anwendungsfall EMS03: Labormeldung Referenzlabor

  • Labor: Datenaufbereitung durch die Labor-EDV: Erzeugen des CDA-Dokuments
  • Labor: Automatisierte Übermittlung des erzeugten CDA-Dokuments (mit vorheriger Authentifizierung) an das entsprechende EMS-Webservice.
  • EMS-Webservice: Übernahme der Daten mit Datenprüfung
  • Weiterverarbeitung der Daten:
    • Labormeldung generieren
    • Fall anlegen
    • Auftrag an Referenzlabor mit Fall-Id
  • Referenzlabor: führt erneuten Test durch
  • Referenzlabor: erstellt Befund und übermittelt diesen inkl. bekannter Fall-Id

6.4 Anwendungsfall EMS04: Labormeldung behördlich angeordneter Untersuchungsauftrag

  • Labor: Erhält Untersuchungsauftrag inklusive Probe und Fall-Id und führt den Auftrag laut Anforderung aus
  • Labor: Datenaufbereitung und Erzeugung des CDAs mit der erhaltenden Fall-Id und übermittelt dieses an das entsprechende EMS-Webservice
  • EMS-Webservice: Übernahme der Daten mit Datenprüfung
  • Weiterverarbeitung der Daten
    • Anhand der empfangenen Fall-Id Zuweisung zu einem bestehenden Fall

6.5 Anwendungsfall EMS05: Labormeldung Folgemeldung

Im Zuge der Meldung an das epidemiologische Meldesystem werden nur abgeschlossene Analysen übermittelt, i.e. sollte ein Ergebnis noch ausständig sein, kann dieses in Form einer Folgemeldung nachgereicht werden. Das Labor hat zu einem früheren Zeitpunkt schon eine Meldung an das EMS geschickt und hat im Zuge der Übermittlung die Fall-Id erhalten (Anwendungsfall EMS01) und diese lokal verspeichert.

  • Labor: Datenaufbereitung und Erzeugung des CDAs mit der erhaltenden Fall-Id und übermittelt dieses an das entsprechende EMS-Webservice
  • EMS-Webservice: Übernahme der Daten mit Datenprüfung
  • Weiterverarbeitung der Daten
    • Anhand der empfangenen Fall-Id Zuweisung zu einem bestehenden Fall

6.6 Anwendungsfall EMS06: Arztmeldung automatisiert intramural

  • Ein Arzt stellt bei einem Patienten, der intramural ambulant oder stationär behandelt wird eine meldepflichtige Erkrankung fest oder hat einen begründeten Verdacht auf eine solche.
  • Der Arzt erfasst die erforderlichen Daten im Krankenhausinformationssystem.
  • Datenaufbereitung durch Krankenhausinformationssystem: Erzeugen des CDA-Dokuments und automatisierte Übermittlung des erzeugten CDA-Dokuments (mit vorheriger Authentifizierung) an das entsprechende EMS-Webservice (analog Anwendungsfall EMS01). Als Response erhält der Absender die Information ob ein neuer Fall angelegt wurde oder ob die gesendete Meldung zu einem bestehenden Fall hinzugefügt wurde sowie die Fall-Id.
  • EMS-Webservice: Übernahme der Daten mit Datenprüfung
  • Weiterverarbeitung der Daten:
    • Labormeldung generieren
    • Fall anlegen oder bestehenden Fall ergänzen
    • EMS: Ggf. Signalisierung
  • EMS: Ggf. Nachbearbeitung durch Bearbeiter (zuständiges Ministerium) bzw. Bezirksverwaltungsbehörde

6.7 Anwendungsfall EMS07: Arztmeldung automatisiert niedergelassener Bereich

  • Ein niedergelassener Arzt stellt bei einem Patienten eine meldungspflichtige Erkrankung fest oder hat einen begründeten Verdacht auf diese
  • Der Arzt erfasst die erforderlichen Daten über ein entsprechendes Eingabeformular im Arztpraxis-Informationssystem
  • Datenaufbereitung durch Arztpraxis-Informationssystem: Erzeugen des CDA-Dokuments und automatisierte Übermittlung des erzeugten CDA-Dokuments (mit vorheriger Authentifizierung) an das entsprechende EMS-Webservice. Als Response erhält der Absender die Information ob ein neuer Fall angelegt wurde oder ob die gesendete Meldung zu einem bestehenden Fall hinzugefügt wurde sowie die Fall-Id.
  • EMS-Webservice: Übernahme der Daten mit Datenprüfung
  • Weiterverarbeitung der Daten:
    • Arztmeldung generieren
    • Fall anlegen oder bestehenden Fall ergänzen
    • EMS: Ggf. Signalisierung
    • EMS: Ggf. Nachbearbeitung durch Bearbeiter (zuständiges Ministerium) bzw. Bezirksverwaltungsbehörde

6.8 Anwendungsfall EMS08: Arztmeldung "Gatewayapplikation"

Die Gateway-Applikation (GA) dient zum Erfassen von Arztmeldungen in einem Web-GUI und anschließender Übermittlung der Daten in Form von CDA-Dokumenten an das EMS-Interface. D.h. die GA verwendet dieselbe Schnittstelle wie die Primärinformationssysteme (Arzt- bzw. Krankenhausinformationssystem).

  • Arzt stellt bei einem Patienten eine meldungspflichtige Erkrankung fest oder hat einen begründeten Verdacht auf diese.
  • Arzt ruft die Gatewayapplikation auf bzw. die GA wird aus dem Primärsystem aufgerufen – Authentifizierung des GDA und Arztes.
  • Arzt: Erfassen einer Arztmeldung durch den User über ein Web-GUI, bestehend aus folgenden Schritten:
    • Eingabe der Kopfdaten der Meldung: Dokumenten-ID, Datum, Patientendaten, Daten zu „Author“, „Informant“, „Custodian“ und „Authenticator“
    • Auswahl der zu meldenden Erkrankung
    • Erfassung der krankheitsspezifischen Datenfelder
  • Gateway-Applikation: Aus den eingegebenen Daten wird durch die Gateway-Applikation ein CDA-Dokument generiert und an das EMS übermittelt
  • EMS-Webservice: Übernahme der Daten mit Datenprüfung
  • Weiterverarbeitung der Daten:
    • Arztmeldung generieren
    • Fall anlegen oder bestehenden Fall ergänzen
    • EMS: Ggf. Signalisierung
    • EMS: Ggf. Nachbearbeitung durch Bearbeiter (zuständiges Ministerium) bzw. Bezirksverwaltungsbehörde

7 Technische Spezifikation

7.1 Übersicht CDA Strukturen (Header & Body)

Folgende informative Tabelle stellt die relevanten Informationselement und Inhalte dar welche im Zuge einer Labor- oder Arztmeldung dar.

Feld Beschreibung Labor Arzt Bereich
Allgemeine Befundinformation
Eindeutige Befundnummer eindeutige Befundenummer welche vom Ersteller des Dokuments generiert wird X X Header
Meldendes Labor Identifikation des meldungerstellenden Labors X Header
Empfänger Betreiber des EMS (in der Regel das für Gesundheit zuständige Bundesministerium) X X Header
Meldungsrelevante Ergebnisse und Inhalte
Fall-Id Identifikation eines Falles laut EMS X X Body
EMS Parameter Parameter welche im Rahmen einer EMS Meldung benötigt werden jedoch nicht in der Struktur des ELGA Laborbefundes abgebildet werden können (z.B. Angabe ob es sich um ein Erstisolat handelt). Observations entsprechend den „Analysen“ im Laborbefund. X X Body
Meldepflichtiger Erreger Bei Laboruntersuchungen gefundener meldepflichtiger Erreger X Body
Meldepflichtige Krankheit Durch meldepflichtigen Erreger ausgelöste Erkrankung X X Body
Todesdatum Angaben zum Todesdatum X Header
Hospitalisierung Angaben zur (geplanten) Hospitalisierung des Patienten/der Patientin X Body
Klinische Manifestation Angaben zur klinischen Manifestation X Body
Tätigkeitsbereich Angabe zum (beruflichen) Tätigkeitsbereichs des Patienten/der Patientin X Body
Impfungen Angabe zu Impfungen bei impfpräventablen Krankheiten X Body
Bakteriologische Ergebnisse
Analysen X Body
Erreger X Body
Antibiotischer Wirkstoff X Body
Resistenzkennung Codierte Bewertung der Resistenz (R,S,I) X Body

7.1.1 Übersicht über die administrativen Daten (CDA-Header-Elemente)

Die nachfolgende Tabelle liefert einen Überblick über die CDA-Elemente, welche für die entsprechende Meldung benötigt werden. Sollten die gelisteten CDA-Elementen keinen, durch diesen Leitfaden spezifizierten Einschränkungen unterliegen, können Details dem Allgemeinen Implementierungsleitdafen für ELGA CDA Dokumente [1] entnommen werden.

Feld Element Optionalität
Labor Arzt
Daten zum Dokument
Realm Code ClinicalDocument/realmCode M

[1..1]

Dokumentenformat ClinicalDocument/typeId M

[1..1]

Template ClinicalDocument/templateId M

[3..3]

Dokumenten-ID ClinicalDocument/id M

[1..1]

Dokumentenklasse ClinicalDocument/code M

[1..1]

Dokumenttitel ClinicalDocument/title M

[1..1]

Dokumentdatum ClinicalDocument/effectiveTime M

[1..1]

Vertraulichkeitscode ClinicaDocument/confidentialityCode M

[1..1]

Sprachcode ClinicalDocument/languageCode M

[1..1]

Versionierung des Dokuments ClinicalDocument/setId
ClinicalDocument/versionNumber
M

[1..1]

Teilnehmende Parteien
Patient ClinicalDocument/recordTarget M

[1..1]

Patient lebt betreut ClinicalDocument/recordTarget/patientRole/addr@use="TMP" O

[0..1]

R

[0..1]

Verfasser des Dokuments ClinicalDocument/author M

[1..1]

Verwalter des originalen Dokuments ClinicalDocument/custodian M

[1..1]

Rechtlicher Unterzeichner ClinicalDocument/legalAuthenticator M

[1..1]

Validatoren ClinicalDocument/authenticator O

[0..*]

Vorgesehener Empfänger ClinicalDocument/informationRecipient M

[1..1]

Referenz zum Auftrag
Einsender ClinicalDocument/participant@typeCode=“REF“ M

[1..1]

NP

[0..0]

Auftragsidentifikation ClinicalDocument/inFulfillmentOf/order M

[1..1]

NP

[0..0]

Dokumentation der Gesundheitsdienstleistung
Service Events ClinicalDocument/documentationOf/serviceEvent M

[2..2]

Meldendes Labor ClinicalDocument/documentationOf/

serviceEvent[0]/performer

M

[1..1]

NP

[0..0]

Durchführende Labors ClinicalDocument/documentationOf/

serviceEvent/performer

O

[0..*]

NP

[0..0]

7.1.1.1 Header-Elemente ohne speziellen Vorgaben

Elemente, welche für die Implementierung in einer EMS Meldung keine gesonderten Regeln benötigen, werden nach den Richtlinien und Vorschriften im Allgemeinen Implementierungsleitfaden [1] codiert. Folgende Elemente haben keine speziellen Vorgaben:

  • XML Metainformationen; Die Metainformationen codieren den verwendeten Zeichensatz sowie Information zum Stylesheet
  • Wurzelelement; Neben den XML-Wurzelelement „ClinicalDocument“ wird auch der default-Namespace definiert
  • Hoheitsbereich des Dokuments („realmCode“); Kennzeichnung aus welchem Land das Dokument stammt
  • Dokumentformat („typeId“); Kennzeichnung, dass das Dokument in CDA R2 Format vorliegt
  • Dokumenten-Id („id”); weltweit eindeutiger Identifier für das Dokument (Befundnummer)
  • Erstellungsdatum des Dokuments („effectiveTime“)
  • Vertraulichkeitscode („confidentialityCode“); Codierung der Vertraulichkeitsstufe des Do-kuments. Da die Dokumente nach ihrer Validierung nicht geändert werden dürfen können über den Vertraulichkeitscode keine Zugriffsrechte geregelt werden. Nachdem dieses Element aber ein Pflichtelement in CDA ist wird dieses Element einfach mit einem festen Code codiert
  • Sprachcode des Dokuments („languageCode“)

Elemente der Teilnehmenden Parteien ohne speziellen Vorgaben:

  • Personen bei der Dateneingabe (dataEnterer)
  • Verwahrer des Dokuments (custodian)
  • Beabsichtigte Empfänger des Dokuments(informationRecipient)
  • Rechtlicher Unterzeichner (legalAuthenticator)
  • Weitere Unterzeichner (authenticator)

7.1.2 Übersicht über die medizinischen Inhalte (CDA-Body)

Die folgende Tabelle soll einen Überblick über die verwendeten CDA Level 3 Inhalte ermöglichen. Hierbei wird zwischen den spezifischen Implementierungen für die Arztmeldungen und der Labormeldung unterschieden. Für die textuelle CDA Level 2 Darstellung (Inhalte im Element section/text) kann die vorliegende Tabelle als Strukturierungshilfe dienen. Hierzu können ELGA styleCode Attribute und html Formatierungscodes laut Allgemeinen ELGA Implementierungsleitfaden [1] genutzt werden um die gewünschte Struktur zu generieren. Weiters kann auch auf Empfehlungen bzw. Vorschriften zur textuellen Gestaltung zurückgegriffen werden, welche in anderen Leitfäden festgehalten sind (z.B.: Darstellung der Probeninformation aus dem ELGA Laborleitfaden[2]).

Zu kodierender Inhalt Body-Bereich Optionalität
Labor Arzt
Probeninformation M

[1..1]

NP

[0..0]

Krankheitserreger O

[0..1]

Krankheit M

[1..1]

Diagnosesicherheit NP

[0..0]

R

[0..1]

Weitere Krankheitsmerkmale NP

[0..0]

R

[0..2]

Angaben zum Erkrankungszeitpunkts NP

[0..0]

O

[0..1]

Todesdatum NP

[0..0]

R

[0..1]

Angaben zur Hospitalisierung NP

[0..0]

R

[0..1]

Angaben zum Tätigkeitsbereichs NP

[0..0]

R

[0..1]

Symptome NP

[0..0]

O

[0..1]

Angabe zu Impfungen NP

[0..0]

R

[0..1]

Analyseergebnisse M

[1..*]

NP

[0..0]

Importierte Krankheiten NP

[0..0]

R

[0..1]

Krankheitsüberträger NP

[0..0]

R

[0..1]

Weitere EMS spezifischen Parameter R

[0..*]

7.1.2.1 Aufbau der EMS Labormeldung

  • Die Meldung beinhaltet genau eine Sektion
  • Informationen zu der Probe sind in dieser Sektion kodiert
  • Die Sektion beinhaltet verpflichtend einen "Notification organizer"
    • OPTIONAL: Mit "Notifiable Condition" = Angabe des Erregers
    • Mit "Case Identification" = Angabe der Krankheit
  • Die Sektion beinhaltet einen zusätzlichen Organizer welche das Laborergebnis/Testergebnis sowie weitere, für die Meldung relevante Parameter enthält
  • Die Sektion kann einen "Isolate Organizer" beinhalten welcher die Ergebnisse eines Antibiogramm und einer Bestimmung der minimalen Hemmkonzentration beinhalten kann

7.1.2.2 Aufbau der EMS Arztmeldung

  • Die Meldung beinhaltet genau eine Sektion
  • Die Sektion beinhaltet verpflichtend einen "Notification organizer"
    • OPTIONAL: Mit "Notifiable Condition" = Angabe des Erregers
    • Mit "Case Identification" = Angabe der Krankheit

7.1.2.3 Der EMS Organizer

Aufgrund der Tatsache, dass sich die Struktur und die CDA Umsetzung der EMS Meldungen an dem Implementierungsleitfaden für ELGA Laborbefunde orientiert gibt es für die Meldung relevante Informationen welche nicht durch einen Laborbefund abgedeckt wird. Aus diesem Grund wird eine eigene Befundgruppe (umgesetzt mit Hilfe des CDA-Organizer-Elements) eingeführt, mit Hilfe derer Informationen, welche nicht in anderen Laborsektionen unterge-bracht werden können, codiert werden können. In diese Gruppe können EMS spezifische Parameter maschinenlesbar codiert werden.

7.2 CDA Templates

7.2.1 Header Templates

7.2.1.1 Document Realm

Id1.2.40.0.34.6.0.11.1.10
ref
at-cda-bbr-
Gültigkeit2019‑02‑12 13:35:45
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_DocumentRealmAnzeigenameDocument Realm
BeschreibungHoheitsbereich des Dokuments.

Dieses Element kennzeichnet, dass das Dokument aus dem Hoheitsbereich Österreich (bzw. Bereich der HL7 Affiliate Austria, Code „AT“) stammt.
KlassifikationCDA Header Level Template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
Beispiel
Strukturbeispiel
<realmCode code="AT"/>
ItemDTKardKonfBeschreibungLabel
hl7:realmCode
CSR Hoheitsbereich des Dokuments.

Fester Wert: @code = AT
(aus ValueSet „ELGA_RealmCode“)
(atc...alm)
Treetree.png@code
1 … 1FAT


7.2.1.2 Document TypeId

Id1.2.40.0.34.6.0.11.1.30
ref
at-cda-bbr-
Gültigkeit2019‑05‑13 10:27:22
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_DocumentTypeIdAnzeigenameDocument TypeId
BeschreibungDieses Element kennzeichnet, dass das Dokument im Format CDA R2 vorliegt.
KlassifikationCDA Header Level Template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
Beispiel
Strukturbeispiel
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
ItemDTKardKonfBeschreibungLabel
hl7:typeId
IIRDokumentformat CDA R2
(atc...eId)
Treetree.png@root
uid1 … 1F2.16.840.1.113883.1.3
Treetree.png@extension
st1 … 1FPOCD_HD000040


7.2.1.3 Document Id

Id1.2.40.0.34.6.0.11.1.1
ref
at-cda-bbr-
Gültigkeit2019‑02‑18 11:06:14
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_DocumentIdAnzeigenameDocument Id
Beschreibung
Die Dokumenten-Id eines CDA-Dokuments ist ein eindeutiger Instanzidentifikator, der das Dokument weltweit und für alle Zeit eindeutig identifiziert. Ein CDA-Dokument hat genau eine Id.
↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut uniqueId gemappt.
KlassifikationCDA Header Level Template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
Beispiel
Strukturbeispiel (mit Extension)
<id assigningAuthorityName="Amadeus Spital" root="1.2.40.0.34.99.111.1.1" extension="134F989"/>
Beispiel
Strukturbeispiel (ohne Extension)
<id assigningAuthorityName="Amadeus Spital" root="1.2.40.0.34.99.111.1.1.20248969"/>
ItemDTKardKonfBeschreibungLabel
hl7:id
II1 … 1MDokumenten-Id des CDA-Dokuments.
Es MUSS eine gültige und innerhalb des ID-Pools eindeutige Dokumenten-ID angegeben werden.

Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen.
(atc...tId)
Treetree.png@root
uid1 … 1R


7.2.1.4 Document Effective Time

Id1.2.40.0.34.6.0.11.1.11
ref
at-cda-bbr-
Gültigkeit2019‑02‑12 16:30:12
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_DocumentEffectiveTimeAnzeigenameDocument Effective Time
Beschreibung
Dokumentiert das Erstellungsdatum bzw. den Zeitpunkt, an dem das Dokument inhaltlich fertiggestellt wurde. Damit ist jenes Datum gemeint, welches normalerweise im Briefkopf eines Schriftstückes angegeben wird (z.B. Wien, am …). Das Erstellungsdatum des Dokuments muss nicht mit dem Datum der rechtlichen Unterzeichnung (oder „Vidierung“) übereinstimmen.

↔ Hinweis zum XDS-Mapping: Dieses Element wird in das XDS-Attribut XDSDocumentEntry.creationTimegemappt (sofern es sicht nicht um ein On-Demand Document Entry handelt).

Verweis auf speziellen Implementierungsleitfaden: Für das Erstellungsdatum ist das medizinisch zutreffendste Datum anzugeben, dieses muss für jede einzelne Dokumentenklasse im speziellen Leitfaden separat definiert werden.
Begründung: Das Erstellungsdatum wird für die Sortierung der Befunde im Dokumentenregister (XDSDocumentEntry-Metadaten) verwendet. Es muss also sichergestellt werden, dass die Befunde in der Reihenfolge sortiert werden, wie sie in einer Krankenakte sortiert werden. 
Beispiel: Laborbefunde müssen nach dem Probenentnahmedatum sortiert werden (NICHT nach dem Vidierdatum), Radiologiebefunde nach dem Ende der Bildaufnahme (NICHT nach dem Befundungszeitpunkt).
KlassifikationCDA Header Level Template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
at-cda-bbr-data​element-11Kyellow.png Erstellungsdatum Kyellow.png Dataset A 2019
BeziehungVersion: Template 1.2.40.0.34.11.90008 CD effectiveTime (2016‑07‑21)
ref
elgabbr-
Beispiel
Nur Datum: Zeitpunkt als Datum (ohne Zeit) im Format YYYYMMDD
<effectiveTime value="20190606"/>
Beispiel
Datum, Zeit und Zeitzone: Zeitpunkt als Datum mit Zeit und Zeitzone im Format YYYYMMDDhhmmss[+/-]HHMM
<effectiveTime value="20190606134038+0200"/>
ItemDTKardKonfBeschreibungLabel
hl7:effectiveTime
TS.AT.TZR
Relevantes Datum des Dokuments.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
(atc...ime)
 
Target.png
at-cda-bbr-data​element-11Kyellow.png Erstellungsdatum Kyellow.png Dataset A 2019


7.2.1.5 Document Confidentiality Code

Id1.2.40.0.34.6.0.11.1.12
ref
at-cda-bbr-
Gültigkeit2019‑03‑04 12:35:46
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_DocumentConfidentialityCodeAnzeigenameDocument Confidentiality Code
Beschreibung
Grundsätzlich stellt CDA Informationen zum Vertraulichkeitsstatus eines Dokuments zur Verfügung, um Anwendungssysteme bei der Verwaltung des Zugriffs auf sensible Daten zu unterstützen. Der Vertraulichkeitsstatus kann für das gesamte Dokument oder für bestimmte Teile des Dokuments gelten. Der im Header angegebene Wert gilt für das gesamte Dokument, es sei denn, er wird durch einen verschachtelten Wert überschrieben. Der tatsächliche Zugriff auf das Dokument muss von der übergeordneten Infrastrukturschicht geregelt werden, der Vertraulichkeitscode im Dokument selbst ist daher rein informativ.
↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut confidentialityCode gemappt.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
at-cda-bbr-data​element-13Kyellow.png Vertraulichkeitscode Kyellow.png Dataset A 2019
BeziehungVersion: Template 1.2.40.0.34.11.90009 CD confidentialityCode (2013‑11‑07)
ref
elgabbr-
Beispiel
Strukturbeispiel
<confidentialityCode codeSystemName="HL7:Confidentiality" code="N" codeSystem="2.16.840.1.113883.5.25" displayName="normal"/>
ItemDTKardKonfBeschreibungLabel
hl7:confidentialityCode
CEVertraulichkeitscode des Dokuments aus ValueSet „ELGA_Confidentiality“
(atc...ode)
 
Target.png
at-cda-bbr-data​element-13Kyellow.png Vertraulichkeitscode Kyellow.png Dataset A 2019
Treetree.png@codeSystemName
st1 … 1FHL7:Confidentiality
 ConstraintFür ELGA-Leitfäden ist ausschließlich "N" erlaubt!


7.2.1.6 Document Language

Id1.2.40.0.34.6.0.11.1.13
ref
at-cda-bbr-
Gültigkeit2019‑02‑12 14:08:58
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_DocumentLanguageAnzeigenameDocument Language
Beschreibung
Gibt die Sprache des Dokuments an, sowohl in Inhalts- oder Attributwerten. Die Angabe erfolgt im Sprachcode-Attribut gemäß IETF RFC 3066 (Internet Engineering Task Force RFC 3066 for the Identification of Languages, ed. H. Alvestrand 1995).
Es enthält mindestens eine Sprachencode gemäß ISO 639 ("Code for the representation of names of languages") und einen optionalen Ländercode gemäß ISO 3166 alpha-2.
Syntax: Vereinfacht folgt der LanguaceCode dem Format ll-CC, wobei ll dem Sprachencode gemäß ISO-639-1 in Kleinbuchstaben folgt und CC dem Ländercode gemäß ISO 3166 (Tabelle mit zwei Zeichen) in Großbuchstaben. Trennzeichen ist der Bindestrich (UTF-8 "Hyphen-Minus" mit Kode 45 (dezimal) bzw. 2D (hexadezimal)).
↔ Hinweis zum XDS-Mapping:
Dieses Element wird ins XDS-Attribut languageCode gemappt.
KlassifikationCDA Header Level Template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
at-cda-bbr-data​element-14Kyellow.png Sprachcode Kyellow.png Dataset A 2019
BeziehungVersion: Template 1.2.40.0.34.11.90010 CD languageCode (2013‑11‑07)
ref
elgabbr-
Beispiel
Strukturbeispiel
<languageCode code="de-AT"/>
ItemDTKardKonfBeschreibungLabel
hl7:language​Code
CS.LANGSprachcode des Dokuments.
(atc...age)
 
Target.png
at-cda-bbr-data​element-14Kyellow.png Sprachcode Kyellow.png Dataset A 2019
Treetree.png@code
cs1 … 1Fde-AT
 ConstraintIn ELGA ist in @code für CDA und Ableitungen in die XDSDocumentEntry-Metadaten ausschließlich der Wert "de-AT" zulässig.


7.2.1.7 Document Set Id and Version Number

Id1.2.40.0.34.6.0.11.1.15
ref
at-cda-bbr-
Gültigkeit2019‑02‑12 14:48:59
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_DocumentSetIdAndVersionNumberAnzeigenameDocument Set Id and Version Number
Beschreibung
Versionierung des Dokuments.
Der CDA-Header repräsentiert Beziehungen zu anderen Dokumenten mit Referenz auf die Dokumenten-Identifikation. Mittels der Attribute setId und versionNumber kann eine Versionskennung des Dokuments erreicht werden.
Für ELGA-CDA-Dokumente MÜSSEN immer beide Elemente angegeben werden.
Anhänge oder Ersetzungen von Vordokumenten MÜSSEN ebenfalls diese zusätzlichen Angaben enthalten. Der genaue Zusammenhang zwischen diesen Attributen finden Sie im Kapitel „Bezug zu vorgehenden Dokumenten“.
KlassifikationCDA Header Level Template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
BeziehungVersion: Template 1.2.40.0.34.11.90007 SetId VersionNumber (2015‑09‑18)
ref
elgabbr-
Beispiel
Beispiel für die 1.Version eines Dokuments
<!-- Die bei setId angegebene ID SOLLTE nicht gleich sein wie die id des Dokuments.-->
<placeholder>
  <id root="1.2.40.0.34.99.111.1.1" extension="AAAAAAAAAAAAAAA" assigningAuthorityName="KH Eisenstadt"/>  <setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZ" assigningAuthorityName="KH Eisenstadt"/>  <versionNumber value="1"/></placeholder>
Beispiel
Beispiel für die 2.Version eines Dokuments
<!--Die bei setId angegebene ID MUSS mit der setId der Vorversion übereinstimmen.-->
<placeholder>
  <id root="1.2.40.0.34.99.111.1.1" extension="BBBBBBBBBBBBBBB" assigningAuthorityName="KH Eisenstadt"/>  <setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZ" assigningAuthorityName="KH Eisenstadt"/>  <versionNumber value="2"/></placeholder>
ItemDTKardKonfBeschreibungLabel
hl7:setId
IIR
Eindeutige Id des Dokumentensets. Diese bleibt über alle Versionen der Dokumente gleich (initialer Wert bleibt erhalten).
Die setId SOLL unterschiedlich zur clinicalDocument.id sein.
↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut referenceIdList ("urn:elga:iti:xds:2014:ownDocument_setId") gemappt.
Hinweis: Bestimmte Systeme, die bei der Übernahme der setId in die XDS-Metadaten mit dem V2-Datentyp CX arbeiten, könnten ein Problem mit @extension-Attributen haben, die länger als 15 Zeichen sind.
(atc...ber)
hl7:versionNumber
INT.​NONNEGRVersionsnummer des Dokuments, wird bei neuen Dokumenten mit 1 festgelegt.
Die versionNumber ist eine natürliche Zahl für die fortlaufende Versionszählung. Mit einer neuen Version wird diese Zahl hochgezählt, während die setId gleich bleibt.
(atc...ber)
Treetree.png@value
int1 … 1RVersionsnummer als positive ganze Zahl.


7.2.1.8 Record Target - EMS

Id1.2.40.0.34.6.0.11.1.34Gültigkeit2020‑02‑20 09:20:38
StatusKyellow.png EntwurfVersions-Label2020
Nameepims_header_RecordTargetAnzeigenameRecord Target - EMS
Beschreibung
Das RecordTarget-Element enthält den "Patienten": Die Person, die von einem Gesundheitsdiensteanbieter (Arzt, einer Ärztin oder einem Angehörigen anderer Heilberufe) behandelt wird und über die bzw. über deren Gesundheitsdaten im Dokument berichtet wird.


Laut Allgemeinen ELGA Implementierungsleitfaden ist es möglich, dass mehrere Vornamen eines Patienten/einer Patientin in einzelnen <given>-Tags codiert werden. Aufgrund der Tatsache, dass die Reihenfolge dieser Elemente nicht überprüft werden kann, könnte es vorkommen dass aus z.B.: „Hans Peter“ „Peter Hans“ werden kann. Dieser Umstand erschwert den Abgleich der Personendaten mit den Daten des Zentralen Melderegisters. Daher ist im Falle einer EMS Meldung nur ein <given>-Tag erlaubt (dies kann jedoch auch „Hans Peter“ beinhalten).

   


KlassifikationCDA Header Level Template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
Benutzt
Benutzt 6 Templates
Benutzt als NameVersion
1.2.40.0.34.6.0.11.9.25ContainmentKyellow.png Address Compilation (2019)DYNAMIC
1.2.40.0.34.6.0.11.9.38ContainmentKyellow.png Person Name Compilation G2 M - EMS (2020)DYNAMIC
1.2.40.0.34.6.0.11.9.12ContainmentKyellow.png Person Name Compilation G1 M (2019)DYNAMIC
1.2.40.0.34.6.0.11.9.11ContainmentKyellow.png Person Name Compilation G2 M (2019)DYNAMIC
1.2.40.0.34.6.0.11.9.27ContainmentKyellow.png Organization Name Compilation (2019)DYNAMIC
1.2.40.0.34.6.0.11.9.10ContainmentKyellow.png Address Compilation Minimal (2019)DYNAMIC
BeziehungSpezialisierung: Template 1.2.40.0.34.6.0.11.1.3 Record Target (2019‑02‑20 12:10:02)
ref
at-cda-bbr-

Spezialisierung: Template 2.16.840.1.113883.10.12.101 CDA recordTarget (2005‑09‑07)
ref
ad1bbr-
Beispiel
Strukturbeispiel
<hl7:recordTarget typeCode="RCT" contextControlCode="OP">
  <hl7:patientRole classCode="PAT">
    <hl7:id root="1.2.3.999" extension="--example only--"/>    <hl7:addr>
      <!-- template 1.2.40.0.34.6.0.11.9.25 'Address Compilation' (2019-02-28T14:24:14) -->
    </hl7:addr>
    <hl7:telecom value="--TODO--" use="cs"/>    <hl7:patient>
      <!-- choice: 1..1
element hl7:administrative​Gender​Code[not(@nullFlavor)]
element hl7:administrative​Gender​Code[@nullFlavor='UNK']
-->
      <!-- choice: 1..1
element hl7:birthTime
element hl7:birthTime[@nullFlavor='UNK']
-->
      <deceasedInd value="false"/>      <deceasedTime value="20200529"/>      <hl7:maritalStatusCode code="D" codeSystem="2.16.840.1.113883.5.2" codeSystemName="HL7:MaritalStatus" displayName="Divorced"/>      <hl7:religiousAffiliationCode code="100" codeSystem="2.16.840.1.113883.2.16.1.4.1" codeSystemName="HL7.AT:ReligionAustria" displayName="Katholische Kirche (o.n.A.)"/>      <hl7:guardian classCode="GUARD">
        <hl7:addr>
          <!-- template 1.2.40.0.34.6.0.11.9.25 'Address Compilation' (2019-02-28T14:24:14) -->
        </hl7:addr>
        <hl7:telecom value="value" use="cs"/>        <!-- choice: 1..1
element hl7:guardian​Person containing template 1.2.40.0.34.6.0.11.9.12 (dynamic)
element hl7:guardian​Person containing template 1.2.40.0.34.6.0.11.9.11 (dynamic)
element hl7:guardian​Organization containing template 1.2.40.0.34.6.0.11.9.27 (dynamic)
-->
      </hl7:guardian>
      <hl7:birthplace classCode="BIRTHPL">
        <hl7:place classCode="PLC" determinerCode="INSTANCE">
          <!-- choice: 1..1
element hl7:addr containing template 1.2.40.0.34.6.0.11.9.10 (dynamic)
element hl7:addr containing template 1.2.40.0.34.6.0.11.9.25 (dynamic)
-->
        </hl7:place>
      </hl7:birthplace>
      <hl7:languageCommunication>
        <hl7:languageCode code="aa"/>        <hl7:modeCode code="ESP" displayName="Expressed spoken" codeSystem="2.16.840.1.113883.5.60" codeSystemName="HL7:LanguageAbilityMode"/>        <hl7:proficiencyLevelCode code="E" displayName="Excellent" codeSystem="2.16.840.1.113883.5.61" codeSystemName="HL7:LanguageAbilityProficiency"/>        <hl7:preferenceInd value="false"/>      </hl7:languageCommunication>
      <!-- template 1.2.40.0.34.6.0.11.9.38 'Person Name Compilation G2 M - EMS' (2020-02-20T09:26:26) -->
    </hl7:patient>
  </hl7:patientRole>
</hl7:recordTarget>
ItemDTKardKonfBeschreibungLabel
hl7:recordTarget
1 … 1MKomponente für die Patientendaten.(epi...get)
Treetree.png@typeCode
cs0 … 1FRCT
Treetree.png@context​Control​Code
cs0 … 1FOP
Treetree.pnghl7:patientRole
1 … 1MPatientendaten.
(epi...get)
Treeblank.pngTreetree.png@classCode
cs0 … 1FPAT
Treeblank.pngTreetree.pnghl7:id
II2 … *RPatientenidentifikatoren(epi...get)
 Constraint
   Hinweis: Die Reihenfolge der id-Elemente MUSS unbedingt eingehalten werden!
id[1] Identifikation des Patienten im lokalen System. Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen. (1..1 M)
↔ Hinweis zum XDS-Mapping:
Das Element id[1] wird ins XDS-Attribut sourcePatientId gemappt.
   id[2] Sozialversicherungsnummer des Patienten (1..1 R):
  • @root: OID der Liste aller österreichischen Sozialversicherungen, fester Wert: 1.2.40.0.10.1.4.3.1  (1..1 M)
  • @extension: Vollständige Sozialversicherungsnummer des Patienten (10 Stellen) (1..1 M)
  • @assigningAuthorityName: Fester Wert: Österreichische Sozialversicherung (0..1 O)
Zugelassene nullFlavor:
  • NI … Patient hat keine Sozialversicherungsnummer (z.B. Ausländer)
  • UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt
   id[3] Bereichsspezifisches Personenkennzeichen, Bereichskennzeichen GH (Gesundheit) (0..1 O)
  • @root: OID der österreichischen bPK, fester Wert: 1.2.40.0.10.2.1.1.149 (1..1 M)
  • @extension: bPK-GH des Patienten: Bereichskürzel + bPK
  • Anmerkung: Das bPK dient ausschließlich der Zuordnung der elektronischen Identität und darf daher nicht am Ausdruck erscheinen (1..1 M)
  • @assigningAuthorityName: Fester Wert: Österreichische Stammzahlenregisterbehörde (0..1 O)
Treeblank.pngTreetree.pnghl7:addr
0 … 2R
Adresse des Patienten.
Es MUSS eine mögliche Adresse unterstützt werden. Im Falle, dass ein Patient/eine Patientin in einer Gemeinschaftseinrichtung/gesundheitsversorgender Einrichtung betreut wird, SOLL diese Information im Zuge der Arztmeldung angegeben werden. Hierbei MUSS ein 2tes addr-Element mit dem use-Attribute "TMP" genutzt werden.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(epi...get)
 Constraint
Werden mehrere address-Elemente strukturiert (z.B. Home, Pflege), MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *RKontakt-Element. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.
(epi...get)
Treeblank.pngTreeblank.pngTreetree.png@value
url1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom-Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß Value-Set „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreetree.png@use
cs0 … 1 
Bedeutung des angegebenen Kontakts (z.B Heim, Arbeitsplatz), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreetree.pnghl7:patient
1 … 1MName des Patienten.
Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!
Grundsätzlich sind die Vorgaben gemäß „Namen-Elemente von Personen PN“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.38 Person Name Compilation G2 M - EMS (DYNAMIC)
(epi...get)
Auswahl1 … 1
Codierung des Geschlechts des Patienten aus ValueSet "ELGA_AdministrativeGender".
Elemente in der Auswahl:
  • hl7:administrative​Gender​Code[not(@nullFlavor)]
  • hl7:administrative​Gender​Code[@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CE0 … 1(epi...get)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.1
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FHL7:AdministrativeGender
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CE0 … 1(epi...get)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Auswahl1 … 1
Geburtsdatum des Patienten.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.
Elemente in der Auswahl:
  • hl7:birthTime
  • hl7:birthTime[@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.DATE0 … 1(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.DATE0 … 1(epi...get)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treeblank.pngTreeblank.pngTreetree.pngsdtc:deceasedInd
BL0 … 1Indikator ob Patient/Patientin verstorben ist(epi...get)
Treeblank.pngTreeblank.pngTreetree.pngsdtc:deceasedTime
TS.DATE0 … 1Angabe des Sterbedatums(epi...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:marital​Status​Code
CE0 … 1RCodierung des Familienstands des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“
(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.2
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7:MaritalStatus
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.11 ELGA_MaritalStatus (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:religious​Affiliation​Code
CE0 … 1RCodierung des Religionsbekenntnisses des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“
(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.2.16.1.4.1
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st1 … 1FHL7.AT:ReligionAustria
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.18 ELGA_ReligiousAffiliation (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:raceCode
NP
Rasse des Patienten
    Darf nicht verwendet werden!
   
(epi...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:ethnic​Group​Code
NPEthnische Zugehörigkeit des Patienten.

Darf nicht verwendet werden!


(epi...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:guardian
0 … *RGesetzlicher Vertreter: Erwachsenenvertreter, Vormund, Obsorgeberechtigter.
Der gesetzliche Vetreter kann entweder eine Person (guardianPerson) oder eine Organisation (guardianOrganization) sein.
Beim Patient können optional ein oder mehrere gesetzliche Vetreter angegeben werden. Wenn ein gesetzliche Vetreter bekannt ist, SOLL diese Information auch angegeben werden.
(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FGUARD
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
0 … 1R
Die Adresse des gesetzlichen Vertreters oder der Organisation.
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *RBeliebig viele Kontaktdaten des gesetzlichen Vertreters als Person oder Organisation.
Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.
(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom-Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß Value-Set „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (z.B. Heim, Arbeitsplatz) Bsp: WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Auswahl1 … 1
Angabe des gesetzlichen Vertreters als Person (guardianPerson in Granularitätsstufe 1 oder 2) ODER als Organisation (guardianOrganization)
Elemente in der Auswahl:
  • hl7:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
  • hl7:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
  • hl7:guardian​Organization welches enthält Template 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Person
0 … 1Name des gesetzlichen Vertreters: Angabe in Granularitätsstufe 1
Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Person
0 … 1Name des gesetzlichen Vertreters: Angabe in Granularitätsstufe 2
Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:guardian​Organization
0 … 1RName des gesetzlichen Vertreters (Organisation)
Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)
(epi...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:birthplace
0 … 1RGeburtsort des Patienten.(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FBIRTHPL
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:place
1 … 1M(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPLC
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC)
  • hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional.

Beinhaltet 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC)
(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Die Adresse des Geburtsorts, struktuiert.
Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(epi...get)
Treeblank.pngTreeblank.pngTreetree.pnghl7:language​Communication
0 … *R
Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten.
(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:language​Code
CS1 … 1MSprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen).
(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1RZulässige Werte gemäß Value-Set „ELGA_HumanLanguage“ aus Code-System „HL7:HumanLanguage 2.16.840.1.113883.6.121“
Gemäß IETF / RFC 3066 enthält es ein bestimmtes Subset von Codes aus ISO 639-1 und ISO 639-2 (also zwei- und dreistellige Sprachcodes). Gemäß RFC 3066 ist es zulässig, eine Angabe der landestypischen Ausprägung der Sprache nach einem Bindestrich anzufügen. Das Land wird dabei nach ISO 3166-1 Alpha 2 angegeben. Dies MUSS bei der Auswertung des languageCodes berücksichtigt und toleriert werden.
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.173 ELGA_HumanLanguage (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:modeCode
CE0 … 1RAusdrucksform der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_LanguageAbilityMode“
(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.60
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FHL7:LanguageAbilityMode
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:proficiency​Level​Code
CE0 … 1RGrad der Sprachkenntnis in der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“
(epi...get)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1F2.16.840.1.113883.5.61
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
st0 … 1FHL7:LanguageAbilityProficiency
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.174 ELGA_ProficiencyLevelCode (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:preference​Ind
BL0 … 1RKennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.(epi...get)
 Schematron assertrole error 
 testnot(hl7:id[1]/@nullFlavor) 
 MeldungDie Verwendung von id/@nullFlavor ist an dieser Stelle NICHT ERLAUBT. 
 Schematron assertrole error 
 testnot(hl7:id[2]/@nullFlavor) or (hl7:id[2][@nullFlavor='UNK'] or hl7:id[2][@nullFlavor='NI']) 
 MeldungZugelassene nullFlavor sind "NI" und "UNK" 


7.2.1.9 Author

Id1.2.40.0.34.6.0.11.1.2
ref
at-cda-bbr-
Gültigkeit2019‑02‑13 09:50:17
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_AuthorAnzeigenameAuthor
Beschreibung
Der Autor, Urheber oder Dokumentersteller ist die Person, die haupt-ursächlich etwas verursacht oder veranlasst oder als Anstifter, Initiator, Verfasser oder Verursacher wirkt. Der Autor kann auch ein „Dokument-erstellendes Gerät“ sein, etwa ein Computerprogramm, das automatisch Daten zu einem Patienten in Form eines Befunds oder einer Zusammenfassung kombiniert.
Die das Dokument schreibende Person (Schreibkraft, medizinischeR DokumentationsassistentIn, …) wird in CDA in einem eigenen Element (dataEnterer) abgebildet, siehe „Personen der Dateneingabe („dataEnterer“)“.
Es kann auch mehr als ein Dokumentersteller angegeben werden (mehrere author-Elemente). Für die XDS-Metadaten sollen jeweils nur die Author-Elemente verwendet werden, die eine Person darstellen, mit dem „Hauptautor“ als erstes Element. Geräte MÜSSEN hinter den Personen-Autoren stehen (sofern nicht ein OnDemandDocument ohne Person oder sonstige - automatisch ohne Personenkontakt erstellte - Dokumente ohne Person).
↔ Hinweis zum XDS-Mapping: Folgende XDS-Attribute werden aus dem Element Author abgeleitet:
  • AuthorInstitution (=representedOrganization)
  • AuthorPerson (=assignedAuthor)
  • AuthorRole (=functionCode)
  • AuthorSpeciality  (=assignedAuthor.code)
Nur Author-Elemente mit einer Person sind für das XDS-Mapping zu übernehmen.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 3 Templates
Benutzt als NameVersion
1.2.40.0.34.6.0.11.9.11ContainmentKyellow.png Person Name Compilation G2 M (2019)DYNAMIC
1.2.40.0.34.6.0.11.9.18ContainmentKyellow.png Device Compilation (2019)DYNAMIC
1.2.40.0.34.6.0.11.9.5ContainmentKyellow.png Organization Compilation with id, name (2019)DYNAMIC
Beispiel
Person als Author
<author typeCode="AUT" contextControlCode="OP">
  <!-- Funktionscode -->
  <functionCode code="OA" displayName="Diensthabender Oberarzt" codeSystem="1.2.40.0.34.99.111.2.1" codeSystemName="Amadeus Spital Funktionen"/>  <!-- Zeitpunkt der Erstellung -->
  <time value="20190605133410+0200"/>  <assignedAuthor classCode="ASSIGNED">
    <!-- Identifikation des Verfassers des Dokuments -->
    <id root="1.2.40.0.34.99.111.1.3" extension="1111" assigningAuthorityName="Amadeus Spital"/>    <!-- Fachrichtung des Verfassers des Dokuments -->
    <code code="107" displayName="Fachärztin/Facharzt für Chirurgie" codeSystem="1.2.40.0.34.5.160" codeSystemName="ELGA_Fachaerzte"/>    <!-- Kontaktdaten des Verfassers des Dokuments -->
    <telecom value="tel:+43.1.40400"/>    <telecom value="mailto:Isabella.Stern@organization.at"/>    <!-- Person als Author -->
    <assignedPerson classCode="PSN" determinerCode="INSTANCE">
      <!-- template 1.2.40.0.34.6.0.11.9.11 'Person Name Compilation G2 M' (2019-04-02T10:09:43) -->
    </assignedPerson>
    <representedOrganization>
      <!-- template 1.2.40.0.34.6.0.11.9.5 'Organization Compilation with id, name' (2019-03-25T13:43:57) -->
    </representedOrganization>
  </assignedAuthor>
</author>
Beispiel
Gerät als Author
<author typeCode="AUT" contextControlCode="OP">
  <!-- Zeitpunkt der Erstellung -->
  <time value="20190605133410+0200"/>  <assignedAuthor classCode="ASSIGNED">
    <!-- Geräte Identifikation (oder nullFlavor) -->
    <id root="86562fe5-b509-4ce9-b976-176fd376e477" assigningAuthorityName="KH Eisenstadt"/>    <!-- Gerät als Author -->
    <assignedAuthoringDevice classCode="DEV" determinerCode="INSTANCE">
      <!-- template 1.2.40.0.34.6.0.11.9.18 'Device Compilation' (2019-02-13T10:11:00) -->
    </assignedAuthoringDevice>
    <representedOrganization>
      <!-- template 1.2.40.0.34.6.0.11.9.5 'Organization Compilation with id, name' (2019-03-25T13:43:57) -->
    </representedOrganization>
  </assignedAuthor>
</author>
ItemDTKardKonfBeschreibungLabel
hl7:author
1 … *MVerfasser des Dokuments.
(atc...hor)
Treetree.png@typeCode
cs0 … 1FAUT
Treetree.png@context​Control​Code
cs0 … 1FOP
Treetree.pnghl7:functionCode
CE (extensible)0 … 1R
Funktionscode des Verfassers des Dokuments, z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“.
Eigene Codes und Bezeichnungen können verwendet werden.
(atc...hor)
Treeblank.pngTreetree.png@code
cs1 … 1R
Treeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreetree.png@displayName
st1 … 1R
Auswahl1 … 1
Der Zeitpunkt an dem das Dokument verfasst, bzw. inhaltlich fertiggestellt wurde.
Elemente in der Auswahl:
  • hl7:time[not(@nullFlavor)]
  • hl7:time[@nullFlavor='UNK']
Treeblank.pngTreetree.pnghl7:time
TS.AT.TZ0 … 1(atc...hor)
wo [not(@nullFlavor)]
Treeblank.pngTreetree.pnghl7:time
TS.AT.TZ0 … 1(atc...hor)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treetree.pnghl7:assignedAuthor
1 … 1M(atc...hor)
Treeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Auswahl1 … *
Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software.
ODER Identifikation des/der datenerstellenden Gerätes/Software. 
Elemente in der Auswahl:
  • hl7:id[not(@nullFlavor)]
  • hl7:id[@nullFlavor='NI']
  • hl7:id[@nullFlavor='UNK']
 ConstraintZugelassene nullFlavor:
  • NI  ….... Person hat keine ID / Gerät/Software hat keine ID 
  • UNK  … Person hat eine ID, diese ist jedoch unbekannt / Gerät/Software hat eine ID, diese ist jedoch unbekannt
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *
Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software.
ODER Identifikation des/der datenerstellenden Gerätes/Software. 
(atc...hor)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(atc...hor)
wo [@nullFlavor='NI']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FNI
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(atc...hor)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treeblank.pngTreetree.pnghl7:code
CE0 … 1R
Angabe der Fachrichtung des Verfassers des Dokuments („Sonderfach“ gem. Ausbildungsordnung), z.B: „Facharzt/Fachärzting für Gynäkologie“.
Wenn ein Autor mehreren ärztlichen Sonderfächern zugeordnet ist, kann das anzugebende Sonderfach gewählt werden. Additivfächer werden nicht angegeben.
(atc...hor)
Treeblank.pngTreeblank.pngTreetree.png@codeSystem
oid1 … 1R
Treeblank.pngTreeblank.pngTreetree.png@displayName
st1 … 1R
Treeblank.pngTreeblank.pngTreetree.png@code
cs1 … 1R
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten des Verfassers des Dokuments.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(atc...hor)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:assigned​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
  • hl7:assigned​Authoring​Device welches enthält Template 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
0 … 1
Personendaten des Verfassers des Dokuments.
Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen, name-Element ist hier Mandatory.

Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
(atc...hor)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Authoring​Device
0 … 1Datenerstellendes Gerät
Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC)
(atc...hor)
Treeblank.pngTreetree.pnghl7:represented​Organization
1 … 1MOrganisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.

Beinhaltet 1.2.40.0.34.6.0.11.9.5 Organization Compilation with id, name (DYNAMIC)
(atc...hor)
 Constraint
  • id MUSS der OID der Organisation aus dem GDA-Index entsprechen.
  • Zu dem Namen größerer Organisationen SOLL auch die Abteilung angegeben werden., z.B.: „Amadeus Spital, Chirurgische Abteilung“
 Schematron assertrole error 
 testcount(hl7:telecom)<2 or (count(hl7:telecom) = count(hl7:telecom[@use])) 
 MeldungDas Attribut telecom/@use MUSS bei allen telecom Elementen strukturiert sein. 


7.2.1.10 Custodian

Id1.2.40.0.34.6.0.11.1.4
ref
at-cda-bbr-
Gültigkeit2019‑02‑26 11:28:24
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_CustodianAnzeigenameCustodian
Beschreibung
Der "Verwahrer" des Dokuments stellt die Organisation dar, von der das Dokument stammt und die für die Aufbewahrung und Verwaltung des ORIGINALEN Dokuments verantwortlich ist. Jedes CDA-Dokument hat genau einen Custodian.
Der Custodian entspricht der Definition von Verwaltertätigkeit ("Stewardship") von CDA. Da CDA ein Austauschformat für Dokumente ist und ein CDA-Dokument möglicherweise nicht die ursprüngliche Form der authentifizierten Dokumente darstellt, repräsentiert der Custodian den Verwalter der ursprünglichen Quelldokumente.
KlassifikationCDA Header Level Template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
at-cda-bbr-data​element-24Kyellow.png Verwahrer Kyellow.png Dataset A 2019
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.6.0.11.9.25ContainmentKyellow.png Address Compilation (2019)DYNAMIC
Beispiel
Beispiel
<!-- Verwahrer des Dokuments -->
<custodian typeCode="CST">
  <assignedCustodian classCode="ASSIGNED">
    <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">
      <!-- Identifikation des Verwahrers -->
      <id root="1.2.3.999" extension="7601234567890"/>      <name>Amadeus Spital</name>      <telecom value="tel:+43.(0)50.55460-0"/>      <addr>
        <!-- template 1.2.40.0.34.6.0.11.9.25 'Address Compilation' (2019-02-28T14:24:14) -->
      </addr>
    </representedCustodianOrganization>
  </assignedCustodian>
</custodian>
ItemDTKardKonfBeschreibungLabel
hl7:custodian
Verwahrer des Dokuments.(atc...ian)
 
Target.png
at-cda-bbr-data​element-24Kyellow.png Verwahrer Kyellow.png Dataset A 2019
Treetree.png@typeCode
cs0 … 1FCST
Treetree.pnghl7:assignedCustodian
1 … 1M(atc...ian)
Treeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Treeblank.pngTreetree.pnghl7:represented​Custodian​Organization
1 … 1M(atc...ian)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *MIdentifikation des Verwahrers des Dokuments, wie im GDA-Index angegeben. Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.(atc...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1MName des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Namen-Elemente von Organisationen ON“ zu befolgen.(atc...ian)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *Kontaktdaten des Verwahrers des originalen Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.(atc...ian)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1MAdresse des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.
Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(atc...ian)


7.2.1.11 Legal Authenticator

Id1.2.40.0.34.6.0.11.1.5
ref
at-cda-bbr-
Gültigkeit2019‑03‑04 11:41:57
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_LegalAuthenticatorAnzeigenameLegal Authenticator
Beschreibung
Der „Rechtliche Unterzeichner“ oder Hauptunterzeichner ist jene Person, welche für das Dokument aus rechtlicher Sicht die Verantwortung übernimmt.
Es muss organisatorisch sichergestellt werden, dass die Person, die als rechtlicher Unterzeichner eingetragen wird, über die entsprechende Berechtigung verfügt. Grundsätzlich MUSS der Hauptunterzeichner angegeben werden, in bestimmten Fällen kann dies aber unterbleiben, etwa wenn es sich um automatisch
erstellte Befunde handelt (Dokumente, die von „Geräten“ oder "Software" autonom erstellt wurden, d.h. wenn der Inhalt durch einen Algorithmus erzeugt und
nicht von einer natürlichen Person freigegeben wurde, z.B. On-demand Dokumente).
Diese Fälle sind in den jeweiligen speziellen Leitfaden entsprechend angegeben.  Falls mehrere rechtliche Unterzeichner vorhanden sind, können diese
angegeben werden.

    ↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Metadatenelement DocumentEntry.legalAuthenticator gemappt.
    ACHTUNG: Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste ELement (ClinicalDocument/LegalAuthenticator[1]) übernommen werden.
KlassifikationCDA Header Level Template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 6 Konzepte
IdNameDatensatz
elgaimpf-data​element-368Kyellow.png Unterzeichnende Person (Dokument) Kyellow.png Datensatz e-Impfpass 2019
at-cda-bbr-data​element-1Kyellow.png Rechtlicher Unterzeichner Kyellow.png Dataset A 2019
elgaimpf-data​element-370Kyellow.png Signatur Kyellow.png Datensatz e-Impfpass 2019
at-cda-bbr-data​element-5Kyellow.png Zeitpunkt der Unterzeichnung Kyellow.png Dataset A 2019
elgaimpf-data​element-369Kyellow.png Zeitpunkt der Unterzeichnung Kyellow.png Datensatz e-Impfpass 2019
at-cda-bbr-data​element-6Kyellow.png Signatur Kyellow.png Dataset A 2019
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.6.0.11.9.22ContainmentKyellow.png Assigned Entity (2019)DYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.20006 HeaderLegalAuthenticator (2011‑12‑19)
ref
elgabbr-
Beispiel
Strukturbeispiel
<legalAuthenticator contextControlCode="OP" typeCode="LA">
  <!-- Zeitpunkt der Unterzeichnung -->
  <time value="20190324082015+0100"/>  <!-- Signaturcode -->
  <signatureCode code="S"/>  <!-- Personen- und Organisationsdaten des Rechtlichen Unterzeichners des Dokuments -->
  <assignedEntity>
    <!-- include template 1.2.40.0.34.6.0.11.9.22 'Assigned Entity' (dynamic) .. O -->
  </assignedEntity>
</legalAuthenticator>
ItemDTKardKonfBeschreibungLabel
hl7:legalAuthenticator
Hauptunterzeichner, Rechtlicher Unterzeichner
(atc...tor)
 
Target.png
elgaimpf-data​element-368Kyellow.png Unterzeichnende Person (Dokument) Kyellow.png Datensatz e-Impfpass 2019
at-cda-bbr-data​element-1Kyellow.png Rechtlicher Unterzeichner Kyellow.png Dataset A 2019
Treetree.png@context​Control​Code
cs0 … 1FOP
Treetree.png@typeCode
cs0 … 1FLA
Auswahl1 … 1
Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.
Elemente in der Auswahl:
  • hl7:time[not(@nullFlavor)]
  • hl7:time[@nullFlavor='UNK']
Treeblank.pngTreetree.pnghl7:time
TS.AT.TZ0 … 1(atc...tor)
wo [not(@nullFlavor)]
 
Target.png
at-cda-bbr-data​element-5Kyellow.png Zeitpunkt der Unterzeichnung Kyellow.png Dataset A 2019
elgaimpf-data​element-369Kyellow.png Zeitpunkt der Unterzeichnung Kyellow.png Datensatz e-Impfpass 2019
Treeblank.pngTreetree.pnghl7:time
TS.AT.TZ0 … 1(atc...tor)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treetree.pnghl7:signatureCode
CS1 … 1MSignaturcode gibt an, dass das Originaldokument unterzeichnet wurde.
(atc...tor)
 
Target.png
elgaimpf-data​element-370Kyellow.png Signatur Kyellow.png Datensatz e-Impfpass 2019
at-cda-bbr-data​element-6Kyellow.png Signatur Kyellow.png Dataset A 2019
Treeblank.pngTreetree.png@code
CONF1 … 1FS
Treetree.pnghl7:assignedEntity
1 … 1MPersonendaten des rechtlichen Unterzeichners.
Für den Namen ist verpflichtend Granularitätsstufe 2 ("strukturierte Angabe des Namens") anzuwenden!
Beinhaltet 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC)
(atc...tor)


7.2.1.12 Authenticator

Id1.2.40.0.34.6.0.11.1.6
ref
at-cda-bbr-
Gültigkeit2019‑03‑04 13:11:54
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_AuthenticatorAnzeigenameAuthenticator
Beschreibung
Mitunterzeichner, weiterer Unterzeichner.
Dokumente können neben dem verpflichtenden legalAuthenticator („rechtlichen Unterzeichner“, Hauptunterzeichner) auch beliebig viele weitere Mitunterzeichner beinhalten.
Sonderfälle:
  • Multidisziplinäre Befunde: Die Angabe von mindestens zwei Mitunterzeichnern (authenticator) ersetzt die Angabe eines Hauptunterzeichners (legalAuthenticator), wenn dieser nicht ermittelt werden kann (z.B. bei multidisziplinären Befunden, die von mehreren Fachärzten mit unterschiedlicher Fachrichtung gleichermaßen verantwortet werden).
  • Automatisch erstellte Befunde: Bei Dokumenten, die von „Geräten“ erstellt wurden (wenn der Inhalt durch einen Algorithmus erzeugt und nicht von einer natürlichen Person freigegeben wurde), entfällt die Angabe aller Unterzeichner.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 3 Konzepte
IdNameDatensatz
at-cda-bbr-data​element-105Kyellow.png Zeitpunkt der Unterzeichnung Kyellow.png Dataset A 2019
at-cda-bbr-data​element-31Kyellow.png Weitere Unterzeichner Kyellow.png Dataset A 2019
at-cda-bbr-data​element-106Kyellow.png Signatur Kyellow.png Dataset A 2019
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.6.0.11.9.22InklusionKyellow.png Assigned Entity (2019)DYNAMIC
Beispiel
Strukturbeispiel
<authenticator typeCode="AUTHEN">
  <!-- Zeitpunkt der Unterzeichnung -->
  <time value="20190605"/>  <!-- Signaturcode -->
  <signatureCode code="S"/>  <!-- Personen- und Organisationsdaten des Weiteren Unterzeichners des Dokuments -->
  <assignedEntity>
    <!-- include template 1.2.40.0.34.6.0.11.9.22 'Assigned Entity' (dynamic) .. O -->
  </assignedEntity>
</authenticator>
ItemDTKardKonfBeschreibungLabel
hl7:authenticator
Weitere Unterzeichner.(atc...tor)
 
Target.png
at-cda-bbr-data​element-31Kyellow.png Weitere Unterzeichner Kyellow.png Dataset A 2019
Treetree.png@typeCode
cs0 … 1FAUTHEN
Auswahl1 … 1
Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.
Grundsätzlich sind die Vorgaben gemäß für „Zeit-Elemente“ zu befolgen.
Elemente in der Auswahl:
  • hl7:time[not(@nullFlavor)]
  • hl7:time[@nullFlavor='UNK']
Treeblank.pngTreetree.pnghl7:time
TS.AT.TZ0 … 1(atc...tor)
wo [not(@nullFlavor)]
 
Target.png
at-cda-bbr-data​element-105Kyellow.png Zeitpunkt der Unterzeichnung Kyellow.png Dataset A 2019
Treeblank.pngTreetree.pnghl7:time
TS.AT.TZ0 … 1(atc...tor)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treetree.pnghl7:signatureCode
CS1 … 1M(atc...tor)
 
Target.png
at-cda-bbr-data​element-106Kyellow.png Signatur Kyellow.png Dataset A 2019
Treeblank.pngTreetree.png@code
CONF1 … 1FS
Treetree.pnghl7:assignedEntity
1 … 1M
Personendaten des weiteren Unterzeichners.
Grundsätzlich sind die Vorgaben gemäß Kapitel „AssignedEntity-Element (Person + Organisation)“ zu befolgen.
(atc...tor)
Eingefügt von 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC)
Treeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Auswahl1 … *
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
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(atc...tor)
wo [not(@nullFlavor)]
 
Target.png
elgaimpf-data​element-371Kyellow.png ID des Unterzeichners Kyellow.png Datensatz e-Impfpass 2019
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(atc...tor)
wo [@nullFlavor='NI']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FNI
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(atc...tor)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Auswahl0 … 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']
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
0 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)(atc...tor)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
0 … 1(atc...tor)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Beliebig viele Kontakt-Elemente der Person der Entität.
Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.
(atc...tor)
wo [not(@nullFlavor)]
 
Target.png
elgaimpf-data​element-372Kyellow.png Kontaktdaten Kyellow.png Datensatz e-Impfpass 2019
Treeblank.pngTreeblank.pngTreetree.png@value
url1 … 1R
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“
Treeblank.pngTreeblank.pngTreetree.png@use
cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP.
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M
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...tor)
Treeblank.pngTreetree.pnghl7:represented​Organization
0 … 1R
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...tor)
 
Target.png
elgaimpf-data​element-374Kyellow.png Organisation Kyellow.png Datensatz e-Impfpass 2019
 Schematron assertrole error 
 testcount(hl7:telecom)<2 or (count(hl7:telecom) = count(hl7:telecom[@use])) 
 MeldungDas Attribut telecom/@use MUSS bei allen telecom Elementen strukturiert sein. 


7.2.1.13 Information Recipient - EMS

Id1.2.40.0.34.6.0.11.1.35Gültigkeit2020‑02‑20 09:37:56
StatusKyellow.png EntwurfVersions-Label2020
Nameepims_header_informationRecipientAnzeigenameInformation Recipient - EMS
Beschreibung
Dieses Element dokumentiert den/die Empfänger des Dokuments. Da es sich bei der Meldung ans EMS um eine gerichtete Kommunikation handelt kann der primäre Empfänger des Dokuments, das Bundesministeriums für Gesundheit, optional angegeben werden.


KlassifikationCDA Header Level Template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.40.0.34.6.0.11.9.39ContainmentKyellow.png Organization Compilation with id, name, tel, addr - EMS (2020)DYNAMIC
BeziehungSpezialisierung: Template 1.2.40.0.34.6.0.11.1.24 Information Recipient (2019‑03‑26 13:08:59)
ref
at-cda-bbr-

Version: Template 1.2.40.0.34.11.20005 Header​Information​Recipient (2011‑12‑19)
ref
elgabbr-
Beispiel
Beispiel
<hl7:informationRecipient typeCode="PRCP">
  <hl7:intendedRecipient classCode="cs">
    <hl7:id assigningAuthorityName="BMGF" root="1.2.40.0.34.3.1.1"/>    <hl7:informationRecipient>
      <hl7:name>BMGF</hl7:name>    </hl7:informationRecipient>
    <hl7:receivedOrganization>
      <!-- template 1.2.40.0.34.6.0.11.9.39 'Organization Compilation with id, name, tel, addr - EMS' (2020-02-20T09:48:27) -->
    </hl7:receivedOrganization>
  </hl7:intendedRecipient>
</hl7:informationRecipient>
ItemDTKardKonfBeschreibungLabel
hl7:information​Recipient
Beabsichtiger Empfänger des Dokuments. 
(epi...ent)
Treetree.png@typeCode
cs0 … 1FPRCP
Treetree.pnghl7:intended​Recipient
1 … 1M(epi...ent)
Treeblank.pngTreetree.png@classCode
cs0 … 1 
Treeblank.pngTreetree.pnghl7:id
II1 … 1M(epi...ent)
Treeblank.pngTreeblank.pngTreetree.png@assigningAuthorityName
st0 … 1FBMGF
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.3.1.1
Treeblank.pngTreetree.pnghl7:information​Recipient
1 … 1M(epi...ent)
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ST1 … 1M(epi...ent)
 CONF
Elementinhalt muss "BMGF" sein
Treeblank.pngTreetree.pnghl7:received​Organization
1 … 1MBeinhaltet 1.2.40.0.34.6.0.11.9.39 Organization Compilation with id, name, tel, addr - EMS (DYNAMIC)(epi...ent)


7.2.1.14 Participant Ein-, Ueber-, Zuweisender Arzt

Id1.2.40.0.34.6.0.11.1.21
ref
at-cda-bbr-
Gültigkeit2019‑02‑12 16:23:33
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_ParticipantEinweisenderZuweisenderUeberweisenderArztAnzeigenameParticipant Ein-, Ueber-, Zuweisender Arzt
Beschreibung
Beteiligter (Einweisender/Zuweisender Arzt)
KlassifikationCDA Header Level Template
Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
Benutzt
Benutzt 4 Templates
Benutzt als NameVersion
1.2.40.0.34.6.0.11.9.25ContainmentKyellow.png Address Compilation (2019)DYNAMIC
1.2.40.0.34.6.0.11.9.12ContainmentKyellow.png Person Name Compilation G1 M (2019)DYNAMIC
1.2.40.0.34.6.0.11.9.11ContainmentKyellow.png Person Name Compilation G2 M (2019)DYNAMIC
1.2.40.0.34.6.0.11.9.9InklusionKyellow.png Organization Compilation with name (2019)DYNAMIC
BeziehungVersion: Template 1.2.40.0.34.11.1.1.1 HeaderParticipant Ansprechpartner (2014‑03‑25)
ref
elgabbr-
Beispiel
Strukturbeispiel
<participant contextControlCode="OP" typeCode="REF">
  <templateId root="1.2.40.0.34.6.0.11.1.21"/>  <associatedEntity classCode="PROV">
    <!-- Participant Ein-, Ueber-, Zuweisender Arzt -->
    <id root="1.2.3.999"/>    <addr>
      <!-- template 1.2.40.0.34.6.0.11.9.25 'Address Compilation' (2019-02-28T14:24:14) -->
    </addr>
    <telecom use="WP" value="tel:+43.1.3453446.1"/>    <associatedPerson>
      <!-- Name des ein-, ueber-, zuweisenden Arztes (strukturierte Angabe) -->
      <!-- include template 1.2.40.0.34.6.0.11.9.11 'Person Name Compilation G2 M' 1..1 M -->
    </associatedPerson>
    <scopingOrganization>
      <!-- include template 1.2.40.0.34.6.0.11.9.9 'Organization Compilation with name' (dynamic) .. O -->
    </scopingOrganization>
  </associatedEntity>
</participant>
ItemDTKardKonfBeschreibungLabel
hl7:participant
Einweisender/Zuweisender/Überweisender Arzt(atc...rzt)
wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.21']]
Treetree.png@typeCode
cs1 … 1FREF
 Referrer
Treetree.png@context​Control​Code
cs0 … 1FOP
Treetree.pnghl7:templateId
II1 … 1M(atc...rzt)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.40.0.34.6.0.11.1.21
Treetree.pnghl7:associated​Entity
1 … 1M(atc...rzt)
Treeblank.pngTreetree.png@classCode
cs1 … 1FPROV
 Healthcare provider - Gesundheitsdiensteanbieter
Auswahl1 … *
Identifikation des einweisenden/zuweisenden/überweisenden Arztes.
Elemente in der Auswahl:
  • hl7:id[not(@nullFlavor)]
  • hl7:id[@nullFlavor='NI']
  • hl7:id[@nullFlavor='UNK']
 ConstraintZugelassene nullFlavor:
  • NI … Die Person der Entität hat keine Identifikationsnummer
  • UNK … Die Person der Entität hat eine Identifikationsnummer, diese ist jedoch unbekannt
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(atc...rzt)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(atc...rzt)
wo [@nullFlavor='NI']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FNI
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1(atc...rzt)
wo [@nullFlavor='UNK']
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
cs1 … 1FUNK
Treeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse des einweisenden/zuweisenden/überweisenden Arztes
Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(atc...rzt)
wo [not(@nullFlavor)]
Treeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … * Beliebig viele Kontaktdaten des einweisenden/zuweisenden/überweisenden Arztes
(atc...rzt)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 CONF
Der Wert von @use muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.190 AddressUse (DYNAMIC)
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Auswahl1 … 1
Name des einweisenden/zuweisenden/überweisenden Arztes.
Elemente in der Auswahl:
  • hl7:associated​Person[hl7:name[count(child::*)=0]] welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
  • hl7:associated​Person[hl7:name[count(child::*)!=0]] welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)(atc...rzt)
wo [hl7:name [count(child::*)=0]]
Treeblank.pngTreeblank.pngTreetree.pnghl7:associated​Person
 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)(atc...rzt)
wo [hl7:name [count(child::*)!=0]]
Treeblank.pngTreetree.pnghl7:scoping​Organization
0 … 1R
                           Organisation, der der Einweiser/Zuweiser/Überweiser angehört (mit Adresse und Kontaktdaten der Organisation).
Grundsätzlich sind die Vorgaben für "Organisations-Element" zu befolgen.
(atc...rzt)
Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.(atc...rzt)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1MName der Organisation. Bei Organisationen, die im GDA-Index angegeben sind, soll deren Kurzbezeichnung verwendet werden.
Zu dem Namen größerer Organisationen SOLL auch die Abteilung angegeben werden.
(atc...rzt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL.AT0 … *
Kontaktdaten der Organisation.
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.
(atc...rzt)
wo [not(@nullFlavor)]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
st1 … 1R
Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567
Formatkonvention siehe „telecom – Format Konventionen für Telekom-Daten“
Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
set_cs0 … 1 
Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP
Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
 ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)
(atc...rzt)
wo [not(@nullFlavor)]
 Schematron assertrole error 
 testcount(hl7:telecom)<2 or (count(hl7:telecom) = count(hl7:telecom[@use])) 
 MeldungDas Attribut telecom/@use MUSS bei allen telecom Elementen strukturiert sein. 


7.2.1.15 In Fulfillment Of

Id1.2.40.0.34.6.0.11.1.9
ref
at-cda-bbr-
Gültigkeit2019‑03‑14 13:22:14
StatusKyellow.png EntwurfVersions-Label2019
Nameatcdabbr_header_InFulfillmentOfAnzeigenameIn Fulfillment Of
Beschreibung
Das Element “inFulfillmentOf” ermöglicht die Referenz zum ursprünglichen Auftrag des Auftraggebers.
Dies kann zum Beispiel eine Auftrags- oder Anforderungsnummer sein. Das Element erlaubt genau ein order Unterelement.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 2 Konzepte
IdNameDatensatz
at-cda-bbr-data​element-42Kyellow.png Auftrag Kyellow.png Dataset A 2019
at-cda-bbr-data​element-43Kyellow.png ID Kyellow.png Dataset A 2019
BeziehungVersion: Template 1.2.40.0.34.11.20009 HeaderInFulfillmentOf (2011‑12‑19)
ref
elgabbr-
Beispiel
Strukturbeispiel
<inFulfillmentOf typeCode="FLFS">
  <order classCode="ACT" moodCode="RQO">
    <id root="2.16.840.1.113883.2.16.1.99.3.1" extension="081201-004"/>  </order>
</inFulfillmentOf>
ItemDTKardKonfBeschreibungLabel
hl7:inFulfillmentOf
Komponente zur Dokumentation des Auftrags.
(atc...tOf)
 
Target.png
at-cda-bbr-data​element-42Kyellow.png Auftrag Kyellow.png Dataset A 2019
Treetree.png@typeCode
cs1 … 1FFLFS
Treetree.pnghl7:order
1 … 1MAuftrag.
(atc...tOf)
Treeblank.pngTreetree.png@classCode
cs1 … 1FACT
Treeblank.pngTreetree.png@moodCode
cs1 … 1FRQO
Treeblank.pngTreetree.pnghl7:id
II1 … 1MAuftragsnummer, Anforderungsnummer.
Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen.
(atc...tOf)
 
Target.png
at-cda-bbr-data​element-43Kyellow.png ID Kyellow.png Dataset A 2019


7.2.1.16 Documentation Of Service Event - Infectious disease Note

Id1.2.40.0.34.6.0.11.1.36Gültigkeit2020‑02‑20 10:42:57
StatusKyellow.png EntwurfVersions-Label2020
Nameepims_header_documentationOfServiceEventInfDisNoteAnzeigenameDocumentation Of Service Event - Infectious disease Note
Beschreibung
Dieses ServiceEvent codiert, dass dieses Dokument eine meldepflichtige Krankheit meldet.


Die Angabe eines zeitlichen Erbringungsintervalls effectiveTime mit einer Start- low und End-zeit high ist verpflichtend

    KlassifikationCDA Header Level Template
    Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
    Benutzt
    Benutzt 1 Template
    Benutzt als NameVersion
    1.2.40.0.34.6.0.11.9.35InklusionKyellow.png Date Interval Information minimal (2019)DYNAMIC
    BeziehungSpezialisierung: 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)
    ref
    ?

    Version: Template 1.2.40.0.34.11.20010 HeaderServiceEvent (2011‑12‑19)
    ref
    elgabbr-
    Beispiel
    Beispiel
    <hl7:documentationOf typeCode="DOC">
      <hl7:serviceEvent classCode="ACT" moodCode="EVN">
        <hl7:code code="34782-3" codeSystem="2.16.840.1.113883.6.1" displayName="Infectious disease Note"/>    <hl7:effectiveTime>
          <!-- include template 1.2.40.0.34.6.0.11.9.35 'Date Interval Information minimal' (dynamic) 1..1 M -->
        </hl7:effectiveTime>
      </hl7:serviceEvent>
    </hl7:documentationOf>
    ItemDTKardKonfBeschreibungLabel
    hl7:documentationOf
    Komponente für die Gesundheitsdienstleistung.
    (epi...ote)
    Treetree.png@typeCode
    cs0 … 1FDOC
    Treetree.pnghl7:serviceEvent
    1 … 1M(epi...ote)
    Treeblank.pngTreetree.png@classCode
    cs0 … 1FACT
    Treeblank.pngTreetree.png@moodCode
    cs0 … 1FEVN
    Treeblank.pngTreetree.pnghl7:code
    CE1 … 1M(epi...ote)
    Treeblank.pngTreeblank.pngTreetree.png@code
    CONF1 … 1F34782-3
    Treeblank.pngTreeblank.pngTreetree.png@codeSystem
    1 … 1F2.16.840.1.113883.6.1 (LOINC)
    Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
    1 … 1FLOINC
    Treeblank.pngTreeblank.pngTreetree.png@displayName
    1 … 1FInfectious disease Note
    Treeblank.pngTreetree.pnghl7:effectiveTime
    IVL_TS1 … 1MDie Angabe eines zeitlichen Erbringungsintervalls effectiveTime mit einer Start- low und End-zeit high ist verpflichtend
    (epi...ote)
    Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.9.35 Date Interval Information minimal (DYNAMIC)
    Auswahl1 … 1Elemente in der Auswahl:
    • hl7:low[not(@nullFlavor)]
    • hl7:low[@nullFlavor='UNK']
    Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
    TS.DATE0 … 1(epi...ote)
    wo [not(@nullFlavor)]
    Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
    TS.DATE0 … 1(epi...ote)
    wo [@nullFlavor='UNK']
    Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
    cs1 … 1FUNK
    Auswahl1 … 1Elemente in der Auswahl:
    • hl7:high[not(@nullFlavor)]
    • hl7:high[@nullFlavor='UNK']
    Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
    TS.DATE0 … 1(epi...ote)
    wo [not(@nullFlavor)]
    Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
    TS.DATE0 … 1(epi...ote)
    wo [@nullFlavor='UNK']
    Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
    cs1 … 1FUNK


    7.2.1.17 Documentation Of Service Event - Laboratory Report

    Id1.2.40.0.34.6.0.11.1.38Gültigkeit2020‑02‑25 14:51:13
    StatusKyellow.png EntwurfVersions-Label2020
    Nameepims_header_documentationOfServiceEventLaboratoryReportAnzeigenameDocumentation Of Service Event - Laboratory Report
    BeschreibungDieses ServiceEvent, in Kombination des ServiceEvents für "Infectious disease Note" kennzeichnen, dass dieses Dokument von einem Labor ins EMS eingebracht wird.
      KlassifikationCDA Header Level Template
      Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
      Benutzt
      Benutzt 2 Templates
      Benutzt als NameVersion
      1.2.40.0.34.6.0.11.9.35InklusionKyellow.png Date Interval Information minimal (2019)DYNAMIC
      1.2.40.0.34.6.0.11.9.22InklusionKyellow.png Assigned Entity (2019)DYNAMIC
      BeziehungSpezialisierung: 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)
      ref
      ?

      Version: Template 1.2.40.0.34.11.20010 HeaderServiceEvent (2011‑12‑19)
      ref
      elgabbr-
      Beispiel
      Beispiel
      <hl7:documentationOf typeCode="DOC">
        <hl7:serviceEvent classCode="ACT" moodCode="EVN">
          <hl7:code code="11502-2" codeSystem="2.16.840.1.113883.6.1" displayName="Laboratory Report"/>    <hl7:effectiveTime>
            <!-- include template 1.2.40.0.34.6.0.11.9.35 'Date Interval Information minimal' (dynamic) 1..1 M -->
          </hl7:effectiveTime>
          <hl7:performer typeCode="PRF">
            <hl7:templateId root="1.3.6.1.4.1.19376.1.3.3.1.7"/>      <hl7:assignedEntity>
              <!-- include template 1.2.40.0.34.6.0.11.9.22 'Assigned Entity' (dynamic) 1..1 M -->
            </hl7:assignedEntity>
          </hl7:performer>
        </hl7:serviceEvent>
      </hl7:documentationOf>
      ItemDTKardKonfBeschreibungLabel
      hl7:documentationOf
      Komponente für die Gesundheitsdienstleistung.
      (epi...ort)
      Treetree.png@typeCode
      cs0 … 1FDOC
      Treetree.pnghl7:serviceEvent
      1 … 1M(epi...ort)
      Treeblank.pngTreetree.png@classCode
      cs0 … 1FACT
      Treeblank.pngTreetree.png@moodCode
      cs0 … 1FEVN
      Treeblank.pngTreetree.pnghl7:code
      CE1 … 1M(epi...ort)
      Treeblank.pngTreeblank.pngTreetree.png@code
      CONF1 … 1F11502-2
      Treeblank.pngTreeblank.pngTreetree.png@codeSystem
      1 … 1F2.16.840.1.113883.6.1 (LOINC)
      Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
      1 … 1FLOINC
      Treeblank.pngTreeblank.pngTreetree.png@displayName
      1 … 1FLaboratory Report
      Treeblank.pngTreetree.pnghl7:effectiveTime
      IVL_TS1 … 1MDie Angabe eines zeitlichen Erbringungsintervalls effectiveTime mit einer Start- low und End-zeit high ist verpflichtend
      (epi...ort)
      Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.9.35 Date Interval Information minimal (DYNAMIC)
      Auswahl1 … 1Elemente in der Auswahl:
      • hl7:low[not(@nullFlavor)]
      • hl7:low[@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
      TS.DATE0 … 1(epi...ort)
      wo [not(@nullFlavor)]
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
      TS.DATE0 … 1(epi...ort)
      wo [@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
      cs1 … 1FUNK
      Auswahl1 … 1Elemente in der Auswahl:
      • hl7:high[not(@nullFlavor)]
      • hl7:high[@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
      TS.DATE0 … 1(epi...ort)
      wo [not(@nullFlavor)]
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
      TS.DATE0 … 1(epi...ort)
      wo [@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
      cs1 … 1FUNK
      Treeblank.pngTreetree.pnghl7:performer
      1 … 1MMeldendes Labor(epi...ort)
      Treeblank.pngTreeblank.pngTreetree.png@typeCode
      cs1 … 1FPRF
      Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
      II1 … 1M(epi...ort)
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
      uid1 … 1F1.3.6.1.4.1.19376.1.3.3.1.7
      Treeblank.pngTreeblank.pngTreetree.pnghl7:assignedEntity
      1 … 1M(epi...ort)
      Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC)
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
      cs0 … 1FASSIGNED
      Auswahl1 … 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
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
      II0 … *(epi...ort)
      wo [not(@nullFlavor)]
       
      Target.png
      elgaimpf-data​element-371Kyellow.png ID des Unterzeichners Kyellow.png Datensatz e-Impfpass 2019
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
      II0 … 1(epi...ort)
      wo [@nullFlavor='NI']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
      cs1 … 1FNI
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
      II0 … 1(epi...ort)
      wo [@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
      cs1 … 1FUNK
      Auswahl1 … 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']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
      0 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)(epi...ort)
      wo [not(@nullFlavor)]
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
      0 … 1(epi...ort)
      wo [@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
      cs1 … 1FUNK
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
      TEL.AT1 … 1M
      Beliebig viele Kontakt-Elemente der Person der Entität.
      Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.
      (epi...ort)
      wo [not(@nullFlavor)]
       
      Target.png
      elgaimpf-data​element-372Kyellow.png Kontaktdaten Kyellow.png Datensatz e-Impfpass 2019
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
      url1 … 1R
      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“
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
      cs0 … 1 
      Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP.
      Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
       ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
      1 … 1M
      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)
      (epi...ort)
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
      1 … 1M
      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)
      (epi...ort)
       
      Target.png
      elgaimpf-data​element-374Kyellow.png Organisation Kyellow.png Datensatz e-Impfpass 2019
       Schematron assertrole error 
       testcount(hl7:telecom)<2 or (count(hl7:telecom) = count(hl7:telecom[@use])) 
       MeldungDas Attribut telecom/@use MUSS bei allen telecom Elementen strukturiert sein. 


      7.2.1.18 Documentation Of Service Event - Microbiology Studies

      Id1.2.40.0.34.6.0.11.1.43Gültigkeit2020‑04‑22 13:03:07
      StatusKyellow.png EntwurfVersions-Label2020
      Nameepims_header_documentationOfServiceEventMicrobiologyAnzeigenameDocumentation Of Service Event - Microbiology Studies
      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!
      KlassifikationCDA Header Level Template
      Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
      Benutzt
      Benutzt 2 Templates
      Benutzt als NameVersion
      1.2.40.0.34.6.0.11.9.15InklusionKyellow.png Time Interval Information minimal (2019)DYNAMIC
      1.2.40.0.34.6.0.11.9.22InklusionKyellow.png Assigned Entity (2019)DYNAMIC
      BeziehungSpezialisierung: 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
      <hl7:documentationOf typeCode="DOC">
        <hl7:serviceEvent classCode="ACT" moodCode="EVN">
          <hl7:code code="18725-2" codeSystem="2.16.840.1.113883.6.1" displayName="Microbiology Studies"/>    <hl7:effectiveTime>
            <!-- include template 1.2.40.0.34.6.0.11.9.15 'Time Interval Information minimal' (dynamic) .. O -->
          </hl7:effectiveTime>
          <hl7:performer typeCode="PRF">
            <hl7:functionCode code="100" codeSystem="1.2.40.0.34.5.2" displayName="Ärztin/Arzt für Allgemeinmedizin"/>      <hl7:time>
              <!-- include template 1.2.40.0.34.6.0.11.9.15 'Time Interval Information minimal' (dynamic) .. O -->
            </hl7:time>
            <hl7:assignedEntity>
              <!-- include template 1.2.40.0.34.6.0.11.9.22 'Assigned Entity' (dynamic) 1..1 M -->
            </hl7:assignedEntity>
          </hl7:performer>
        </hl7:serviceEvent>
      </hl7:documentationOf>
      ItemDTKardKonfBeschreibungLabel
      hl7:documentationOf
      Komponente für die Gesundheitsdienstleistung.
      (epi...ogy)
      Treetree.png@typeCode
      cs0 … 1FDOC
      Treetree.pnghl7:serviceEvent
      1 … 1M(epi...ogy)
      Treeblank.pngTreetree.png@classCode
      cs0 … 1FACT
      Treeblank.pngTreetree.png@moodCode
      cs0 … 1FEVN
      Treeblank.pngTreetree.pnghl7:code
      CE1 … 1M(epi...ogy)
      Treeblank.pngTreeblank.pngTreetree.png@code
      CONF1 … 1F18725-2
      Treeblank.pngTreeblank.pngTreetree.png@codeSystem
      1 … 1F2.16.840.1.113883.6.1 (LOINC)
      Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
      1 … 1FLOINC
      Treeblank.pngTreeblank.pngTreetree.png@displayName
      1 … 1FMicrobiology Studies
      Treeblank.pngTreetree.pnghl7:effectiveTime
      IVL_TS1 … 1M(epi...ogy)
      Eingefügt von 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC)
      Auswahl1 … 1Elemente in der Auswahl:
      • hl7:low[@value]
      • hl7:low[@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
      TS.AT.TZ0 … 1(epi...ogy)
      wo [@value]
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
      TS.AT.TZ0 … 1(epi...ogy)
      wo [@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
      cs1 … 1FUNK
      Auswahl1 … 1Elemente in der Auswahl:
      • hl7:high[@value]
      • hl7:high[@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
      TS.AT.TZ0 … 1(epi...ogy)
      wo [@value]
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
      TS.AT.TZ0 … 1(epi...ogy)
      wo [@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
      cs1 … 1FUNK
      Treeblank.pngTreetree.pnghl7:performer
      0 … *RPerson 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.
      (epi...ogy)
      Treeblank.pngTreeblank.pngTreetree.png@typeCode
      cs1 … 1RZulä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)
      Treeblank.pngTreeblank.pngTreetree.pnghl7:functionCode
      CE0 … 1R
                                 Funktionscode
      
      (epi...ogy)
       CONF
      Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC)
      Treeblank.pngTreeblank.pngTreetree.pnghl7:time
      IVL_TS0 … 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
      (epi...ogy)
      Eingefügt von 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC)
      Auswahl1 … 1Elemente in der Auswahl:
      • hl7:low[@value]
      • hl7:low[@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
      TS.AT.TZ0 … 1(epi...ogy)
      wo [@value]
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
      TS.AT.TZ0 … 1(epi...ogy)
      wo [@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
      cs1 … 1FUNK
      Auswahl1 … 1Elemente in der Auswahl:
      • hl7:high[@value]
      • hl7:high[@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
      TS.AT.TZ0 … 1(epi...ogy)
      wo [@value]
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
      TS.AT.TZ0 … 1(epi...ogy)
      wo [@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
      cs1 … 1FUNK
      Treeblank.pngTreeblank.pngTreetree.pnghl7:assignedEntity
      1 … 1M(epi...ogy)
      Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC)
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
      cs0 … 1FASSIGNED
      Auswahl1 … 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
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
      II0 … *(epi...ogy)
      wo [not(@nullFlavor)]
       
      Target.png
      elgaimpf-data​element-371Kyellow.png ID des Unterzeichners Kyellow.png Datensatz e-Impfpass 2019
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
      II0 … 1(epi...ogy)
      wo [@nullFlavor='NI']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
      cs1 … 1FNI
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
      II0 … 1(epi...ogy)
      wo [@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
      cs1 … 1FUNK
      Auswahl1 … 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']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
      0 … 1Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC)(epi...ogy)
      wo [not(@nullFlavor)]
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
      0 … 1(epi...ogy)
      wo [@nullFlavor='UNK']
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
      cs1 … 1FUNK
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
      TEL.AT1 … 1M
      Beliebig viele Kontakt-Elemente der Person der Entität.
      Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.
      (epi...ogy)
      wo [not(@nullFlavor)]
       
      Target.png
      elgaimpf-data​element-372Kyellow.png Kontaktdaten Kyellow.png Datensatz e-Impfpass 2019
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@value
      url1 … 1R
      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“
      Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@use
      cs0 … 1 
      Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP.
      Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“
       ConstraintWerden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein.
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
      1 … 1M
      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)
      (epi...ogy)
      Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
      1 … 1M
      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)
      (epi...ogy)
       
      Target.png
      elgaimpf-data​element-374Kyellow.png Organisation Kyellow.png Datensatz e-Impfpass 2019
       Schematron assertrole error 
       testcount(hl7:telecom)<2 or (count(hl7:telecom) = count(hl7:telecom[@use])) 
       MeldungDas Attribut telecom/@use MUSS bei allen telecom Elementen strukturiert sein. 


      7.2.1.19 Documentation Of Service Event - Physician Note

      Id1.2.40.0.34.6.0.11.1.37Gültigkeit2020‑02‑20 10:55:54
      StatusKyellow.png EntwurfVersions-Label2020
      Nameepims_header_documentationOfServiceEventPhysicianNoteAnzeigenameDocumentation Of Service Event - Physician Note
      BeschreibungDieses ServiceEvent, in Kombination des ServiceEvents für "Infectious disease Note" kennzeichnen, dass dieses Dokument von einem Arzt/einer Ärztin ins EMS eingebracht wird.
        KlassifikationCDA Header Level Template
        Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
        Benutzt
        Benutzt 1 Template
        Benutzt als NameVersion
        1.2.40.0.34.6.0.11.9.35InklusionKyellow.png Date Interval Information minimal (2019)DYNAMIC
        BeziehungSpezialisierung: 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)
        ref
        ?

        Version: Template 1.2.40.0.34.11.20010 HeaderServiceEvent (2011‑12‑19)
        ref
        elgabbr-
        Beispiel
        Beispiel
        <hl7:documentationOf typeCode="DOC">
          <hl7:serviceEvent classCode="ACT" moodCode="EVN">
            <hl7:code code="75476-2" codeSystem="2.16.840.1.113883.6.1" displayName="Physician Note"/>    <hl7:effectiveTime>
              <!-- include template 1.2.40.0.34.6.0.11.9.35 'Date Interval Information minimal' (dynamic) 1..1 M -->
            </hl7:effectiveTime>
          </hl7:serviceEvent>
        </hl7:documentationOf>
        ItemDTKardKonfBeschreibungLabel
        hl7:documentationOf
        Komponente für die Gesundheitsdienstleistung.
        (epi...ote)
        Treetree.png@typeCode
        cs0 … 1FDOC
        Treetree.pnghl7:serviceEvent
        1 … 1M(epi...ote)
        Treeblank.pngTreetree.png@classCode
        cs0 … 1FACT
        Treeblank.pngTreetree.png@moodCode
        cs0 … 1FEVN
        Treeblank.pngTreetree.pnghl7:code
        CE1 … 1M(epi...ote)
        Treeblank.pngTreeblank.pngTreetree.png@code
        CONF1 … 1F75476-2
        Treeblank.pngTreeblank.pngTreetree.png@codeSystem
        1 … 1F2.16.840.1.113883.6.1 (LOINC)
        Treeblank.pngTreeblank.pngTreetree.png@codeSystemName
        1 … 1FLOINC
        Treeblank.pngTreeblank.pngTreetree.png@displayName
        1 … 1FPhysician Note
        Treeblank.pngTreetree.pnghl7:effectiveTime
        IVL_TS1 … 1MDie Angabe eines zeitlichen Erbringungsintervalls effectiveTime mit einer Start- low und End-zeit high ist verpflichtend
        (epi...ote)
        Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.9.35 Date Interval Information minimal (DYNAMIC)
        Auswahl1 … 1Elemente in der Auswahl:
        • hl7:low[not(@nullFlavor)]
        • hl7:low[@nullFlavor='UNK']
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
        TS.DATE0 … 1(epi...ote)
        wo [not(@nullFlavor)]
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
        TS.DATE0 … 1(epi...ote)
        wo [@nullFlavor='UNK']
        Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
        cs1 … 1FUNK
        Auswahl1 … 1Elemente in der Auswahl:
        • hl7:high[not(@nullFlavor)]
        • hl7:high[@nullFlavor='UNK']
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
        TS.DATE0 … 1(epi...ote)
        wo [not(@nullFlavor)]
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
        TS.DATE0 … 1(epi...ote)
        wo [@nullFlavor='UNK']
        Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
        cs1 … 1FUNK


        7.2.1.20 AssignedEntityElements

        Id1.2.40.0.34.11.90003
        ref
        elgabbr-
        Gültigkeit2011‑12‑19
        StatusKgreen.png AktivVersions-Label
        NameAssignedEntityElementsAnzeigenameAssignedEntityElements
        KlassifikationCDA Header Level Template
        Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
        Benutzt
        Benutzt 2 Templates
        Benutzt als NameVersion
        1.2.40.0.34.11.90001InklusionKgreen.png PersonElementsDYNAMIC
        1.2.40.0.34.11.90002InklusionKgreen.png OrganizationElementsDYNAMIC
        BeziehungVersion: Template 1.2.40.0.34.11.90003 AssignedEntityElements (2011‑12‑19)
        ref
        elgabbr-
        ItemDTKardKonfBeschreibungLabel
        hl7:id
        II1 … *R
        Mindestens eine Id der validierenden Person.
        Zugelassene nullFlavor: UNK
        (Ass...nts)
        hl7:addr
        AD0 … 1
        Ein Adress-Element der validierenden Person.
        Zugelassene nullFlavor: UNK
        (Ass...nts)
        hl7:telecom
        TEL.AT0 … *
        Mindestens ein Telecom-Element der validierenden Person.
        Zugelassene nullFlavor: UNK
        (Ass...nts)
        hl7:assigned​Person
        1 … 1MPersondendaten der validierenden Person.
        (Ass...nts)
        Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
        Treetree.png@classCode
        cs0 … 1FPSN
        Treetree.png@determiner​Code
        cs0 … 1FINSTANCE
        Treetree.pnghl7:name
        PN1 … 1M

        Name der Person

        Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!

        Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
        (Ass...nts)
        hl7:represented​Organization
        0 … 1Organistationsdaten der validierenden Person.
        (Ass...nts)
        Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
        Treetree.png@classCode
        0 … 1FORG
        Treetree.png@determiner​Code
        0 … 1FINSTANCE
        Treetree.pnghl7:id
        II0 … *(Ass...nts)
        Treetree.pnghl7:name
        ON1 … 1M(Ass...nts)
        Treetree.pnghl7:telecom
        TEL.AT0 … *(Ass...nts)
        Treetree.pnghl7:addr
        AD0 … 1(Ass...nts)


        7.2.1.21 PersonElements

        Id1.2.40.0.34.11.90001
        ref
        elgabbr-
        Gültigkeit2011‑12‑19
        StatusKgreen.png AktivVersions-Label
        NamePersonElementsAnzeigenamePersonElements
        KlassifikationCDA Header Level Template
        Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
        BeziehungVersion: Template 1.2.40.0.34.11.90001 PersonElements (2011‑12‑19)
        ref
        elgabbr-
        ItemDTKardKonfBeschreibungLabel
        @classCode
        cs0 … 1FPSN
        @determiner​Code
        cs0 … 1FINSTANCE
        hl7:name
        PN1 … 1M

        Name der Person

        Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!

        Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
        (Per...nts)


        7.2.1.22 OrganizationElements

        Id1.2.40.0.34.11.90002
        ref
        elgabbr-
        Gültigkeit2011‑12‑19
        StatusKgreen.png AktivVersions-Label
        NameOrganizationElementsAnzeigenameOrganizationElements
        KlassifikationCDA Header Level Template
        Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
        ItemDTKardKonfBeschreibungLabel
        @classCode
        0 … 1FORG
        @determiner​Code
        0 … 1FINSTANCE
        hl7:id
        II0 … *(Org...nts)
        hl7:name
        ON1 … 1M(Org...nts)
        hl7:telecom
        TEL.AT0 … *(Org...nts)
        hl7:addr
        AD0 … 1(Org...nts)


        7.2.1.23 Laboratory Performer 2

        Id1.2.40.0.34.11.4.3.3
        ref
        elgabbr-
        Gültigkeit2014‑12‑06
        StatusKgreen.png AktivVersions-Label
        NameLaboratoryPerformer2AnzeigenameLaboratory Performer 2
        BeschreibungElement zur Kennzeichnung einer Analyse, die in einem externen Labor durchgeführt wurde.
        KontextGeschwisterknoten des Template-Element mit Id 1.2.40.0.34.11.4.3.3
        KlassifikationCDA Header Level Template
        Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
        Benutzt
        Benutzt 2 Templates
        Benutzt als NameVersion
        1.2.40.0.34.11.90001InklusionKgreen.png PersonElementsDYNAMIC
        1.2.40.0.34.11.90002InklusionKgreen.png OrganizationElementsDYNAMIC
        BeziehungVersion: Template 1.2.40.0.34.11.4.3.3 Laboratory Performer 2 (2014‑12‑06)
        ref
        elgabbr-
        Beispiel
        Strukturbeispiel
        <component>
          <observation classCode="OBS" moodCode="EVN">
             ...     <performer typeCode="PRF">
              <templateId root="1.2.40.0.34.11.4.3.3"/>      <time value="20121201073406+0100"/>      <assignedEntity>
                <id nullFlavor="NI"/>        <code code="E" codeSystem="2.16.840.1.113883.2.16.1.4.9" codeSystemName="HL7.at.Laborkennzeichnung" displayName="EXTERN"/>        <addr> . . . </addr>        <telecom> . . . </telecom>        <assignedPerson> . . . </assignedPerson>        <representedOrganization> . . . </representedOrganization>      </assignedEntity>
            </performer>
          </observation>
        </component>
        ItemDTKardKonfBeschreibungLabel
        hl7:templateId
        1 … 1M(Lab...er2)
        Treetree.png@root
        uid1 … 1F1.2.40.0.34.11.4.3.3
        hl7:time
        IVL_TS1 … 1MZeitpunkt der Testdurchführung: Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“.(Lab...er2)
        hl7:assignedEntity
        1 … 1M(Lab...er2)
        Treetree.pnghl7:id
        II1 … 1R
        Identifikation der Person/Organi-sation: Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“.
        Zugelassene nullFlavor: NI

        (Lab...er2)
        Treetree.pnghl7:code
        CE0 … 1R(Lab...er2)
        Treeblank.pngTreetree.png@code
        CONF0 … 1FE
        Treeblank.pngTreetree.png@codeSystem
        0 … 1F2.16.840.1.113883.2.16.1.4.9
        Treeblank.pngTreetree.png@codeSystemName
        0 … 1FHL7.at.Laborkennzeichnung
        Treeblank.pngTreetree.png@displayName
        0 … 1FEXTERN
         Beispiel<code code="E" codeSystem="2.16.840.1.113883.2.16.1.4.9" codeSystemName="HL7.at.Laborkennzeichnung" displayName="EXTERN"/>
        Treetree.pnghl7:addr
        AD1 … 1MAdresse der Person/Organisation: Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“.
        (Lab...er2)
        Treetree.pnghl7:telecom
        TEL.AT1 … *MKontaktdaten der Person/Organisation: Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“.
        (Lab...er2)
        Auswahl1 … 
        Angabe von Personenname oder Organisationsname ist verpflichtend.
        Elemente in der Auswahl:
        • hl7:assigned​Person
        • hl7:represented​Organization
        Treeblank.pngTreetree.pnghl7:assigned​Person
         … 1Personenname: Es gelten die Vorgaben des Kapitels „Personen-Element“ des „Allgemeinen Implementierungsleitfadens“ .
        (Lab...er2)
        Eingefügt von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)
        Treeblank.pngTreeblank.pngTreetree.png@classCode
        cs0 … 1FPSN
        Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
        cs0 … 1FINSTANCE
        Treeblank.pngTreeblank.pngTreetree.pnghl7:name
        PN1 … 1M

        Name der Person

        Für den Namen ist verpflichtend Granularitätsstufe 2 („strukturierte Angabe des Namens‘‘) anzuwenden!

        Grundsätzlich sind die Vorgaben für „Namen-Elemente von Personen PN“ zu befolgen.
        (Lab...er2)
        Treeblank.pngTreetree.pnghl7:represented​Organization
         … 1Organisationsname: Es gelten die Vorgaben des Kapitels „Organisations-Element“ des „Allgemeinen Implementierungsleitfadens“.
        (Lab...er2)
        Eingefügt von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)
        Treeblank.pngTreeblank.pngTreetree.png@classCode
        0 … 1FORG
        Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
        0 … 1FINSTANCE
        Treeblank.pngTreeblank.pngTreetree.pnghl7:id
        II0 … *(Lab...er2)
        Treeblank.pngTreeblank.pngTreetree.pnghl7:name
        ON1 … 1M(Lab...er2)
        Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
        TEL.AT0 … *(Lab...er2)
        Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
        AD0 … 1(Lab...er2)


        7.2.2 Section Templates

        7.2.2.1 EMS Sektion - Arztmeldung

        Id1.2.40.0.34.6.0.11.2.78Gültigkeit2020‑02‑20 13:56:48
        StatusKyellow.png EntwurfVersions-Label2020
        Nameepims_section_EMSSectionArztmeldungAnzeigenameEMS Sektion - Arztmeldung
        KontextElternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.2.78
        KlassifikationCDA Section level template
        Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
        Benutzt
        Benutzt 7 Templates
        Benutzt als NameVersion
        1.2.40.0.34.6.0.11.3.56ContainmentKyellow.png Notification Organizer EMS Arztmeldung (2020)DYNAMIC
        1.2.40.0.34.6.0.11.3.93ContainmentKyellow.png EMS Organizer Arzt (2020)DYNAMIC
        1.2.40.0.34.6.0.11.3.60InklusionKyellow.png EMS Hospitalisierung (2020)DYNAMIC
        1.2.40.0.34.6.0.11.3.98InklusionKyellow.png EMS Problem Concern Entry (2020)DYNAMIC
        1.2.40.0.34.6.0.11.3.95InklusionKyellow.png EMS Organizer Tätigkeitsbereich (2020)DYNAMIC
        1.2.40.0.34.6.0.11.3.97ContainmentKyellow.png EMS Immunization Entry (2020)DYNAMIC
        1.2.40.0.34.6.0.11.3.28ContainmentKyellow.png Immunization Entry Impfung nicht angegeben (2019)DYNAMIC
        BeziehungAdaptation: Template 2.16.840.1.113883.10.12.701 CDA Section SDTC (2005‑09‑07)
        ref
        ad1bbr-

        Adaptation: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
        ref
        ad1bbr-
        Beispiel
        Beispiel
        <hl7:section classCode="DOCSECT" moodCode="EVN">
          <hl7:templateId root="1.2.40.0.34.6.0.11.2.78"/>  <hl7:id root="1.2.3.999" extension="--example only--"/>  <hl7:code code="3" codeSystem="1.2.40.0.34.5.189" displayName="EMS_Section"/>  <hl7:title>title</hl7:title>  <hl7:text/>  <hl7:entry typeCode="DRIV">
            <hl7:templateId root="1.3.6.1.4.1.19376.1.3.1"/>    <hl7:act moodCode="EVN" classCode="ACT">
              <hl7:code code="34782-3" codeSystem="2.16.840.1.113883.6.1" displayName="Infectious disease Note"/>      <hl7:statusCode code="completed"/>      <hl7:entryRelationship typeCode="COMP">
                <!-- template 1.2.40.0.34.6.0.11.3.56 'Notification Organizer EMS Arztmeldung' (2020-02-20T14:55:40) -->
              </hl7:entryRelationship>
              <hl7:entryRelationship typeCode="COMP">
                <!-- template 1.2.40.0.34.6.0.11.3.93 'EMS Organizer Arzt' (2020-04-22T15:46:30) -->
              </hl7:entryRelationship>
            </hl7:act>
          </hl7:entry>
          <hl7:entry>
            <!-- include template 1.2.40.0.34.6.0.11.3.60 'EMS Hospitalisierung' (dynamic) 1..1 R -->
          </hl7:entry>
          <hl7:entry>
            <!-- include template 1.2.40.0.34.6.0.11.3.98 'EMS Problem Concern Entry' (dynamic) 1..1 M -->
          </hl7:entry>
          <hl7:entry>
            <!-- include template 1.2.40.0.34.6.0.11.3.95 'EMS Organizer Tätigkeitsbereich' (dynamic) 1..1 M -->
          </hl7:entry>
          <!-- choice: 0..1
        element hl7:entry containing template 1.2.40.0.34.6.0.11.3.97 (dynamic)
        element hl7:entry containing template 1.2.40.0.34.6.0.11.3.28 (dynamic)
        -->
        </hl7:section>
        ItemDTKardKonfBeschreibungLabel
        hl7:section
        (epi...ung)
        Treetree.png@classCode
        cs0 … 1FDOCSECT
        Treetree.png@moodCode
        cs0 … 1FEVN
        Treetree.pnghl7:templateId
        II1 … 1M(epi...ung)
        Treeblank.pngTreetree.png@root
        uid1 … 1F1.2.40.0.34.6.0.11.2.78
        Treetree.pnghl7:id
        II0 … 1(epi...ung)
        Treetree.pnghl7:code
        CE1 … 1M(epi...ung)
        Treeblank.pngTreetree.png@code
        CONF1 … 1F3
        Treeblank.pngTreetree.png@codeSystem
        1 … 1F1.2.40.0.34.5.189
        Treeblank.pngTreetree.png@codeSystemName
        1 … 1FEMS_struktur_elemente
        Treeblank.pngTreetree.png@displayName
        1 … 1FEMS_Section
        Treetree.pnghl7:title
        ST1 … 1MDer Titel der Sektion kann vom Ersteller frei vergeben werden. Möglich wäre die Wiederholung des Dokumententitels (z.b. Labormeldung oder Arztmeldung)(epi...ung)
        Treetree.pnghl7:text
        SD.TEXT1 … 1MDie Inhalt als auch die textuelle Gestaltung des section/text-Elements obliegt dem Ersteller. Sinngemäße Angaben der in den Level 3 codierten Inhalte sollten hier geführt werden.


        Im Falle einer Labormeldung sollten Informationen wie die Probeninformation, die meldepflichtige Krankheit sowie etwaige Analyseergebnisse angegeben werden. Die Struktur (z.B. Tabellen) kann analog zum ELGA Laborleitfaden angewendet werden.


        Im Falle einer Arztmeldung sollten Informationen zur meldepflichtigen Krankheit (inkl. Diagnosesicherheit), Angabe zum Todesdatum (wenn Patient/Patientin verstorben ist) sowie etwaige Auslandsaufenthalte angegeben werden.
        (epi...ung)
        Treetree.pnghl7:entry
        1 … 1M(epi...ung)
        Treeblank.pngTreetree.png@typeCode
        cs0 … 1FDRIV
        Treeblank.pngTreetree.pnghl7:templateId
        II1 … 1M(epi...ung)
        Treeblank.pngTreeblank.pngTreetree.png@root
        uid1 … 1F1.3.6.1.4.1.19376.1.3.1
        Treeblank.pngTreetree.pnghl7:act
        1 … 1M(epi...ung)
        Treeblank.pngTreeblank.pngTreetree.png@moodCode
        cs1 … 1FEVN
        Treeblank.pngTreeblank.pngTreetree.png@classCode
        cs1 … 1FACT
        Treeblank.pngTreeblank.pngTreetree.pnghl7:code
        CE1 … 1M(epi...ung)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
        CONF1 … 1F34782-3
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
        1 … 1F2.16.840.1.113883.6.1 (LOINC)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
        1 … 1FLOINC
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
        1 … 1FInfectious disease Note
        Treeblank.pngTreeblank.pngTreetree.pnghl7:statusCode
        CS (erforderlich)1 … 1M(epi...ung)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
        CONF1 … 1Fcompleted
        Treeblank.pngTreeblank.pngTreetree.pnghl7:entryRelationship
        1 … 1MBeinhaltet 1.2.40.0.34.6.0.11.3.56 Notification Organizer EMS Arztmeldung (DYNAMIC)(epi...ung)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
        cs1 … 1FCOMP
        Treeblank.pngTreeblank.pngTreetree.pnghl7:entryRelationship
        0 … 1RBeinhaltet 1.2.40.0.34.6.0.11.3.93 EMS Organizer Arzt (DYNAMIC)(epi...ung)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
        cs1 … 1FCOMP
        Treetree.pnghl7:entry
        0 … 1RAngaben zur (geplanten) Hospitalisierung(epi...ung)
        Eingefügt1 … 1R von 1.2.40.0.34.6.0.11.3.60 EMS Hospitalisierung (DYNAMIC)
        Treeblank.pngTreetree.pnghl7:act
        1 … 1R(epi...ung)
        Treeblank.pngTreeblank.pngTreetree.png@classCode
        cs1 … 1FACT
        Treeblank.pngTreeblank.pngTreetree.png@moodCode
        cs1 … 1FEVN
        Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
        II1 … 1M(epi...ung)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
        uid1 … 1F1.2.40.0.34.11.6.3.6
        Treeblank.pngTreeblank.pngTreetree.pnghl7:code
        CE1 … 1M(epi...ung)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
        CONF1 … 1F77974-4
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
        1 … 1F2.16.840.1.113883.6.1 (LOINC)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
        1 … 1FLOINC
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
        1 … 1FPatient was hospitalized because of this condition
        Treeblank.pngTreeblank.pngTreetree.pnghl7:effectiveTime
        IVL_TS0 … 1Zeitpunkt der (geplanten) Hospitalisierung(epi...ung)
        Treetree.pnghl7:entry
        0 … 1RAngaben zur klinischen Manifestation(epi...ung)
        Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.3.98 EMS Problem Concern Entry (DYNAMIC)
        Treeblank.pngTreetree.pnghl7:act
        1 … 1MIHE PCC TF2 Rev.11, 6.3.4.12
        Treeblank.pngTreeblank.pngTreetree.png@classCode
        cs1 … 1FACT
        Treeblank.pngTreeblank.pngTreetree.png@moodCode
        cs1 … 1FEVN
        Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
        II1 … 1MIHE PCC TF2 Rev.11, 6.3.4.12
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
        uid1 … 1F1.2.40.0.34.6.0.11.3.98
        Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
        II1 … 1MELGAIHE PCC TF2 Rev.11, 6.3.4.12
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
        uid1 … 1F1.2.40.0.34.6.0.11.3.7
        Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
        II1 … 1MHL7 CCD Problem actIHE PCC TF2 Rev.11, 6.3.4.12
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
        uid1 … 1F2.16.840.1.113883.10.20.1.27
        Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
        II1 … 1MIHE PCC Concern EntryIHE PCC TF2 Rev.11, 6.3.4.12
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
        uid1 … 1F1.3.6.1.4.1.19376.1.5.3.1.4.5.1
        Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
        II1 … 1M IHE PCC Problem Concern EntryIHE PCC TF2 Rev.11, 6.3.4.12
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
        uid1 … 1F1.3.6.1.4.1.19376.1.5.3.1.4.5.2
        Treeblank.pngTreeblank.pngTreetree.pnghl7:id
        II1 … 1M
        ID des Problem/Bedenken-Entry
        Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen.
        IHE PCC TF2 Rev.11, 6.3.4.12
        Treeblank.pngTreeblank.pngTreetree.pnghl7:code
        CE1 … 1RCode des Problem/Bedenken-Entry.
        IHE PCC TF2 Rev.11, 6.3.4.12
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@nullFlavor
        cs1 … 1FNA
        Treeblank.pngTreeblank.pngTreetree.pnghl7:statusCode
        CS1 … 1MDer statusCode zeigt den derzeitigen Zustand an, in dem sich das Problem/Bedenken befindet.
        IHE PCC TF2 Rev.11, 6.3.4.12
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
        CONF1 … 1Factive
        Treeblank.pngTreeblank.pngTreetree.pnghl7:effectiveTime
        IVL_TS1 … 1R
        Zeitintervall in dem das Problem/Bedenken existent war/ist.
        Grundsätzlich sind die Vorgaben gemäß Kapitel „Zeit-Elemente“ zu befolgen.


        Anforderung in Abhängigkeit von „statusCode“:
        Ist das Element statusCode auf „active“ oder „suspended“ gesetzt, MUSS das high-Element des Zeitintervalls weggelassen werden.
        IHE PCC TF2 Rev.11, 6.3.4.12
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:low
        TS.AT.TZ1 … 1RBeginn des Intervalls.IHE PCC TF2 Rev.11, 6.3.4.12
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:high
        TS.AT.TZ0 … 1CEnde des Intervalls.IHE PCC TF2 Rev.11, 6.3.4.12
         Schematron assertrole error 
         testcount(hl7:statusCode[@code='active'])=0 or count(hl7:effectiveTime/hl7:high)=0 
         MeldungIst das Element statusCode auf „active“ gesetzt, muss das high-Element des Zeitintervalls weggelassen werden. 
        Treeblank.pngTreeblank.pngTreetree.pnghl7:entryRelationship
        1 … *MBeinhaltet 1.2.40.0.34.6.0.11.3.99 EMS Problem Entry (DYNAMIC)IHE PCC TF2 Rev.11, 6.3.4.12
        wo [@typeCode='SUBJ']
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
        cs1 … 1FSUBJ
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@context​Conduction​Ind
        cs0 … 1Ftrue
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@inversionInd
        bl1 … 1Ffalse
        Treetree.pnghl7:entry
        0 … 1RAngabe zum (beruflichen) Tätigkeitsbereichs des Patienten/der Patientin.(epi...ung)
        Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.3.95 EMS Organizer Tätigkeitsbereich (DYNAMIC)
        Treeblank.pngTreetree.pnghl7:organizer
        1 … 1M(epi...ung)
        Treeblank.pngTreeblank.pngTreetree.png@classCode
        cs1 … 1FBATTERY
        Treeblank.pngTreeblank.pngTreetree.png@moodCode
        cs1 … 1FEVN
        Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
        II1 … 1M(epi...ung)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
        uid1 … 1F1.2.40.0.34.6.0.11.3.95
        Treeblank.pngTreeblank.pngTreetree.pnghl7:code
        CE1 … 1M(epi...ung)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystemName
        st0 … 1FEMS_struktur_elemente
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@displayName
        st0 … 1FEMS_Organizer_Taetigkeitsbereich
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
        CONF1 … 1F40
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
        1 … 1F1.2.40.0.34.5.189
        Treeblank.pngTreeblank.pngTreetree.pnghl7:statusCode
        CS1 … 1M(epi...ung)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@code
        CONF1 … 1Fcompleted
        Treeblank.pngTreeblank.pngTreetree.pnghl7:component
        1 … *RAngabe der einzelnen Tätigkeitsfelder(epi...ung)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
        cs1 … 1FCOMP
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@context​Conduction​Ind
        bl0 … 1 
        Eingefügt1 … 1M von 1.2.40.0.34.6.0.11.3.94 EMS Act Tätigkeitsbereich (DYNAMIC)
        Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:act
        1 … 1M(epi...ung)
        Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@moodCode
        cs1 … 1FEVN
        Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
        cs1 … 1FINFRM
        Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:code
        CD1 … 1M(epi...ung)
         CONF
        Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.21 EMS Tätigkeitsbereich VS (DYNAMIC)
        Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:effectiveTime
        IVL_TS0 … 1Angabe des Zeitraums der Tätigkeit(epi...ung)
        Auswahl0 … 1
        Für impfpräventable Krankheiten MUSS hier die Angabe über eine Impfung bzw. die Information, dass nicht geimpft wurde angegeben werden.
        Elemente in der Auswahl:
        • hl7:entry welches enthält Template 1.2.40.0.34.6.0.11.3.97 EMS Immunization Entry (DYNAMIC)
        • hl7:entry welches enthält Template 1.2.40.0.34.6.0.11.3.28 Immunization Entry Impfung nicht angegeben (DYNAMIC)
        Treeblank.pngTreetree.pnghl7:entry
        0 … 1RBeinhaltet 1.2.40.0.34.6.0.11.3.97 EMS Immunization Entry (DYNAMIC)(epi...ung)
        Treeblank.pngTreetree.pnghl7:entry
        0 … 1RBeinhaltet 1.2.40.0.34.6.0.11.3.28 Immunization Entry Impfung nicht angegeben (DYNAMIC)(epi...ung)


        7.2.2.2 EMS Sektion - Labormeldung

        Id1.2.40.0.34.6.0.11.2.86Gültigkeit2020‑04‑22 14:41:21
        StatusKyellow.png EntwurfVersions-Label2020
        Nameepims_section_EMSSectionLabormeldungAnzeigenameEMS Sektion - Labormeldung
        KlassifikationCDA Section level template
        Offen/GeschlossenGeschlossen (nur definierte Elemente sind erlaubt)
        Benutzt
        Benutzt 3 Templates
        Benutzt als NameVersion
        1.2.40.0.34.6.0.11.3.55ContainmentKyellow.png EMS Abnahmeinformationen (Specimen Collection) (2020)DYNAMIC
        1.2.40.0.34.6.0.11.3.92ContainmentKyellow.png Notification Organizer EMS Labormeldung (2020)DYNAMIC
        1.2.40.0.34.6.0.11.3.61ContainmentKyellow.png EMS Organizer Labor (2020)DYNAMIC
        BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.701 CDA Section SDTC (2005‑09‑07)
        ref
        ad1bbr-

        Adaptation: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
        ref
        ad1bbr-
        Beispiel
        Beispiel
        <hl7:section classCode="DOCSECT" moodCode="EVN">
          <hl7:templateId root="1.3.6.1.4.1.19376.1.3.3.2.1"/>  <hl7:id root="1.2.3.999" extension="--example only--"/>  <hl7:code code="3" codeSystem="1.2.40.0.34.5.189" displayName="EMS_Section"/>  <hl7:title>title</hl7:title>  <hl7:text/>  <hl7:entry typeCode="DRIV">
            <hl7:templateId root="1.3.6.1.4.1.19376.1.3.1"/>    <hl7:act moodCode="EVN" classCode="ACT">
              <hl7:code code="34782-3" codeSystem="2.16.840.1.113883.6.1" displayName="Infectious disease Note"/>      <hl7:statusCode code="completed"/>      <hl7:entryRelationship xsi:type="ANY" typeCode="COMP">
                <!-- template 1.2.40.0.34.6.0.11.3.55 'EMS Abnahmeinformationen (Specimen Collection)' (2020-02-20T14:17:08) -->
              </hl7:entryRelationship>
              <hl7:entryRelationship typeCode="COMP">
                <!-- template 1.2.40.0.34.6.0.11.3.92 'Notification Organizer EMS Labormeldung' (2020-04-22T15:35:09) -->
              </hl7:entryRelationship>
              <hl7:entryRelationship typeCode="COMP">
                <!-- template 1.2.40.0.34.6.0.11.3.61 'EMS Organizer Labor' (2020-02-20T16:12:29) -->
              </hl7:entryRelationship>
            </hl7:act>
          </hl7:entry>
        </hl7:section>
        ItemDTKardKonfBeschreibungLabel
        hl7:section
        (epi...ung)
        Treetree.png@classCode
        cs0 … 1FDOCSECT
        Treetree.png@moodCode
        cs0 … 1FEVN
        Treetree.pnghl7:templateId
        II1 … 1M(epi...ung)
        Treeblank.pngTreetree.png@root
        uid1 … 1F1.3.6.1.4.1.19376.1.3.3.2.1
        Treetree.pnghl7:id
        II0 … 1(epi...ung)
        Treetree.pnghl7:code
        CE1 … 1M(epi...ung)
        Treeblank.pngTreetree.png@code
        CONF1 … 1F3
        Treeblank.pngTreetree.png@codeSystem
        1 … 1F1.2.40.0.34.5.189
        Treeblank.pngTreetree.png@codeSystemName
        1 … 1FEMS_struktur_elemente
        Treeblank.pngTreetree.png@displayName
        1 … 1FEMS_Section
        Treetree.pnghl7:title
        ST1 … 1MDer Titel der Sektion kann vom Ersteller frei vergeben werden. Möglich wäre die Wiederholung des Dokumententitels (z.b. Labormeldung oder Arztmeldung)(epi...ung)
        Treetree.pnghl7:text
        SD.TEXT1 … 1MDie Inhalt als auch die textuelle Gestaltung des section/text-Elements obliegt dem Ersteller. Sinngemäße Angaben der in den Level 3 codierten Inhalte sollten hier geführt werden.


        Im Falle einer Labormel