Epidemiologisches Meldesystem - Labor und Arzt

CDA Implementierungsleitfaden

HL7 Implementation Guide for CDA^® R2:
Implementierungsleitfaden Meldung an das Epidemiologische Meldesystem (EMS) – Labor-und Arztmeldung

Zur Anwendung im österreichischen
Gesundheitswesen [1.2.40.0.34.7.22.1]

2021.01.28

2020

Normativ

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 und insbesondere auf dem ELGA Implementierungsleitfaden „HL7 Implementation Guide for CDA® R2: Laborbefund“ zur Anwendung im österreichischen Gesundheitswesen, 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

7 Technische Spezifikation

7.1 Übersicht CDA Strukturen (Header & Body)

Folgende informative Tabelle stellt die relevanten Informationselemente und Inhalte dar, welche im Zuge einer Labor- oder Arztmeldung relevant sind bzw. benötigt werden.

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 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]
Vorgesehener Empfänger	ClinicalDocument/informationRecipient	M [1..1]
Rechtlicher Unterzeichner	ClinicalDocument/legalAuthenticator	M [1..1]
Validatoren	ClinicalDocument/authenticator	O [0..*]
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[2]/ serviceEvent/performer	M [1..1]	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 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)
• 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 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).

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 Document Level Templates

7.2.1.1 Arztmeldung

Id	1.2.40.0.34.6.0.11.0.8	Gültigkeit	2020‑02‑20 08:35:37
Status	Entwurf	Versions-Label	2020
Name	epims_document_arztmeldung	Bezeichnung	Arztmeldung
Kontext	Pfadname /
Klassifikation	CDA Document Level Template
Offen/Geschlossen	Geschlossen (nur definierte Elemente sind erlaubt)
Benutzt	Benutzt 18 Templates Benutzt als Name Version 1.2.40.0.34.6.0.11.1.10 Inklusion Document Realm (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.30 Inklusion Document TypeId (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.1 Inklusion Document Id (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.11 Inklusion Document Effective Time (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.12 Inklusion Document Confidentiality Code (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.13 Inklusion Document Language (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.15 Inklusion Document Set Id and Version Number (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.34 Inklusion Record Target - EMS (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.2 Inklusion Author (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.4 Inklusion Custodian (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.5 Inklusion Legal Authenticator (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.6 Inklusion Authenticator (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.35 Inklusion Information Recipient - EMS (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.21 Inklusion Participant Ein-, Ueber-, Zuweisender Arzt (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.9 Inklusion In Fulfillment Of (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.36 Inklusion Documentation Of Service Event - Infectious disease Note (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.37 Inklusion Documentation Of Service Event - Physician Note (2020.1) DYNAMIC 1.2.40.0.34.6.0.11.2.78 Containment EMS Sektion - Arztmeldung (2020) DYNAMIC
Item DT Kard Konf Beschreibung Label hl7:ClinicalDocument (epi...ung) @classCode cs 0 … 1 F DOCCLIN @moodCode cs 0 … 1 F EVN Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.10 Document Realm (DYNAMIC) Kennzeichnung aus welchem Land das Dokument stammt hl7:realmCode CS 1 … 1 M Hoheitsbereich des Dokuments. Fester Wert: @code = AT (aus ValueSet „ELGA_RealmCode“) (epi...ung) @code 1 … 1 F AT Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.30 Document TypeId (DYNAMIC) Kennzeichnung, dass das Dokument in CDA R2 Format vorliegt hl7:typeId II 1 … 1 M Dokumentformat CDA R2 (epi...ung) @root uid 1 … 1 F 2.16.840.1.113883.1.3 @extension st 1 … 1 F POCD_HD000040 hl7:templateId II 1 … 1 M templateId für Dokumente welche den Basisanforderungen für ELGA genügen (epi...ung) @root uid 1 … 1 F 1.2.40.0.34.11.1 hl7:templateId II 1 … 1 M templateId für EMS-Meldungen (epi...ung) @root uid 1 … 1 F 1.2.40.0.34.11.6 hl7:templateId II 1 … 1 M templateId für die Arztmeldung ins EMS (epi...ung) @root uid 1 … 1 F 1.2.40.0.34.11.6.0.2 Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.1 Document Id (DYNAMIC) weltweit eindeutiger Identifier für das Dokument (Befundnummer) hl7:id II 1 … 1 M Dokumenten-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. (epi...ung) @root uid 1 … 1 R hl7:code CE 1 … 1 M (epi...ung) @code CONF 1 … 1 F 34782-3 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) @codeSystemName 1 … 1 F LOINC @displayName 1 … 1 F Infectious disease Note hl7:title ST 1 … 1 M Der Titel des Dokumentes ist verpflichtend anzugeben, vom Ersteller frei zu vergeben und beschreibt die Art des Dokumentes näher. Der Titel des Dokuments ist für den lesenden Dokumentempfänger das sichtbare Element. Ein Beispiel wäre "Arztmeldung". (epi...ung) Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.11 Document Effective Time (DYNAMIC) Dieser Zeitstempel entspricht dem Meldedatum hl7:effectiveTime TS.AT.TZ 1 … 1 M Relevantes Datum des Dokuments. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. (epi...ung)   at-cda-bbr-data​element-11  Erstellungsdatum  Dataset A 2019 Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.12 Document Confidentiality Code (DYNAMIC) hl7:confidentialityCode CE 1 … 1 M Vertraulichkeitscode des Dokuments aus ValueSet „ELGA_Confidentiality“.  (epi...ung)   at-cda-bbr-data​element-13  Vertraulichkeitscode  Dataset A 2019 @codeSystemName st 1 … 1 F HL7:Confidentiality   Constraint Für ELGA-Dokumente ist ausschließlich "N" erlaubt! Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.13 Document Language (DYNAMIC) hl7:language​Code CS.LANG 1 … 1 M Sprachcode des Dokuments. (epi...ung)   at-cda-bbr-data​element-14  Sprachcode  Dataset A 2019 @code cs 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.10 atcdabbr_LanguageCode (DYNAMIC)   Constraint Für ELGA ist in @code für CDA und Ableitungen in die XDSDocumentEntry-Metadaten derzeit ausschließlich der Wert "de-AT" zulässig. Für eHealth und zukünftige Versionen der ELGA Leitfäden können weitere Sprachcodes erlaubt werden. Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.15 Document Set Id and Version Number (DYNAMIC) hl7:setId II 1 … 1 M 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. (epi...ung) hl7:versionNumber INT.​NONNEG 1 … 1 M Versionsnummer 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. (epi...ung) @value int 1 … 1 R Versionsnummer als positive ganze Zahl. Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.34 Record Target - EMS (DYNAMIC) 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). hl7:recordTarget 1 … 1 M Komponente für die Patientendaten. (epi...ung) @typeCode cs 0 … 1 F RCT @context​Control​Code cs 0 … 1 F OP hl7:patientRole 1 … 1 M Patientendaten. (epi...ung) @classCode cs 0 … 1 F PAT hl7:id II 2 … * R Patientenidentifikatoren (epi...ung)   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) hl7:addr 0 … 2 R 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...ung)   Constraint Werden mehrere address-Elemente strukturiert (z.B. Home, Pflege), MUSS jeweils das Attribut @use angeführt sein. hl7:telecom TEL.AT 0 … * R Kontakt-Element. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen. (epi...ung) @value url 1 … 1 R 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“ @use cs 0 … 1   Bedeutung des angegebenen Kontakts (z.B Heim, Arbeitsplatz), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:patient 1 … 1 M Name 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...ung) Auswahl 1 … 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'] hl7:administrative​Gender​Code CE 0 … 1 (epi...ung) wo [not(@nullFlavor)] @displayName st 1 … 1 R @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.1 @codeSystemName st 0 … 1 F HL7:AdministrativeGender   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC) hl7:administrative​Gender​Code CE 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK Auswahl 1 … 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'] hl7:birthTime TS.DATE 0 … 1 (epi...ung) hl7:birthTime TS.DATE 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK sdtc:deceasedInd BL 0 … 1 Indikator ob Patient/Patientin verstorben ist (epi...ung) sdtc:deceasedTime TS.DATE 0 … 1 Angabe des Sterbedatums (epi...ung) hl7:marital​Status​Code CE 0 … 1 R Codierung des Familienstands des Patienten. Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“ (epi...ung) @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.2 @codeSystemName st 1 … 1 F HL7:MaritalStatus @displayName st 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.11 ELGA_MaritalStatus (DYNAMIC) hl7:religious​Affiliation​Code CE 0 … 1 R Codierung des Religionsbekenntnisses des Patienten. Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“ (epi...ung) @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.2.16.1.4.1 @codeSystemName st 1 … 1 F HL7.AT:ReligionAustria @displayName st 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.18 ELGA_ReligiousAffiliation (DYNAMIC) hl7:raceCode NP Rasse des Patienten Darf nicht verwendet werden! (epi...ung) hl7:ethnic​Group​Code NP Ethnische Zugehörigkeit des Patienten. Darf nicht verwendet werden! (epi...ung) hl7:guardian 0 … * R Gesetzlicher 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...ung) @classCode cs 0 … 1 F GUARD hl7:addr 0 … 1 R 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...ung) hl7:telecom TEL.AT 0 … * R Beliebig viele Kontaktdaten des gesetzlichen Vertreters als Person oder Organisation. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen. (epi...ung) @value st 1 … 1 R 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“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (z.B. Heim, Arbeitsplatz) Bsp: WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. Auswahl 1 … 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) hl7:guardian​Person 0 … 1 Name 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...ung) hl7:guardian​Person 0 … 1 Name 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...ung) hl7:guardian​Organization 0 … 1 R Name des gesetzlichen Vertreters (Organisation) Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) (epi...ung) hl7:birthplace 0 … 1 R Geburtsort des Patienten. (epi...ung) @classCode cs 0 … 1 F BIRTHPL hl7:place 1 … 1 M (epi...ung) @classCode cs 0 … 1 F PLC @determiner​Code cs 0 … 1 F INSTANCE Auswahl 1 … 1 Elemente 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) hl7:addr AD 0 … 1 Angaben zum Geburtsorts. Im Kontext der Arztmeldung an das EMS wird EMPFOHLEN das Geburtsland als Klartext zu übermitteln (und nicht als ISO-2/3 Code). Das bedeutet es SOLL, "Österreich" und nicht "AUT" oder "AT", angegeben werden. Beinhaltet 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) (epi...ung) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts, struktuiert. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (epi...ung) hl7:language​Communication 0 … * R Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten. (epi...ung) hl7:language​Code CS 1 … 1 M Sprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen). (epi...ung) @code cs 1 … 1 R Zulä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) hl7:modeCode CE 0 … 1 R Ausdrucksform der Sprache. Zulässige Werte gemäß Value-Set „ELGA_LanguageAbilityMode“ (epi...ung) @code cs 1 … 1 R @displayName st 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.60 @codeSystemName st 0 … 1 F HL7:LanguageAbilityMode   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC) hl7:proficiency​Level​Code CE 0 … 1 R Grad der Sprachkenntnis in der Sprache. Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“ (epi...ung) @code cs 1 … 1 R @displayName st 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.61 @codeSystemName st 0 … 1 F HL7:LanguageAbilityProficiency   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.174 ELGA_ProficiencyLevelCode (DYNAMIC) hl7:preference​Ind BL 0 … 1 R Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird. (epi...ung)   Schematron assert role  error     test not(hl7:id[1]/@nullFlavor)     Meldung Die Verwendung von id/@nullFlavor ist an dieser Stelle NICHT ERLAUBT.     Schematron assert role  error     test not(hl7:id[2]/@nullFlavor) or (hl7:id[2][@nullFlavor='UNK'] or hl7:id[2][@nullFlavor='NI'])     Meldung Zugelassene nullFlavor sind "NI" und "UNK"   Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.2 Author (DYNAMIC) hl7:author 1 … 1 M Verfasser des Dokuments. (epi...ung) @typeCode cs 0 … 1 F AUT @context​Control​Code cs 0 … 1 F OP hl7:functionCode CE (extensible) 0 … 1 R Funktionscode des Verfassers des Dokuments, z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“. Eigene Codes und Bezeichnungen können verwendet werden. (epi...ung) @code cs 1 … 1 R @codeSystem oid 1 … 1 R @displayName st 1 … 1 R Auswahl 1 … 1 Der Zeitpunkt an dem das Dokument verfasst, bzw. inhaltlich fertiggestellt wurde. Elemente in der Auswahl: hl7:time[not(@nullFlavor)] hl7:time[@nullFlavor='UNK'] hl7:time TS.AT.TZ 0 … 1 (epi...ung) wo [not(@nullFlavor)] hl7:time TS.AT.TZ 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:assignedAuthor 1 … 1 M (epi...ung) @classCode cs 0 … 1 F ASSIGNED Auswahl 1 … * 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']   Constraint Zugelassene 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 hl7:id II 0 … * Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software. ODER Identifikation des/der datenerstellenden Gerätes/Software.  (epi...ung) wo [not(@nullFlavor)] hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='NI'] @nullFlavor cs 1 … 1 F NI hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:code CE 0 … 1 R Angabe der Fachrichtung des Verfassers des Dokuments („Sonderfach“ gem. Ausbildungsordnung), z.B: „Facharzt/Fachärztin 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. (epi...ung) @codeSystem oid 1 … 1 R @displayName st 1 … 1 R @code cs 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC) hl7:telecom TEL.AT 0 … * Kontaktdaten des Verfassers des Dokuments. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (epi...ung) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. Auswahl 1 … 1 Elemente 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) hl7: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) (epi...ung) hl7:assigned​Authoring​Device 0 … 1 Datenerstellendes Gerät Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC) (epi...ung) hl7:represented​Organization 1 … 1 M Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. ↔ Hinweis zum XDS-Mapping: Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, soll das name Element SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird.  Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" -->  "Wien AKH" bzw "Wien AKH - Augenambulanz"  Beinhaltet 1.2.40.0.34.6.0.11.9.5 Organization Compilation with id, name (DYNAMIC) (epi...ung)   Constraint id MUSS der OID der Organisation aus dem GDA-Index entsprechen. name SOLL der Kurzbezeichnung im GDA-I entsprechen (sofern vorhanden) Zu dem Namen größerer Organisationen SOLL auch die Abteilung angegeben werden., z.B.: „Amadeus Spital, Chirurgische Abteilung“ Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.4 Custodian (DYNAMIC) hl7:custodian 1 … 1 M Verwahrer des Dokuments. (epi...ung)   at-cda-bbr-data​element-24  Verwahrer  Dataset A 2019 @typeCode cs 0 … 1 F CST hl7:assignedCustodian 1 … 1 M (epi...ung) @classCode cs 0 … 1 F ASSIGNED hl7:represented​Custodian​Organization 1 … 1 M (epi...ung) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 1 … * M Identifikation des Verwahrers des Dokuments, wie im GDA-Index angegeben. Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen. (epi...ung) hl7:name ON 1 … 1 M Name des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Namen-Elemente von Organisationen ON“ zu befolgen. (epi...ung) hl7:telecom TEL.AT 0 … * Kontaktdaten des Verwahrers des originalen Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen. (epi...ung) wo [not(@nullFlavor)] @value st 1 … 1 R @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:addr AD 1 … 1 M Adresse 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) (epi...ung) Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.5 Legal Authenticator (DYNAMIC) hl7:legalAuthenticator 1 … 1 M Hauptunterzeichner, Rechtlicher Unterzeichner (epi...ung)   elgaimpf-data​element-368  Unterzeichnende Person (Dokument)  Datensatz e-Impfpass 2019 at-cda-bbr-data​element-1  Rechtlicher Unterzeichner  Dataset A 2019 @context​Control​Code cs 0 … 1 F OP @typeCode cs 0 … 1 F LA Auswahl 1 … 1 Der Zeitpunkt, an dem das Dokument unterzeichnet wurde. Elemente in der Auswahl: hl7:time[not(@nullFlavor)] hl7:time[@nullFlavor='UNK'] hl7:time TS.AT.TZ 0 … 1 (epi...ung) wo [not(@nullFlavor)]   at-cda-bbr-data​element-5  Zeitpunkt der Unterzeichnung  Dataset A 2019 elgaimpf-data​element-369  Zeitpunkt der Unterzeichnung  Datensatz e-Impfpass 2019 hl7:time TS.AT.TZ 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:signatureCode CS 1 … 1 M Signaturcode gibt an, dass das Originaldokument unterzeichnet wurde. (epi...ung)   elgaimpf-data​element-370  Signatur  Datensatz e-Impfpass 2019 at-cda-bbr-data​element-6  Signatur  Dataset A 2019 @code CONF 1 … 1 F S hl7:assignedEntity 1 … 1 M Personendaten 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) (epi...ung) Eingefügt 0 … * von 1.2.40.0.34.6.0.11.1.6 Authenticator (DYNAMIC) hl7:authenticator 0 … * Weitere Unterzeichner. (epi...ung)   at-cda-bbr-data​element-31  Weitere Unterzeichner  Dataset A 2019 @typeCode cs 0 … 1 F AUTHEN Auswahl 1 … 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'] hl7:time TS.AT.TZ 0 … 1 (epi...ung) wo [not(@nullFlavor)]   at-cda-bbr-data​element-105  Zeitpunkt der Unterzeichnung  Dataset A 2019 hl7:time TS.AT.TZ 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:signatureCode CS 1 … 1 M (epi...ung)   at-cda-bbr-data​element-106  Signatur  Dataset A 2019 @code CONF 1 … 1 F S hl7:assignedEntity 1 … 1 M Personendaten des weiteren Unterzeichners. Grundsätzlich sind die Vorgaben gemäß Kapitel „AssignedEntity-Element (Person + Organisation)“ zu befolgen. (epi...ung) Eingefügt von 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC) @classCode cs 0 … 1 F ASSIGNED Auswahl 1 … * Mindestens eine ID der Person der Entität Elemente in der Auswahl: hl7:id[not(@nullFlavor)] hl7:id[@nullFlavor='NI'] hl7:id[@nullFlavor='UNK']   Constraint Zugelassene nullFlavor: NI … Die Person der Entität hat keine Identifikationsnummer UNK … Die Person der Entität hat eine Identifikationsnummer, diese ist jedoch unbekannt hl7:id II 0 … * (epi...ung) wo [not(@nullFlavor)]   elgaimpf-data​element-371  ID des Unterzeichners  Datensatz e-Impfpass 2019 hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='NI'] @nullFlavor cs 1 … 1 F NI hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK Auswahl 0 … 1 Elemente in der Auswahl: hl7:addr[not(@nullFlavor)] welches enthält Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:addr[@nullFlavor='UNK'] hl7:addr 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (epi...ung) wo [not(@nullFlavor)] hl7:addr 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:telecom TEL.AT 0 … * Beliebig viele Kontakt-Elemente der Person der Entität. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen. (epi...ung) wo [not(@nullFlavor)]   elgaimpf-data​element-372  Kontaktdaten  Datensatz e-Impfpass 2019 @value url 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.). Es gelten die ELGA Formatkonventionen für Telekom-Daten, z.B. tel:+43.1.1234567 Zulässige Werteliste für telecom Präfixe gemäß Value-Set „ELGA_URLScheme“ @use cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP. Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:assigned​Person 1 … 1 M Personendaten der Person der Entität. Grundsätzlich sind die Vorgaben gemäß „Personen-Element“ zu befolgen. Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) (epi...ung) hl7:represented​Organization 0 … 1 R 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...ung)   elgaimpf-data​element-374  Organisation  Datensatz e-Impfpass 2019   Schematron assert role  error     test count(hl7:telecom)<2 or (count(hl7:telecom) = count(hl7:telecom[@use]))     Meldung Das Attribut telecom/@use MUSS bei allen telecom Elementen strukturiert sein.   Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.35 Information Recipient - EMS (DYNAMIC) hl7:information​Recipient 1 … 1 M Beabsichtiger Empfänger des Dokuments.  (epi...ung) @typeCode cs 0 … 1 F PRCP hl7:intended​Recipient 1 … 1 M (epi...ung) @classCode cs 0 … 1   hl7:id II 1 … 1 M (epi...ung) @assigningAuthorityName st 1 … 1 F moh-at   CDA verlangt hier einen Wert und dieser wird auch überprüft. Aufgrund der Tatsache, dass sich die Bezeichnung und die Abkürzung des für Gesundheitsfragen zuständige Ministerium öfters ändern kann, wird in diesem Attribute der Wert "moh-at" (Ministry of Health - AT) angegeben. Dieser entspricht dem Symbolischen-Bezeichner aus dem österreichischen OID Portal für die OID, welche in dem root-Attribute geführt wird. @root uid 1 … 1 F 1.2.40.0.34.3.1.1 hl7:information​Recipient 1 … 1 M (epi...ung) hl7:name ST 1 … 1 M Hier muss die Angebe des Empfängers erfolgen. Je nach dem wie die aktuelle Abkürzung des für Gesundheitsfragen zuständige Ministerium lautet kann MUSS diese hier angegeben werden. z.B. BMG, BMGF, BMSGPK (epi...ung) hl7:received​Organization 1 … 1 M Beinhaltet 1.2.40.0.34.6.0.11.9.39 Organization Compilation with id, name, tel, addr - EMS (DYNAMIC) (epi...ung) Eingefügt NP von 1.2.40.0.34.6.0.11.1.21 Participant Ein-, Ueber-, Zuweisender Arzt (DYNAMIC) hl7:participant NP Einweisender/Zuweisender/Überweisender Arzt (epi...ung) wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.21']] @typeCode cs 1 … 1 F REF   Referrer @context​Control​Code cs 0 … 1 F OP hl7:templateId II 1 … 1 M (epi...ung) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.1.21 hl7:associated​Entity 1 … 1 M (epi...ung) @classCode cs 1 … 1 F PROV   Healthcare provider - Gesundheitsdiensteanbieter Auswahl 1 … * Identifikation des einweisenden/zuweisenden/überweisenden Arztes. Elemente in der Auswahl: hl7:id[not(@nullFlavor)] hl7:id[@nullFlavor='NI'] hl7:id[@nullFlavor='UNK']   Constraint Zugelassene nullFlavor: NI … Die Person der Entität hat keine Identifikationsnummer UNK … Die Person der Entität hat eine Identifikationsnummer, diese ist jedoch unbekannt hl7:id II 0 … * (epi...ung) wo [not(@nullFlavor)] hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='NI'] @nullFlavor cs 1 … 1 F NI hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:addr AD 0 … 1 Adresse des einweisenden/zuweisenden/überweisenden Arztes Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (epi...ung) wo [not(@nullFlavor)] hl7:telecom TEL.AT 0 … * Beliebig viele Kontaktdaten des einweisenden/zuweisenden/überweisenden Arztes (epi...ung) wo [not(@nullFlavor)] @value st 1 … 1 R 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“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. Auswahl 1 … 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) hl7:associated​Person  … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) (epi...ung) wo [hl7:name [count(child::*)=0]] hl7:associated​Person  … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) (epi...ung) wo [hl7:name [count(child::*)!=0]] hl7:scoping​Organization 0 … 1 R 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. (epi...ung) Eingefügt von 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 0 … * Beliebig viele IDs der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc. (epi...ung) wo [not(@nullFlavor)] hl7:name ON 1 … 1 M Name 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. (epi...ung) hl7:telecom TEL.AT 0 … * Kontaktdaten der Organisation. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (epi...ung) wo [not(@nullFlavor)] @value st 1 … 1 R 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“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:addr AD 0 … 1 Adresse der Organisation. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (epi...ung) wo [not(@nullFlavor)] Eingefügt NP von 1.2.40.0.34.6.0.11.1.9 In Fulfillment Of (DYNAMIC) hl7:inFulfillmentOf NP Komponente zur Dokumentation des Auftrags. (epi...ung)   at-cda-bbr-data​element-42  Auftrag  Dataset A 2019 @typeCode cs 1 … 1 F FLFS hl7:order 1 … 1 M Auftrag. (epi...ung) @classCode cs 1 … 1 F ACT @moodCode cs 1 … 1 F RQO hl7:id II 1 … 1 M Auftragsnummer, Anforderungsnummer. Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen. (epi...ung)   at-cda-bbr-data​element-43  ID  Dataset A 2019 Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.36 Documentation Of Service Event - Infectious disease Note (DYNAMIC) hl7:documentationOf 1 … 1 M Komponente für die Gesundheitsdienstleistung. (epi...ung) @typeCode cs 0 … 1 F DOC hl7:serviceEvent 1 … 1 M (epi...ung) @classCode cs 0 … 1 F ACT @moodCode cs 0 … 1 F EVN hl7:code CE 1 … 1 M (epi...ung) @code CONF 1 … 1 F 34782-3 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) @codeSystemName 1 … 1 F LOINC @displayName 1 … 1 F Infectious disease Note hl7:effectiveTime IVL_TS 1 … 1 M Die Angabe eines zeitlichen Erbringungsintervalls effectiveTime mit einer Start- low und End-zeit high ist verpflichtend. z.B. Beginn / Ende der Feststellung einer möglichen Infektion. (epi...ung) Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC) Auswahl 1 … 1 Elemente in der Auswahl: hl7:low[@value] hl7:low[@nullFlavor='UNK'] hl7:low TS.AT.TZ 0 … 1 (epi...ung) wo [@value] hl7:low TS.AT.TZ 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK Auswahl 1 … 1 Elemente in der Auswahl: hl7:high[@value] hl7:high[@nullFlavor='UNK'] hl7:high TS.AT.TZ 0 … 1 (epi...ung) wo [@value] hl7:high TS.AT.TZ 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.37 Documentation Of Service Event - Physician Note (DYNAMIC) hl7:documentationOf 1 … 1 M Komponente für die Gesundheitsdienstleistung. (epi...ung) @typeCode cs 0 … 1 F DOC hl7:serviceEvent 1 … 1 M (epi...ung) @classCode cs 0 … 1 F ACT @moodCode cs 0 … 1 F EVN hl7:code CE 1 … 1 M (epi...ung) @code CONF 1 … 1 F 75476-2 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) @codeSystemName 1 … 1 F LOINC @displayName 1 … 1 F Physician Note hl7:effectiveTime IVL_TS 1 … 1 M Die Angabe eines zeitlichen Erbringungsintervalls effectiveTime mit einer Start- low und End-zeit high ist verpflichtend: z.B. Beginn / Ende der Arztvisite (epi...ung) Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.9.15 Time Interval Information minimal (DYNAMIC) Auswahl 1 … 1 Elemente in der Auswahl: hl7:low[@value] hl7:low[@nullFlavor='UNK'] hl7:low TS.AT.TZ 0 … 1 (epi...ung) wo [@value] hl7:low TS.AT.TZ 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK Auswahl 1 … 1 Elemente in der Auswahl: hl7:high[@value] hl7:high[@nullFlavor='UNK'] hl7:high TS.AT.TZ 0 … 1 (epi...ung) wo [@value] hl7:high TS.AT.TZ 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:performer 1 … 1 M Meldender Arzt (epi...ung) @typeCode cs 1 … 1 F PRF hl7:templateId II 1 … 1 M (epi...ung) @root uid 1 … 1 F 1.3.6.1.4.1.19376.1.3.3.1.7 hl7:assignedEntity 1 … 1 M (epi...ung) Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC) @classCode cs 0 … 1 F ASSIGNED Auswahl 1 … 1 Mindestens eine ID der Person der Entität Elemente in der Auswahl: hl7:id[not(@nullFlavor)] hl7:id[@nullFlavor='NI'] hl7:id[@nullFlavor='UNK']   Constraint Zugelassene nullFlavor: NI … Die Person der Entität hat keine Identifikationsnummer UNK … Die Person der Entität hat eine Identifikationsnummer, diese ist jedoch unbekannt hl7:id II 0 … * (epi...ung) wo [not(@nullFlavor)]   elgaimpf-data​element-371  ID des Unterzeichners  Datensatz e-Impfpass 2019 hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='NI'] @nullFlavor cs 1 … 1 F NI hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK Auswahl 1 … 1 Elemente in der Auswahl: hl7:addr[not(@nullFlavor)] welches enthält Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:addr[@nullFlavor='UNK'] hl7:addr 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (epi...ung) wo [not(@nullFlavor)] hl7:addr 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:telecom TEL.AT 1 … 1 M Beliebig viele Kontakt-Elemente der Person der Entität. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen. (epi...ung) wo [not(@nullFlavor)]   elgaimpf-data​element-372  Kontaktdaten  Datensatz e-Impfpass 2019 @value url 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.). Es gelten die ELGA Formatkonventionen für Telekom-Daten, z.B. tel:+43.1.1234567 Zulässige Werteliste für telecom Präfixe gemäß Value-Set „ELGA_URLScheme“ @use cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP. Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:assigned​Person 1 … 1 M Personendaten der Person der Entität. Grundsätzlich sind die Vorgaben gemäß „Personen-Element“ zu befolgen. Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) (epi...ung) hl7:represented​Organization 1 … 1 M Organisationsdaten der Entität. Grundsätzlich sind die Vorgaben gemäß „Organisations-Element“ zu befolgen. Beinhaltet 1.2.40.0.34.6.0.11.9.9 Organization Compilation with name (DYNAMIC) (epi...ung)   elgaimpf-data​element-374  Organisation  Datensatz e-Impfpass 2019   Schematron assert role  error     test count(hl7:telecom)<2 or (count(hl7:telecom) = count(hl7:telecom[@use]))     Meldung Das Attribut telecom/@use MUSS bei allen telecom Elementen strukturiert sein.   hl7:component 1 … 1 M (epi...ung) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true hl7:structuredBody 1 … 1 M (epi...ung) @classCode cs 0 … 1 F DOCBODY @moodCode cs 0 … 1 F EVN hl7:component 1 … 1 M Beinhaltet 1.2.40.0.34.6.0.11.2.78 EMS Sektion - Arztmeldung (DYNAMIC) (epi...ung) @typeCode cs 0 … 1 F COMP @context​Conduction​Ind bl 0 … 1 F true

7.2.1.2 Labormeldung

Id	1.2.40.0.34.6.0.11.0.9	Gültigkeit	2020‑02‑25 14:46:58
Status	Entwurf	Versions-Label	2020
Name	epims_document_labormeldung	Bezeichnung	Labormeldung
Kontext	Pfadname /
Klassifikation	CDA Document Level Template
Offen/Geschlossen	Geschlossen (nur definierte Elemente sind erlaubt)
Benutzt	Benutzt 19 Templates Benutzt als Name Version 1.2.40.0.34.6.0.11.1.10 Inklusion Document Realm (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.30 Inklusion Document TypeId (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.1 Inklusion Document Id (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.11 Inklusion Document Effective Time (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.12 Inklusion Document Confidentiality Code (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.13 Inklusion Document Language (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.15 Inklusion Document Set Id and Version Number (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.34 Inklusion Record Target - EMS (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.2 Inklusion Author (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.4 Inklusion Custodian (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.5 Inklusion Legal Authenticator (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.6 Inklusion Authenticator (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.35 Inklusion Information Recipient - EMS (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.21 Inklusion Participant Ein-, Ueber-, Zuweisender Arzt (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.9 Inklusion In Fulfillment Of (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.36 Inklusion Documentation Of Service Event - Infectious disease Note (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.38 Inklusion Documentation Of Service Event - Laboratory Report (2020) DYNAMIC 1.2.40.0.34.6.0.11.1.43 Inklusion Documentation Of Service Event - Microbiology Studies (2020) DYNAMIC 1.2.40.0.34.6.0.11.2.86 Containment EMS Sektion - Labormeldung (2020) DYNAMIC
Item DT Kard Konf Beschreibung Label hl7:ClinicalDocument (epi...ung) @classCode cs 0 … 1 F DOCCLIN @moodCode cs 0 … 1 F EVN Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.10 Document Realm (DYNAMIC) Kennzeichnung aus welchem Land das Dokument stammt hl7:realmCode CS 1 … 1 M Hoheitsbereich des Dokuments. Fester Wert: @code = AT (aus ValueSet „ELGA_RealmCode“) (epi...ung) @code 1 … 1 F AT Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.30 Document TypeId (DYNAMIC) Kennzeichnung, dass das Dokument in CDA R2 Format vorliegt hl7:typeId II 1 … 1 M Dokumentformat CDA R2 (epi...ung) @root uid 1 … 1 F 2.16.840.1.113883.1.3 @extension st 1 … 1 F POCD_HD000040 hl7:templateId II 1 … 1 M ELGA TemplateId für den Allgemeinen Implementierungsleitfaden (epi...ung) @root uid 1 … 1 F 1.2.40.0.34.11.1 hl7:templateId II 1 … 1 M templateId für EMS-Meldungen (epi...ung) @root uid 1 … 1 F 1.2.40.0.34.11.6 hl7:templateId II 1 … 1 M templateId für Labormeldungen ins EMS (epi...ung) @root uid 1 … 1 F 1.2.40.0.34.11.6.0.1 Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.1 Document Id (DYNAMIC) weltweit eindeutiger Identifier für das Dokument (Befundnummer) hl7:id II 1 … 1 M Dokumenten-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. (epi...ung) @root uid 1 … 1 R hl7:code CE 1 … 1 M (epi...ung) @code CONF 1 … 1 F 34782-3 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) @codeSystemName 1 … 1 F LOINC @displayName 1 … 1 F Infectious disease Note hl7:title ST 1 … 1 M Der Titel des Dokumentes ist verpflichtend anzugeben, vom Ersteller frei zu vergeben und beschreibt die Art des Dokumentes näher. Der Titel des Dokuments ist für den lesenden Dokumentempfänger das sichtbare Element. Ein Beispiel wäre "Labormeldung". (epi...ung) Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.11 Document Effective Time (DYNAMIC) hl7:effectiveTime TS.AT.TZ 1 … 1 M Relevantes Datum des Dokuments. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. (epi...ung)   at-cda-bbr-data​element-11  Erstellungsdatum  Dataset A 2019 Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.12 Document Confidentiality Code (DYNAMIC) hl7:confidentialityCode CE 1 … 1 M Vertraulichkeitscode des Dokuments aus ValueSet „ELGA_Confidentiality“.  (epi...ung)   at-cda-bbr-data​element-13  Vertraulichkeitscode  Dataset A 2019 @codeSystemName st 1 … 1 F HL7:Confidentiality   Constraint Für ELGA-Dokumente ist ausschließlich "N" erlaubt! Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.13 Document Language (DYNAMIC) hl7:language​Code CS.LANG 1 … 1 M Sprachcode des Dokuments. (epi...ung)   at-cda-bbr-data​element-14  Sprachcode  Dataset A 2019 @code cs 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.10 atcdabbr_LanguageCode (DYNAMIC)   Constraint Für ELGA ist in @code für CDA und Ableitungen in die XDSDocumentEntry-Metadaten derzeit ausschließlich der Wert "de-AT" zulässig. Für eHealth und zukünftige Versionen der ELGA Leitfäden können weitere Sprachcodes erlaubt werden. Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.15 Document Set Id and Version Number (DYNAMIC) hl7:setId II 1 … 1 M 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. (epi...ung) hl7:versionNumber INT.​NONNEG 1 … 1 M Versionsnummer 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. (epi...ung) @value int 1 … 1 R Versionsnummer als positive ganze Zahl. Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.34 Record Target - EMS (DYNAMIC) 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). hl7:recordTarget 1 … 1 M Komponente für die Patientendaten. (epi...ung) @typeCode cs 0 … 1 F RCT @context​Control​Code cs 0 … 1 F OP hl7:patientRole 1 … 1 M Patientendaten. (epi...ung) @classCode cs 0 … 1 F PAT hl7:id II 2 … * R Patientenidentifikatoren (epi...ung)   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) hl7:addr 0 … 2 R 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...ung)   Constraint Werden mehrere address-Elemente strukturiert (z.B. Home, Pflege), MUSS jeweils das Attribut @use angeführt sein. hl7:telecom TEL.AT 0 … * R Kontakt-Element. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen. (epi...ung) @value url 1 … 1 R 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“ @use cs 0 … 1   Bedeutung des angegebenen Kontakts (z.B Heim, Arbeitsplatz), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:patient 1 … 1 M Name 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...ung) Auswahl 1 … 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'] hl7:administrative​Gender​Code CE 0 … 1 (epi...ung) wo [not(@nullFlavor)] @displayName st 1 … 1 R @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.1 @codeSystemName st 0 … 1 F HL7:AdministrativeGender   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC) hl7:administrative​Gender​Code CE 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK Auswahl 1 … 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'] hl7:birthTime TS.DATE 0 … 1 (epi...ung) hl7:birthTime TS.DATE 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK sdtc:deceasedInd BL 0 … 1 Indikator ob Patient/Patientin verstorben ist (epi...ung) sdtc:deceasedTime TS.DATE 0 … 1 Angabe des Sterbedatums (epi...ung) hl7:marital​Status​Code CE 0 … 1 R Codierung des Familienstands des Patienten. Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“ (epi...ung) @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.2 @codeSystemName st 1 … 1 F HL7:MaritalStatus @displayName st 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.11 ELGA_MaritalStatus (DYNAMIC) hl7:religious​Affiliation​Code CE 0 … 1 R Codierung des Religionsbekenntnisses des Patienten. Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“ (epi...ung) @code cs 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.2.16.1.4.1 @codeSystemName st 1 … 1 F HL7.AT:ReligionAustria @displayName st 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.18 ELGA_ReligiousAffiliation (DYNAMIC) hl7:raceCode NP Rasse des Patienten Darf nicht verwendet werden! (epi...ung) hl7:ethnic​Group​Code NP Ethnische Zugehörigkeit des Patienten. Darf nicht verwendet werden! (epi...ung) hl7:guardian 0 … * R Gesetzlicher 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...ung) @classCode cs 0 … 1 F GUARD hl7:addr 0 … 1 R 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...ung) hl7:telecom TEL.AT 0 … * R Beliebig viele Kontaktdaten des gesetzlichen Vertreters als Person oder Organisation. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen. (epi...ung) @value st 1 … 1 R 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“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (z.B. Heim, Arbeitsplatz) Bsp: WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. Auswahl 1 … 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) hl7:guardian​Person 0 … 1 Name 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...ung) hl7:guardian​Person 0 … 1 Name 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...ung) hl7:guardian​Organization 0 … 1 R Name des gesetzlichen Vertreters (Organisation) Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) (epi...ung) hl7:birthplace 0 … 1 R Geburtsort des Patienten. (epi...ung) @classCode cs 0 … 1 F BIRTHPL hl7:place 1 … 1 M (epi...ung) @classCode cs 0 … 1 F PLC @determiner​Code cs 0 … 1 F INSTANCE Auswahl 1 … 1 Elemente 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) hl7:addr AD 0 … 1 Angaben zum Geburtsorts. Im Kontext der Arztmeldung an das EMS wird EMPFOHLEN das Geburtsland als Klartext zu übermitteln (und nicht als ISO-2/3 Code). Das bedeutet es SOLL, "Österreich" und nicht "AUT" oder "AT", angegeben werden. Beinhaltet 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) (epi...ung) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts, struktuiert. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (epi...ung) hl7:language​Communication 0 … * R Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten. (epi...ung) hl7:language​Code CS 1 … 1 M Sprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen). (epi...ung) @code cs 1 … 1 R Zulä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) hl7:modeCode CE 0 … 1 R Ausdrucksform der Sprache. Zulässige Werte gemäß Value-Set „ELGA_LanguageAbilityMode“ (epi...ung) @code cs 1 … 1 R @displayName st 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.60 @codeSystemName st 0 … 1 F HL7:LanguageAbilityMode   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC) hl7:proficiency​Level​Code CE 0 … 1 R Grad der Sprachkenntnis in der Sprache. Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“ (epi...ung) @code cs 1 … 1 R @displayName st 1 … 1 R @codeSystem oid 1 … 1 F 2.16.840.1.113883.5.61 @codeSystemName st 0 … 1 F HL7:LanguageAbilityProficiency   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.174 ELGA_ProficiencyLevelCode (DYNAMIC) hl7:preference​Ind BL 0 … 1 R Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird. (epi...ung)   Schematron assert role  error     test not(hl7:id[1]/@nullFlavor)     Meldung Die Verwendung von id/@nullFlavor ist an dieser Stelle NICHT ERLAUBT.     Schematron assert role  error     test not(hl7:id[2]/@nullFlavor) or (hl7:id[2][@nullFlavor='UNK'] or hl7:id[2][@nullFlavor='NI'])     Meldung Zugelassene nullFlavor sind "NI" und "UNK"   Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.2 Author (DYNAMIC) hl7:author 1 … 1 M Verfasser des Dokuments. (epi...ung) @typeCode cs 0 … 1 F AUT @context​Control​Code cs 0 … 1 F OP hl7:functionCode CE (extensible) 0 … 1 R Funktionscode des Verfassers des Dokuments, z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“. Eigene Codes und Bezeichnungen können verwendet werden. (epi...ung) @code cs 1 … 1 R @codeSystem oid 1 … 1 R @displayName st 1 … 1 R Auswahl 1 … 1 Der Zeitpunkt an dem das Dokument verfasst, bzw. inhaltlich fertiggestellt wurde. Elemente in der Auswahl: hl7:time[not(@nullFlavor)] hl7:time[@nullFlavor='UNK'] hl7:time TS.AT.TZ 0 … 1 (epi...ung) wo [not(@nullFlavor)] hl7:time TS.AT.TZ 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:assignedAuthor 1 … 1 M (epi...ung) @classCode cs 0 … 1 F ASSIGNED Auswahl 1 … * 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']   Constraint Zugelassene 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 hl7:id II 0 … * Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software. ODER Identifikation des/der datenerstellenden Gerätes/Software.  (epi...ung) wo [not(@nullFlavor)] hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='NI'] @nullFlavor cs 1 … 1 F NI hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:code CE 0 … 1 R Angabe der Fachrichtung des Verfassers des Dokuments („Sonderfach“ gem. Ausbildungsordnung), z.B: „Facharzt/Fachärztin 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. (epi...ung) @codeSystem oid 1 … 1 R @displayName st 1 … 1 R @code cs 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.6 ELGA_AuthorSpeciality (DYNAMIC) hl7:telecom TEL.AT 0 … * Kontaktdaten des Verfassers des Dokuments. Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen. (epi...ung) wo [not(@nullFlavor)] @value st 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.), z.B. tel:+43.1.1234567 Zulässige Werteliste für telecom Präfixe gemäß „ELGA_URLScheme“ @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. Auswahl 1 … 1 Elemente 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) hl7: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) (epi...ung) hl7:assigned​Authoring​Device 0 … 1 Datenerstellendes Gerät Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC) (epi...ung) hl7:represented​Organization 1 … 1 M Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. ↔ Hinweis zum XDS-Mapping: Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, soll das name Element SOLL einer möglichst eindeutigen Kurzbezeichnung der Organisation entsprechen (im GDA-I im Tag description enthalten). Bei größeren Organisationen SOLL zusätzlich die Abteilung angegeben werden, damit die Zuordnung für den Leser einfacher wird.  Beispiel: Statt "Allgemeines Krankenhaus der Stadt Wien-Medizinischer Universitätscampus" -->  "Wien AKH" bzw "Wien AKH - Augenambulanz"  Beinhaltet 1.2.40.0.34.6.0.11.9.5 Organization Compilation with id, name (DYNAMIC) (epi...ung)   Constraint id MUSS der OID der Organisation aus dem GDA-Index entsprechen. name SOLL der Kurzbezeichnung im GDA-I entsprechen (sofern vorhanden) Zu dem Namen größerer Organisationen SOLL auch die Abteilung angegeben werden., z.B.: „Amadeus Spital, Chirurgische Abteilung“ Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.4 Custodian (DYNAMIC) hl7:custodian 1 … 1 M Verwahrer des Dokuments. (epi...ung)   at-cda-bbr-data​element-24  Verwahrer  Dataset A 2019 @typeCode cs 0 … 1 F CST hl7:assignedCustodian 1 … 1 M (epi...ung) @classCode cs 0 … 1 F ASSIGNED hl7:represented​Custodian​Organization 1 … 1 M (epi...ung) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 1 … * M Identifikation des Verwahrers des Dokuments, wie im GDA-Index angegeben. Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen. (epi...ung) hl7:name ON 1 … 1 M Name des Verwahrers des Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Namen-Elemente von Organisationen ON“ zu befolgen. (epi...ung) hl7:telecom TEL.AT 0 … * Kontaktdaten des Verwahrers des originalen Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen. (epi...ung) wo [not(@nullFlavor)] @value st 1 … 1 R @use set_cs 0 … 1   Bedeutung des angegebenen Kontakts gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:addr AD 1 … 1 M Adresse 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) (epi...ung) Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.5 Legal Authenticator (DYNAMIC) hl7:legalAuthenticator 1 … 1 M Hauptunterzeichner, Rechtlicher Unterzeichner (epi...ung)   elgaimpf-data​element-368  Unterzeichnende Person (Dokument)  Datensatz e-Impfpass 2019 at-cda-bbr-data​element-1  Rechtlicher Unterzeichner  Dataset A 2019 @context​Control​Code cs 0 … 1 F OP @typeCode cs 0 … 1 F LA Auswahl 1 … 1 Der Zeitpunkt, an dem das Dokument unterzeichnet wurde. Elemente in der Auswahl: hl7:time[not(@nullFlavor)] hl7:time[@nullFlavor='UNK'] hl7:time TS.AT.TZ 0 … 1 (epi...ung) wo [not(@nullFlavor)]   at-cda-bbr-data​element-5  Zeitpunkt der Unterzeichnung  Dataset A 2019 elgaimpf-data​element-369  Zeitpunkt der Unterzeichnung  Datensatz e-Impfpass 2019 hl7:time TS.AT.TZ 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:signatureCode CS 1 … 1 M Signaturcode gibt an, dass das Originaldokument unterzeichnet wurde. (epi...ung)   elgaimpf-data​element-370  Signatur  Datensatz e-Impfpass 2019 at-cda-bbr-data​element-6  Signatur  Dataset A 2019 @code CONF 1 … 1 F S hl7:assignedEntity 1 … 1 M Personendaten 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) (epi...ung) Eingefügt 0 … * von 1.2.40.0.34.6.0.11.1.6 Authenticator (DYNAMIC) hl7:authenticator 0 … * Weitere Unterzeichner. (epi...ung)   at-cda-bbr-data​element-31  Weitere Unterzeichner  Dataset A 2019 @typeCode cs 0 … 1 F AUTHEN Auswahl 1 … 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'] hl7:time TS.AT.TZ 0 … 1 (epi...ung) wo [not(@nullFlavor)]   at-cda-bbr-data​element-105  Zeitpunkt der Unterzeichnung  Dataset A 2019 hl7:time TS.AT.TZ 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:signatureCode CS 1 … 1 M (epi...ung)   at-cda-bbr-data​element-106  Signatur  Dataset A 2019 @code CONF 1 … 1 F S hl7:assignedEntity 1 … 1 M Personendaten des weiteren Unterzeichners. Grundsätzlich sind die Vorgaben gemäß Kapitel „AssignedEntity-Element (Person + Organisation)“ zu befolgen. (epi...ung) Eingefügt von 1.2.40.0.34.6.0.11.9.22 Assigned Entity (DYNAMIC) @classCode cs 0 … 1 F ASSIGNED Auswahl 1 … * Mindestens eine ID der Person der Entität Elemente in der Auswahl: hl7:id[not(@nullFlavor)] hl7:id[@nullFlavor='NI'] hl7:id[@nullFlavor='UNK']   Constraint Zugelassene nullFlavor: NI … Die Person der Entität hat keine Identifikationsnummer UNK … Die Person der Entität hat eine Identifikationsnummer, diese ist jedoch unbekannt hl7:id II 0 … * (epi...ung) wo [not(@nullFlavor)]   elgaimpf-data​element-371  ID des Unterzeichners  Datensatz e-Impfpass 2019 hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='NI'] @nullFlavor cs 1 … 1 F NI hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK Auswahl 0 … 1 Elemente in der Auswahl: hl7:addr[not(@nullFlavor)] welches enthält Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:addr[@nullFlavor='UNK'] hl7:addr 0 … 1 Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) (epi...ung) wo [not(@nullFlavor)] hl7:addr 0 … 1 (epi...ung) wo [@nullFlavor='UNK'] @nullFlavor cs 1 … 1 F UNK hl7:telecom TEL.AT 0 … * Beliebig viele Kontakt-Elemente der Person der Entität. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen. (epi...ung) wo [not(@nullFlavor)]   elgaimpf-data​element-372  Kontaktdaten  Datensatz e-Impfpass 2019 @value url 1 … 1 R Die Kontaktadresse (Telefonnummer, Email, etc.). Es gelten die ELGA Formatkonventionen für Telekom-Daten, z.B. tel:+43.1.1234567 Zulässige Werteliste für telecom Präfixe gemäß Value-Set „ELGA_URLScheme“ @use cs 0 … 1   Bedeutung des angegebenen Kontakts (Heim, Arbeitsplatz, …), z.B. WP. Zulässige Werte gemäß Value-Set „ELGA_TelecomAddressUse“   Constraint Werden mehrere gleichartige telecom-Elemente strukturiert, MUSS jeweils das Attribut @use angeführt sein. hl7:assigned​Person 1 … 1 M Personendaten der Person der Entität. Grundsätzlich sind die Vorgaben gemäß „Personen-Element“ zu befolgen. Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) (epi...ung) hl7:represented​Organization 0 … 1 R 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...ung)   elgaimpf-data​element-374  Organisation  Datensatz e-Impfpass 2019   Schematron assert role  error     test count(hl7:telecom)<2 or (count(hl7:telecom) = count(hl7:telecom[@use]))     Meldung Das Attribut telecom/@use MUSS bei allen telecom Elementen strukturiert sein.   Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.35 Information Recipient - EMS (DYNAMIC) hl7:information​Recipient 1 … 1 M Beabsichtiger Empfänger des Dokuments.  (epi...ung) @typeCode cs 0 … 1 F PRCP hl7:intended​Recipient 1 … 1 M (epi...ung) @classCode cs 0 … 1   hl7:id II 1 … 1 M (epi...ung) @assigningAuthorityName st 1 … 1 F moh-at   CDA verlangt hier einen Wert und dieser wird auch überprüft. Aufgrund der Tatsache, dass sich die Bezeichnung und die Abkürzung des für Gesundheitsfragen zuständige Ministerium öfters ändern kann, wird in diesem Attribute der Wert "moh-at" (Ministry of Health - AT) angegeben. Dieser entspricht dem Symbolischen-Bezeichner aus dem österreichischen OID Portal für die OID, welche in dem root-Attribute geführt wird. @root uid 1 … 1 F 1.2.40.0.34.3.1.1 hl7:information​Recipient 1 … 1 M (epi...ung) hl7:name ST 1 … 1 M Hier muss die Angebe des Empfängers erfolgen. Je nach dem wie die aktuelle Abkürzung des für Gesundheitsfragen zuständige Ministerium lautet kann MUSS diese hier angegeben werden. z.B. BMG, BMGF, BMSGPK (epi...ung) hl7:received​Organization 1 … 1 M Beinhaltet 1.2.40.0.34.6.0.11.9.39 Organization Compilation with id, name, tel, addr - EMS (DYNAMIC) (epi...ung) Eingefügt 1 … 1 M von 1.2.40.0.34.6.0.11.1.21 Participant Ein-, Ueber-, Zuweisender Arzt (DYNAMIC) hl7:participant 1 … 1 M Einweisender/Zuweisender/Überweisender Arzt (epi...ung) wo [hl7:templateId ​[@root​=​'1.2.40.0.34.6.0.11.1.21']] @typeCode cs 1 … 1 F REF   Referrer @context​Control​Code cs 0 … 1 F OP hl7:templateId II 1 … 1 M (epi...ung) @root uid 1 … 1 F 1.2.40.0.34.6.0.11.1.21 hl7:associated​Entity 1 … 1 M (epi...ung) @classCode cs 1 … 1 F PROV   Healthcare provider - Gesundheitsdiensteanbieter Auswahl 1 … * Identifikation des einweisenden/zuweisenden/überweisenden Arztes. Elemente in der Auswahl: hl7:id[not(@nullFlavor)] hl7:id[@nullFlavor='NI'] hl7:id[@nullFlavor='UNK']   Constraint Zugelassene nullFlavor: NI … Die Person der Entität hat keine Identifikationsnummer UNK … Die Person der Entität hat eine Identifikationsnummer, diese ist jedoch unbekannt hl7:id II 0 … * (epi...ung) wo [not(@nullFlavor)] hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='NI'] @nullFlavor cs 1 … 1 F NI hl7:id II 0 … 1 (epi...ung) wo [@nullFlavor='UNK']