LeitseiteProjektinformationImplementierungsleitfadenDatensatzSzenariosIdentifikatorenTerminologienTemplates

Templates

Name (Versions-Label) / Beschreibung Id
 Gesundheitsberatung 14502025-09-15 (1.0.0+20260223) 1.2.40.0.34.6.0.11.0.27
Name (Versions-Label) / Beschreibung Id
 Author2023-04-06 (1.0.3+20230717)at-cda-bbr-

Der Autor, Urheber oder Dokumentersteller ist die Person, die hauptursächlich etwas verursacht oder veranlasst oder als Initiator, Anstifter, Verfasser oder Verursacher wirkt. Der Autor kann auch ein "Dokument-erstellendes Gerät" sein, etwa ein Computerprogramm, das automatisch Daten zu einem Patienten in Form eines Befunds oder einer Zusammenfassung kombiniert.

Die das Dokument schreibende Person (z.B. Schreibkraft, medizinische Dokumentationsassistenz) wird in CDA in einem eigenen Element (dataEnterer) abgebildet, siehe "Personen der Dateneingabe ("dataEnterer")".

Es kann mehr als ein Dokumentersteller angegeben werden (mehrere author-Elemente). Das erste author-Element SOLL eine Person sein ("Hauptautor"). Geräte MÜSSEN hinter den Personen-Autoren stehen (sofern vorhanden, z.B. bei einem On-Demand Dokument, das keine Person erstellt oder sonstige automatisch ohne Personenkontakt erstellte Dokumente).

↔ Hinweis zum XDS-Mapping: Folgende XDS-Attribute werden aus dem author-Element abgeleitet:

  • AuthorInstitution (=representedOrganization)

  • AuthorPerson (=assignedAuthor)

  • AuthorRole (=functionCode)

  • AuthorSpeciality  (=assignedAuthor.code)

Nur das erste author-Element ist für das XDS-Mapping zu übernehmen.

 1.2.40.0.34.6.0.11.1.2
 Custodian2021-10-13 (1.0.1+20211213)at-cda-bbr-
Der "Verwahrer" des Dokuments stellt die Organisation dar, von der das Dokument stammt und die für die Aufbewahrung und Verwaltung des ORIGINALEN Dokuments verantwortlich ist. Jedes CDA-Dokument hat genau einen Custodian.
Der Custodian entspricht der Definition von Verwaltertätigkeit ("Stewardship") von CDA. Da CDA ein Austauschformat für Dokumente ist und ein CDA-Dokument möglicherweise nicht die ursprüngliche Form der authentifizierten Dokumente darstellt, repräsentiert der Custodian den Verwalter der ursprünglichen Quelldokumente.
 1.2.40.0.34.6.0.11.1.4
 Data Enterer2023-04-05 (1.0.1+20230717)at-cda-bbr-

Die dokumentierende Person (z.B. Medizinische Dokumentationsassistenz, Schreibkraft).

Das Element "dataEnterer" entfällt bei automatisch erstellten Dokumenten (ODD).

 1.2.40.0.34.6.0.11.1.22
 Document Confidentiality Code2023-03-24 (1.0.2+20230717)at-cda-bbr-
Grundsätzlich stellt CDA Informationen zum Vertraulichkeitsstatus eines Dokuments zur Verfügung, um Anwendungssysteme bei der Verwaltung des Zugriffs auf sensible Daten zu unterstützen. Der Vertraulichkeitsstatus kann für das gesamte Dokument oder für bestimmte Teile des Dokuments gelten. Der im Header angegebene Wert gilt für das gesamte Dokument, es sei denn, er wird durch einen verschachtelten Wert überschrieben. Der tatsächliche Zugriff auf das Dokument muss von der übergeordneten Infrastrukturschicht geregelt werden.
↔ Hinweis zum XDS-Mapping: Dieses Element spiegelt sich im XDS-Attribut confidentialityCode wider. Für ELGA wird dieses fix auf "N" gesetzt.
 1.2.40.0.34.6.0.11.1.12
 Document Effective Time2023-04-11 (1.0.1+20230717)at-cda-bbr-

Dokumentiert das Erstellungsdatum bzw. den Zeitpunkt, an dem das Dokument inhaltlich fertiggestellt wurde. Damit ist jenes Datum gemeint, welches normalerweise im Briefkopf eines Schriftstückes angegeben wird (z.B. Wien, am …). Das Erstellungsdatum des Dokuments MUSS NICHT nicht mit dem Datum der rechtlichen Unterzeichnung (oder „Vidierung“) übereinstimmen.

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

Verweis auf speziellen Implementierungsleitfaden: Für das Erstellungsdatum ist das medizinisch zutreffendste Datum anzugeben, dieses MUSS für jede einzelne Dokumentenklasse im speziellen Leitfaden separat definiert werden.
Begründung: Das Erstellungsdatum wird für die Sortierung der CDA-Dokumente im Dokumentenregister (XDSDocumentEntry-Metadaten) verwendet. Es MUSS also sichergestellt werden, dass die CDA-Dokumente in der Reihenfolge sortiert werden, wie sie in einer Krankenakte sortiert werden. 
Beispiel: Laborbefunde müssen nach dem Probenentnahmedatum sortiert werden (NICHT nach dem Vidierdatum), Radiologiebefunde nach dem Ende der Bildaufnahme (NICHT nach dem Befundungszeitpunkt).

 1.2.40.0.34.6.0.11.1.11
 Document Id2021-02-19 (1.0.0+20210219)at-cda-bbr-
Die Dokumenten-Id eines CDA-Dokuments ist ein eindeutiger Instanzidentifikator, der das Dokument weltweit und für alle Zeit eindeutig identifiziert. Ein CDA-Dokument hat genau eine Id.
↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut uniqueId gemappt.
 1.2.40.0.34.6.0.11.1.1
 Document Language2021-02-19 (1.0.0+20210219)at-cda-bbr-
Gibt die Sprache des Dokuments an, sowohl in Inhalts- oder Attributwerten. Die Angabe erfolgt im Sprachcode-Attribut gemäß IETF RFC 3066 (Internet Engineering Task Force RFC 3066 for the Identification of Languages, ed. H. Alvestrand 1995).
Es enthält mindestens einen Sprachcode gemäß ISO 639 ("Code for the representation of names of languages") und einen optionalen Ländercode gemäß ISO 3166 alpha-2.
Syntax: Vereinfacht folgt der LanguaceCode dem Format ll-CC, wobei ll dem Sprachcode gemäß ISO-639-1 in Kleinbuchstaben folgt und CC dem Ländercode gemäß ISO 3166 (Tabelle mit zwei Zeichen) in Großbuchstaben. Trennzeichen ist der Bindestrich (UTF-8 "Hyphen-Minus" mit Kode 45 (dezimal) bzw. 2D (hexadezimal)).
↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut languageCode gemappt.
 1.2.40.0.34.6.0.11.1.13
 Document PracticeSettingCode - Gesundheitsberatung 14502026-02-02 (1.0.0+20260223)
Die fachliche Zuordnung des Dokumentes
Den gültigen Wertebereich für dieses Elements entnehmen Sie bitte  dem Value Set ELGA_PracticeSetting .

↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut practiceSettingCode gemappt, MUSS daher für die Anwendung in ELGA angegeben werden.
 1.2.40.0.34.6.0.11.1.58
 Document Realm2023-03-24 (1.0.1+20230717)at-cda-bbr-
Hoheitsbereich des Dokuments.

Dieses Element kennzeichnet, dass das Dokument aus dem Hoheitsbereich Österreich (bzw. Bereich der HL7 Affiliate Austria, Code „AT“) stammt.
 1.2.40.0.34.6.0.11.1.10
 Document Set Id and Version Number2021-02-19 (1.0.0+20210219)at-cda-bbr-
Versionierung des Dokuments.
Der CDA-Header repräsentiert Beziehungen zu anderen Dokumenten mit Referenz auf die Dokumenten-Identifikation. Mittels der Attribute setId und versionNumber kann eine Versionskennung des Dokuments erreicht werden.
Für ELGA-CDA-Dokumente MÜSSEN immer beide Elemente angegeben werden.
Anhänge oder Ersetzungen von Vordokumenten MÜSSEN ebenfalls diese zusätzlichen Angaben enthalten. Der genaue Zusammenhang zwischen diesen Attributen finden Sie im Kapitel „Bezug zu vorgehenden Dokumenten“.
 1.2.40.0.34.6.0.11.1.15
 Document StatusCode2021-06-24 (1.0.1+20210624)at-cda-bbr-
Status eines Dokuments.
e-Befunde sind grundsätzlich abgeschlossene bzw. "fertige" ("completed") Dokumente, daher entfällt die Angabe eines Status. In folgenden Ausnahmen SOLL der Status eines Dokuments wie folgt angegeben werden:
  • “active”: z.B. wenn bekannt ist, dass Updates folgen werden: Etwa für "vorläufige ärztliche Entlassungsbriefe" oder Laborbefunde, für die noch Ergebnisse einzelner Analysen ausständig sind
  • “nullified”: z.B. für Dokumente, die gemäß Anwendungsfall "Storno von ELGA-Dokumenten" storniert werden, wobei zusätzlich ein letztes Dokument mit Storniert-Status in der Versionskette registriert wird.
Hinweis: Die Angabe von sdtc:statusCode ändert nichts an der Versionierung (Verwendung von setId und versionNr ist unverändert). Wenn z.B. ein vorläufiger Befund mit sdtc:statusCode active durch den endgültigen Befund ohne expliziten statusCode (weil completed) ersetzt wird, muss selbstverständlich eine neue id, dieselbe setId und eine höhere versionNr angegeben werden.

↔ Hinweis zum XDS-Mapping: Der Status wird nicht in die XDS-Metadaten übernommen!
 1.2.40.0.34.6.0.11.1.45
 Document TerminologyDate2021-02-19 (1.0.0+20210219)at-cda-bbr-
Das Terminologie-Datum des Dokumentes
Das Datum, an dem die lokal zur Implementierung verwendeten Value Sets mit dem österreichischen Terminologieserver abgeglichen wurden, wird hier angegeben.
 1.2.40.0.34.6.0.11.1.46
 Document TypeId2021-02-19 (1.0.0+20210219)at-cda-bbr-
Dieses Element kennzeichnet, dass das Dokument im Format CDA R2 vorliegt.
 1.2.40.0.34.6.0.11.1.30
 Documentation Of Service Event2021-02-19 (1.0.0+20210219)at-cda-bbr-
Dokumentation der Gesundheitsdienstleistung.

Mit der Assoziation documentationOf/serviceEvent wird die eigentliche Gesundheitsdienstleistung repräsentiert, die in dem Dokument dokumentiert wird (z.B. eine Koloskopie, Appendektomie, etc.). Dies ist in engem Zusammenhang mit dem Dokumententyp zu sehen, der in ClinicalDocument/code wiedergegeben ist. Mit der documentationOf Beziehung kann die dokumentierte Gesundheitsdienstleistung näher spezifiziert werden. Dies darf natürlich nicht im Widerspruch zum Dokumententyp stehen.

↔ Hinweis zum XDS-Mapping:
Da diese Informationen in die XDS-Metadaten übernommen werden, ergeben sich folgende Implikationen:
  • Es SOLL mindestens eine Gesundheitsdienstleistung als documentationOf/serviceEvent-Element angegeben werden
  • Es können beliebig viele weitere Gesundheitsdienstleistungen als weitere documentationOf/serviceEvent-Elemente angegeben werden
  • Die serviceEvents sind die einzigen medizinischen Informationen zum Dokument im XDS-Dokumentenregister
  • Können daher als Such-/Filterkriterium verwendet werden und scheinen ggf. in den Ergebnissen der Suchabfragen auf
  • Die Zeitangaben des ersten documentationOf/serviceEvent-Elements werden in die Dokument-Metadaten übernommen
  • Die ServiceEvents stellen eine wertvolle Information zum Suchen und Filtern in den Dokument-Metadaten dar!
 1.2.40.0.34.6.0.11.1.17
 Record Target2026-01-19 (1.2.3+20260120)at-cda-bbr-
Das RecordTarget-Element enthält den " Patienten ": Die Person, die von einem Gesundheitsdiensteanbieter (Arzt, einer Ärztin oder einem Angehörigen anderer Heilberufe) behandelt wird und über die bzw. über deren Gesundheitsdaten im Dokument berichtet wird.
↔ Hinweis zum XDS-Mapping: Inhalte dieses Elementes werden in die XDS-Metadaten zu XDSDocumentEntry. sourcePatientId übernommen.
1.2.40.0.34.6.0.11.1.3
Name (Versions-Label) / Beschreibung Id
 Abfrageprotokoll2025-10-29 (1.0.0+20260223)

Diese Section dokumentiert die Abarbeitung eines Abfrageprotokolls sowie alle daraus resultierenden Informationen für den Anrufer, wie Empfehlungen, Instruktionen und Hinweise zur Selbstbehandlung. Zusätzlich kann ein ermitteltes Leitsymptom codiert hinterlegt werden.

 1.2.40.0.34.6.0.11.2.166
 Beilagen2026-01-13 (1.0.3+20260119)at-cda-bbr-

Sonstige Beilagen, außer denjenigen Dokumenten, die in „Willenserklärungen und andere juridische Dokumente“ angegeben sind.

Achtung: Da einzelne e-Befunde vom Bürger ausgeblendet oder gelöscht werden können, ist ein Referenzieren bzw. Verweisen auf andere e-Befunde nicht zuverlässig und daher NICHT ERLAUBT. Inhalte, die unmittelbar zum e-Befund gehören, sollen daher als Beilage eingebettet werden.

 1.2.40.0.34.6.0.11.2.71
 Brieftext2021-06-28 (1.0.1+20210628)at-cda-bbr-
Ein am Anfang des Briefes formulierter Freitext für eine Anrede oder Begrüßung. Z.B. „Sehr geehrte Kollegin…“

Die Angabe von medizinisch / fachlich relevanter Information in diesem Abschnitt ist NICHT ERLAUBT.
Es ist EMPFOHLEN, redundante Angaben von Patientennamen oder Aufenthaltsdaten des Patienten in dieser Section zu vermeiden.
 1.2.40.0.34.6.0.11.2.69
 Handlungsempfehlung2025-09-15 (1.0.0+20260223)

Diese Section enthält jene Empfehlungen der Gesundheitsberatung 1450, die auf Grundlage der berufsrechtlichen Befugnisse des beratenden medizinischen Fachpersonals erteilt werden dürfen. Erfasst werden damit ausschließlich fachlich legitimierte Anweisungen oder Hinweise, die im Rahmen der telefonischen Beratung ausgesprochen werden, wie etwa Empfehlungen zur weiteren diagnostischen Abklärung oder zur Inanspruchnahme medizinischer Versorgung. Zusätzlich ist der im Rahmen der Beratung ermittelte "Best Point of Service" (BPOS) codiert hinterlegt.

 1.2.40.0.34.6.0.11.2.165
 Konsultationsgrund2025-09-15 (1.0.0+20260223)

Diese Section beschreibt Informationen, die vom Anrufer über den eigenen gesundheitlichen Zustand bereitgestellt werden. Dazu können insbesondere Angaben zu Vorerkrankungen, Allergien, Behinderungen, eingenommener Medikation sowie aktuellen Beschwerden gehören. Diese selbst berichteten Gesundheitsdaten werden strukturiert erfasst, um behandelnden oder beratenden Stellen einen vollständigen und verständlichen Überblick über den relevanten medizinischen Hintergrund der Person zu ermöglichen.

 1.2.40.0.34.6.0.11.2.164
 Übersetzung2023-04-13 (1.0.2+20230717)at-cda-bbr-
Subsection für die Übersetzung des narrativen Textes
Die Angabe des languageCode erfolgt durch Angabe eines Codes aus dem Value Set ELGA_HumanLanguage. Optional kann an diesen, mit Bindestrich getrennt, die Angabe des Landes aus ISO-Codelisten angefügt werden.
 1.2.40.0.34.6.0.11.2.8
Name (Versions-Label) / Beschreibung Id
 CDA Device SDTC2005-09-07
Template CDA Device (Prototyp, direkt abgeleitet aus POCD_RM000040 MIF) + SDTC Extensions
 2.16.840.1.113883.10.12.815
 CDA PlayingEntity SDTC2005-09-07
Template CDA PlayingEntity (Prototyp, direkt abgeleitet aus POCD_RM000040 MIF) + SDTC Extensions
 2.16.840.1.113883.10.12.813
 Eingebettetes Objekt Entry2023-05-09 (1.0.2+20230717)at-cda-bbr-

Achtung: Grafiken mit Transparenz sind NICHT ERLAUBT (z.B. bei GIF oder PNG möglich), da sie zu schweren Problemen bei der Wiedergabe oder Konvertierung zu PDF/A-1 führen können.

Die Größe von eingebetteten Dateien MUSS auf ein sinnvolles und angemessenes Maß beschränkt werden. Die Infrastruktur, mit der die Dateien übertragen und gespeichert werden, beschränkt die Größe der resultierenden Gesamtdatei. Der gültige Wert wird von der jeweiligen Infrastruktur angegeben (z.B. ELGA 20 MB, Stand Mai 2020) 

 1.2.40.0.34.6.0.11.3.19
 Handlungsempfehlung Entry2025-09-16 (1.0.0+20260223)

Dieses Entry enthält den im Rahmen der telefonischen Beratung ermittelten "Best Point of Service" (BPOS) in codierter Form.

 1.2.40.0.34.6.0.11.3.190
 Logo Entry2021-06-28 (1.0.1+20210628)at-cda-bbr- 1.2.40.0.34.6.0.11.3.53
 Symptom Entry2025-10-29 (1.0.0+20260223)

Dieses Entry enthält das im Rahmen der Abarbeitung eines Anrufprotokolls ermittelte Leitsymptom in codierter Form.

 1.2.40.0.34.6.0.11.3.191
Name (Versions-Label) / Beschreibung Id
 Abfrageprotokoll2025-10-29 (1.0.0+20260223)

Diese Section dokumentiert die Abarbeitung eines Abfrageprotokolls sowie alle daraus resultierenden Informationen für den Anrufer, wie Empfehlungen, Instruktionen und Hinweise zur Selbstbehandlung. Zusätzlich kann ein ermitteltes Leitsymptom codiert hinterlegt werden.

 1.2.40.0.34.6.0.11.2.166
 Address Compilation2023-04-13 (1.0.1+20230717)at-cda-bbr-
Adressen von Personen und Organisationen werden über das Element addr abgebildet. Das Adress-Element kann in verschiedenen Kontexten mit unterschiedlicher Detailgenauigkeit vorkommen. Daher werden drei Granularitätsstufen definiert, auf die je nach Anwendung entsprechend verwiesen wird, wobei für EIS Enhanced und EIS Full Support die Granularitätsstufe 2 oder 3 angegeben werden MUSS.
Die Adressangabe in Granularitätsstufe 2 (G2)  erlaubt die gemeinsame Angabe Straße und Hausnummer im Element streetAddressLine, Granularitätsstufe 3 (G3) schreibt die strukturierte Angabe von Straße und Hausnummer in den Elementen streetName und houseNumber vor.

Sind keine Adressdaten vorhanden, kann das Element entweder weggelassen werden oder mit nullFlavor angegeben werden – je nachdem wie das Adress-Element im Kontext spezifiziert wurde.
 1.2.40.0.34.6.0.11.9.25
 Address Compilation Minimal2023-04-06 (1.0.2+20230717)at-cda-bbr-
Adressangabe in Granularitätsstufe 2 oder 3
 1.2.40.0.34.6.0.11.9.10
 Assigned Entity2023-04-13 (1.0.2+20230717)at-cda-bbr-
Zusammengesetzte Objekte die Person- und Organisationsinformationen enthalten. 
Hierbei MUSS jedenfalls die „Person“ der Entität angegeben werden. Die Angabe der Organisation, der die Person angehört, ist prinzipiell optional. Diese Optionalität kann sich in Abhängigkeit vom konkreten Anwendungsfall in „verpflichtend“ ändern.
 1.2.40.0.34.6.0.11.9.22
 Assigned Entity Body2021-05-26 (1.0.1+20210526)at-cda-bbr-
Zusammengesetzte Objekte die Person- und Organisationsinformationen enthalten.
Hierbei MUSS jedenfalls die „Person“ der Entität angegeben werden. Die Angabe der Organisation, der die Person angehört, ist prinzipiell optional. Diese Optionalität kann sich in Abhängigkeit vom konkreten Anwendungsfall in „verpflichtend“ ändern.
Unterschiede zu AssigendEntity:
  • Adressangabe minimal möglich
  • assignedPerson.Name kann unstrukturiert angegeben werden
  • representedOrganization.addr Adresse kann minimal angegeben werden
1.2.40.0.34.6.0.11.9.16
 Author2023-04-06 (1.0.3+20230717)at-cda-bbr-

Der Autor, Urheber oder Dokumentersteller ist die Person, die hauptursächlich etwas verursacht oder veranlasst oder als Initiator, Anstifter, Verfasser oder Verursacher wirkt. Der Autor kann auch ein "Dokument-erstellendes Gerät" sein, etwa ein Computerprogramm, das automatisch Daten zu einem Patienten in Form eines Befunds oder einer Zusammenfassung kombiniert.

Die das Dokument schreibende Person (z.B. Schreibkraft, medizinische Dokumentationsassistenz) wird in CDA in einem eigenen Element (dataEnterer) abgebildet, siehe "Personen der Dateneingabe ("dataEnterer")".

Es kann mehr als ein Dokumentersteller angegeben werden (mehrere author-Elemente). Das erste author-Element SOLL eine Person sein ("Hauptautor"). Geräte MÜSSEN hinter den Personen-Autoren stehen (sofern vorhanden, z.B. bei einem On-Demand Dokument, das keine Person erstellt oder sonstige automatisch ohne Personenkontakt erstellte Dokumente).

↔ Hinweis zum XDS-Mapping: Folgende XDS-Attribute werden aus dem author-Element abgeleitet:

  • AuthorInstitution (=representedOrganization)

  • AuthorPerson (=assignedAuthor)

  • AuthorRole (=functionCode)

  • AuthorSpeciality  (=assignedAuthor.code)

Nur das erste author-Element ist für das XDS-Mapping zu übernehmen.

 1.2.40.0.34.6.0.11.1.2
 Author Body2023-04-05 (1.0.1+20230717)at-cda-bbr-
Der Autor (author) ist der Verfasser bzw. geistige Urheber eines bestimmten Inhalts. In der Regel ist das eine Person oder mehrere Personen, es kann aber auch ein "Gerät" - ein Programm oder Software den Inhalt automatisiert erstellen.
Element für Sections und Entries.
Wenn nicht angegeben, gilt das jeweils "darüberlegende" Author-Element (Section, Document).
 1.2.40.0.34.6.0.11.9.36
 Beilagen2026-01-13 (1.0.3+20260119)at-cda-bbr-

Sonstige Beilagen, außer denjenigen Dokumenten, die in „Willenserklärungen und andere juridische Dokumente“ angegeben sind.

Achtung: Da einzelne e-Befunde vom Bürger ausgeblendet oder gelöscht werden können, ist ein Referenzieren bzw. Verweisen auf andere e-Befunde nicht zuverlässig und daher NICHT ERLAUBT. Inhalte, die unmittelbar zum e-Befund gehören, sollen daher als Beilage eingebettet werden.

 1.2.40.0.34.6.0.11.2.71
 Brieftext2021-06-28 (1.0.1+20210628)at-cda-bbr-
Ein am Anfang des Briefes formulierter Freitext für eine Anrede oder Begrüßung. Z.B. „Sehr geehrte Kollegin…“

Die Angabe von medizinisch / fachlich relevanter Information in diesem Abschnitt ist NICHT ERLAUBT.
Es ist EMPFOHLEN, redundante Angaben von Patientennamen oder Aufenthaltsdaten des Patienten in dieser Section zu vermeiden.
 1.2.40.0.34.6.0.11.2.69
 CDA Device SDTC2005-09-07
Template CDA Device (Prototyp, direkt abgeleitet aus POCD_RM000040 MIF) + SDTC Extensions
 2.16.840.1.113883.10.12.815
 CDA PlayingEntity SDTC2005-09-07
Template CDA PlayingEntity (Prototyp, direkt abgeleitet aus POCD_RM000040 MIF) + SDTC Extensions
 2.16.840.1.113883.10.12.813
 Custodian2021-10-13 (1.0.1+20211213)at-cda-bbr-
Der "Verwahrer" des Dokuments stellt die Organisation dar, von der das Dokument stammt und die für die Aufbewahrung und Verwaltung des ORIGINALEN Dokuments verantwortlich ist. Jedes CDA-Dokument hat genau einen Custodian.
Der Custodian entspricht der Definition von Verwaltertätigkeit ("Stewardship") von CDA. Da CDA ein Austauschformat für Dokumente ist und ein CDA-Dokument möglicherweise nicht die ursprüngliche Form der authentifizierten Dokumente darstellt, repräsentiert der Custodian den Verwalter der ursprünglichen Quelldokumente.
 1.2.40.0.34.6.0.11.1.4
 Data Enterer2023-04-05 (1.0.1+20230717)at-cda-bbr-

Die dokumentierende Person (z.B. Medizinische Dokumentationsassistenz, Schreibkraft).

Das Element "dataEnterer" entfällt bei automatisch erstellten Dokumenten (ODD).

 1.2.40.0.34.6.0.11.1.22
 Device Compilation2023-04-06 (1.0.2+20230717)at-cda-bbr-
Datenerstellende Geräte/Software
 1.2.40.0.34.6.0.11.9.18
 Document Confidentiality Code2023-03-24 (1.0.2+20230717)at-cda-bbr-
Grundsätzlich stellt CDA Informationen zum Vertraulichkeitsstatus eines Dokuments zur Verfügung, um Anwendungssysteme bei der Verwaltung des Zugriffs auf sensible Daten zu unterstützen. Der Vertraulichkeitsstatus kann für das gesamte Dokument oder für bestimmte Teile des Dokuments gelten. Der im Header angegebene Wert gilt für das gesamte Dokument, es sei denn, er wird durch einen verschachtelten Wert überschrieben. Der tatsächliche Zugriff auf das Dokument muss von der übergeordneten Infrastrukturschicht geregelt werden.
↔ Hinweis zum XDS-Mapping: Dieses Element spiegelt sich im XDS-Attribut confidentialityCode wider. Für ELGA wird dieses fix auf "N" gesetzt.
 1.2.40.0.34.6.0.11.1.12
 Document Effective Time2023-04-11 (1.0.1+20230717)at-cda-bbr-

Dokumentiert das Erstellungsdatum bzw. den Zeitpunkt, an dem das Dokument inhaltlich fertiggestellt wurde. Damit ist jenes Datum gemeint, welches normalerweise im Briefkopf eines Schriftstückes angegeben wird (z.B. Wien, am …). Das Erstellungsdatum des Dokuments MUSS NICHT nicht mit dem Datum der rechtlichen Unterzeichnung (oder „Vidierung“) übereinstimmen.

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

Verweis auf speziellen Implementierungsleitfaden: Für das Erstellungsdatum ist das medizinisch zutreffendste Datum anzugeben, dieses MUSS für jede einzelne Dokumentenklasse im speziellen Leitfaden separat definiert werden.
Begründung: Das Erstellungsdatum wird für die Sortierung der CDA-Dokumente im Dokumentenregister (XDSDocumentEntry-Metadaten) verwendet. Es MUSS also sichergestellt werden, dass die CDA-Dokumente in der Reihenfolge sortiert werden, wie sie in einer Krankenakte sortiert werden. 
Beispiel: Laborbefunde müssen nach dem Probenentnahmedatum sortiert werden (NICHT nach dem Vidierdatum), Radiologiebefunde nach dem Ende der Bildaufnahme (NICHT nach dem Befundungszeitpunkt).

 1.2.40.0.34.6.0.11.1.11
 Document Id2021-02-19 (1.0.0+20210219)at-cda-bbr-
Die Dokumenten-Id eines CDA-Dokuments ist ein eindeutiger Instanzidentifikator, der das Dokument weltweit und für alle Zeit eindeutig identifiziert. Ein CDA-Dokument hat genau eine Id.
↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut uniqueId gemappt.
 1.2.40.0.34.6.0.11.1.1
 Document Language2021-02-19 (1.0.0+20210219)at-cda-bbr-
Gibt die Sprache des Dokuments an, sowohl in Inhalts- oder Attributwerten. Die Angabe erfolgt im Sprachcode-Attribut gemäß IETF RFC 3066 (Internet Engineering Task Force RFC 3066 for the Identification of Languages, ed. H. Alvestrand 1995).
Es enthält mindestens einen Sprachcode gemäß ISO 639 ("Code for the representation of names of languages") und einen optionalen Ländercode gemäß ISO 3166 alpha-2.
Syntax: Vereinfacht folgt der LanguaceCode dem Format ll-CC, wobei ll dem Sprachcode gemäß ISO-639-1 in Kleinbuchstaben folgt und CC dem Ländercode gemäß ISO 3166 (Tabelle mit zwei Zeichen) in Großbuchstaben. Trennzeichen ist der Bindestrich (UTF-8 "Hyphen-Minus" mit Kode 45 (dezimal) bzw. 2D (hexadezimal)).
↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut languageCode gemappt.
 1.2.40.0.34.6.0.11.1.13
 Document PracticeSettingCode - Gesundheitsberatung 14502026-02-02 (1.0.0+20260223)
Die fachliche Zuordnung des Dokumentes
Den gültigen Wertebereich für dieses Elements entnehmen Sie bitte  dem Value Set ELGA_PracticeSetting .

↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut practiceSettingCode gemappt, MUSS daher für die Anwendung in ELGA angegeben werden.
 1.2.40.0.34.6.0.11.1.58
 Document Realm2023-03-24 (1.0.1+20230717)at-cda-bbr-
Hoheitsbereich des Dokuments.

Dieses Element kennzeichnet, dass das Dokument aus dem Hoheitsbereich Österreich (bzw. Bereich der HL7 Affiliate Austria, Code „AT“) stammt.
 1.2.40.0.34.6.0.11.1.10
 Document Set Id and Version Number2021-02-19 (1.0.0+20210219)at-cda-bbr-
Versionierung des Dokuments.
Der CDA-Header repräsentiert Beziehungen zu anderen Dokumenten mit Referenz auf die Dokumenten-Identifikation. Mittels der Attribute setId und versionNumber kann eine Versionskennung des Dokuments erreicht werden.
Für ELGA-CDA-Dokumente MÜSSEN immer beide Elemente angegeben werden.
Anhänge oder Ersetzungen von Vordokumenten MÜSSEN ebenfalls diese zusätzlichen Angaben enthalten. Der genaue Zusammenhang zwischen diesen Attributen finden Sie im Kapitel „Bezug zu vorgehenden Dokumenten“.
 1.2.40.0.34.6.0.11.1.15
 Document StatusCode2021-06-24 (1.0.1+20210624)at-cda-bbr-
Status eines Dokuments.
e-Befunde sind grundsätzlich abgeschlossene bzw. "fertige" ("completed") Dokumente, daher entfällt die Angabe eines Status. In folgenden Ausnahmen SOLL der Status eines Dokuments wie folgt angegeben werden:
  • “active”: z.B. wenn bekannt ist, dass Updates folgen werden: Etwa für "vorläufige ärztliche Entlassungsbriefe" oder Laborbefunde, für die noch Ergebnisse einzelner Analysen ausständig sind
  • “nullified”: z.B. für Dokumente, die gemäß Anwendungsfall "Storno von ELGA-Dokumenten" storniert werden, wobei zusätzlich ein letztes Dokument mit Storniert-Status in der Versionskette registriert wird.
Hinweis: Die Angabe von sdtc:statusCode ändert nichts an der Versionierung (Verwendung von setId und versionNr ist unverändert). Wenn z.B. ein vorläufiger Befund mit sdtc:statusCode active durch den endgültigen Befund ohne expliziten statusCode (weil completed) ersetzt wird, muss selbstverständlich eine neue id, dieselbe setId und eine höhere versionNr angegeben werden.

↔ Hinweis zum XDS-Mapping: Der Status wird nicht in die XDS-Metadaten übernommen!
 1.2.40.0.34.6.0.11.1.45
 Document TerminologyDate2021-02-19 (1.0.0+20210219)at-cda-bbr-
Das Terminologie-Datum des Dokumentes
Das Datum, an dem die lokal zur Implementierung verwendeten Value Sets mit dem österreichischen Terminologieserver abgeglichen wurden, wird hier angegeben.
 1.2.40.0.34.6.0.11.1.46
 Document TypeId2021-02-19 (1.0.0+20210219)at-cda-bbr-
Dieses Element kennzeichnet, dass das Dokument im Format CDA R2 vorliegt.
 1.2.40.0.34.6.0.11.1.30
 Documentation Of Service Event2021-02-19 (1.0.0+20210219)at-cda-bbr-
Dokumentation der Gesundheitsdienstleistung.

Mit der Assoziation documentationOf/serviceEvent wird die eigentliche Gesundheitsdienstleistung repräsentiert, die in dem Dokument dokumentiert wird (z.B. eine Koloskopie, Appendektomie, etc.). Dies ist in engem Zusammenhang mit dem Dokumententyp zu sehen, der in ClinicalDocument/code wiedergegeben ist. Mit der documentationOf Beziehung kann die dokumentierte Gesundheitsdienstleistung näher spezifiziert werden. Dies darf natürlich nicht im Widerspruch zum Dokumententyp stehen.

↔ Hinweis zum XDS-Mapping:
Da diese Informationen in die XDS-Metadaten übernommen werden, ergeben sich folgende Implikationen:
  • Es SOLL mindestens eine Gesundheitsdienstleistung als documentationOf/serviceEvent-Element angegeben werden
  • Es können beliebig viele weitere Gesundheitsdienstleistungen als weitere documentationOf/serviceEvent-Elemente angegeben werden
  • Die serviceEvents sind die einzigen medizinischen Informationen zum Dokument im XDS-Dokumentenregister
  • Können daher als Such-/Filterkriterium verwendet werden und scheinen ggf. in den Ergebnissen der Suchabfragen auf
  • Die Zeitangaben des ersten documentationOf/serviceEvent-Elements werden in die Dokument-Metadaten übernommen
  • Die ServiceEvents stellen eine wertvolle Information zum Suchen und Filtern in den Dokument-Metadaten dar!
 1.2.40.0.34.6.0.11.1.17
 Eingebettetes Objekt Entry2023-05-09 (1.0.2+20230717)at-cda-bbr-

Achtung: Grafiken mit Transparenz sind NICHT ERLAUBT (z.B. bei GIF oder PNG möglich), da sie zu schweren Problemen bei der Wiedergabe oder Konvertierung zu PDF/A-1 führen können.

Die Größe von eingebetteten Dateien MUSS auf ein sinnvolles und angemessenes Maß beschränkt werden. Die Infrastruktur, mit der die Dateien übertragen und gespeichert werden, beschränkt die Größe der resultierenden Gesamtdatei. Der gültige Wert wird von der jeweiligen Infrastruktur angegeben (z.B. ELGA 20 MB, Stand Mai 2020) 

 1.2.40.0.34.6.0.11.3.19
 Gesundheitsberatung 14502025-09-15 (1.0.0+20260223) 1.2.40.0.34.6.0.11.0.27
 Handlungsempfehlung2025-09-15 (1.0.0+20260223)

Diese Section enthält jene Empfehlungen der Gesundheitsberatung 1450, die auf Grundlage der berufsrechtlichen Befugnisse des beratenden medizinischen Fachpersonals erteilt werden dürfen. Erfasst werden damit ausschließlich fachlich legitimierte Anweisungen oder Hinweise, die im Rahmen der telefonischen Beratung ausgesprochen werden, wie etwa Empfehlungen zur weiteren diagnostischen Abklärung oder zur Inanspruchnahme medizinischer Versorgung. Zusätzlich ist der im Rahmen der Beratung ermittelte "Best Point of Service" (BPOS) codiert hinterlegt.

 1.2.40.0.34.6.0.11.2.165
 Handlungsempfehlung Entry2025-09-16 (1.0.0+20260223)

Dieses Entry enthält den im Rahmen der telefonischen Beratung ermittelten "Best Point of Service" (BPOS) in codierter Form.

 1.2.40.0.34.6.0.11.3.190
 Informant Body2021-10-04 (1.0.1+20211213)at-cda-bbr-
Template für die Angabe des Informanten im CDA Body (Section oder Entry). Als Informanten können auftreten:
  • relatedEntity: der Patient selbst oder eine verwandte / bekannte Person 
  • assignedEntity: ein Gesundheitsdiensteanbieter (GDA)
 1.2.40.0.34.6.0.11.9.3
 Konsultationsgrund2025-09-15 (1.0.0+20260223)

Diese Section beschreibt Informationen, die vom Anrufer über den eigenen gesundheitlichen Zustand bereitgestellt werden. Dazu können insbesondere Angaben zu Vorerkrankungen, Allergien, Behinderungen, eingenommener Medikation sowie aktuellen Beschwerden gehören. Diese selbst berichteten Gesundheitsdaten werden strukturiert erfasst, um behandelnden oder beratenden Stellen einen vollständigen und verständlichen Überblick über den relevanten medizinischen Hintergrund der Person zu ermöglichen.

 1.2.40.0.34.6.0.11.2.164
 Logo Entry2021-06-28 (1.0.1+20210628)at-cda-bbr- 1.2.40.0.34.6.0.11.3.53
 Organization Compilation with id, name2021-06-28 (1.0.1+20210628)at-cda-bbr-
Wiederverwendbare Compilation mit verpflichtender Angabe von name und id.
 1.2.40.0.34.6.0.11.9.5
 Organization Compilation with name2021-02-19 (1.0.0+20210219)at-cda-bbr-
 1.2.40.0.34.6.0.11.9.9
 Organization Compilation with name, addr minimal2021-06-28 (1.0.1+20210628)at-cda-bbr-
Wiederverwendbare Compilation mit verpflichtender Angabe des name-Elements.
Minimale Adressangabe möglich.
 1.2.40.0.34.6.0.11.9.20
 Organization Name Compilation2021-06-28 (1.0.1+20210628)at-cda-bbr-
Organisations-Namen werden über das Element name abgebildet.
Dieser Implementierungsleitfaden lässt nur die unstrukturierte Angabe des Organisations-namens zu.
 1.2.40.0.34.6.0.11.9.27
 Participant Body2021-06-28 (1.0.1+20210628)at-cda-bbr- 1.2.40.0.34.6.0.11.9.13
 Performer Body2021-02-19 (1.0.0+20210219)at-cda-bbr-
Durchführende Entität der Gesundheitsdienstleistung
 1.2.40.0.34.6.0.11.9.17
 Person Name Compilation G1 M2023-04-17 (1.0.1+20230717)at-cda-bbr-
In Granularitätsstufe 1 wird der Personen-Name unstrukturiert angegeben. Die einzelnen Elemente des Namens (Vornamen, Nachnamen) werden nicht getrennt.
Name ist Mandatory. Keine nullFlavor erlaubt!
 1.2.40.0.34.6.0.11.9.12
 Person Name Compilation G22023-03-31 (1.0.1+20230717)at-cda-bbr-
In Granularitätsstufe 2 wird der Personen-Name strukturiert angegeben. Die einzelnen Elemente des Namens (mindestens ein Vorname und mindestens ein Nachname) werden getrennt angegeben.
nullFlavors für Name zugelassen!
Die korrekte Reihenfolge der einzelnen Namenselemente ist wichtig. Als Richtlinie gilt, dass diese in der "natürlichen" Reihenfolge der Benutzung des Namens angegeben werden. Das ist besonders in den folgenden Fällen relevant:
  • Präfixe (prefix) MÜSSEN immer vor dem Namen stehen, zu dem sie gehören.
  • Vornamen (given) MÜSSEN immer in der offiziellen (gesetzlichen) Sequenz stehen.
  • Nachnamen (family) und ein eventuelles Trennzeichen (meistens ‘-‘) MÜSSEN in der offiziellen Sequenz stehen, abhängig von der Wahl bei der Eheschließung.
  • Suffixe (suffix) MÜSSEN immer hinter dem Namen stehen, zu dem sie gehören.
Für die Namenselemente kann zur näheren Bestimmung ein Qualifier angegeben werden (aus dem Value Set ELGA_EntityNamePartQualifier“), v.a. für Präfix/Suffix.
Es gibt auch nicht näher bestimmte Präfixe/Suffixe, z.B. trifft das für die Angabe von "Junior" oder "Senior" bzw "Jun."/"Sen" oder "Jr."/"Sr" zu.
 1.2.40.0.34.6.0.11.9.6
 Person Name Compilation G2 M2023-03-31 (1.0.1+20230717)at-cda-bbr-
In Granularitätsstufe 2 wird der Personen-Name strukturiert angegeben. Die einzelnen Elemente des Namens (mindestens ein Vorname und mindestens ein Nachname) werden getrennt angegeben. 
Name ist Mandatory. Keine nullFlavor erlaubt!
Die korrekte Reihenfolge der einzelnen Namenselemente ist wichtig. Als Richtlinie gilt, dass diese in der "natürlichen" Reihenfolge der Benutzung des Namens angegeben werden. Das ist besonders in den folgenden Fällen relevant:
  • Präfixe (prefix) MÜSSEN immer vor dem Namen stehen, zu dem sie gehören.
  • Vornamen (given) MÜSSEN immer in der offiziellen (gesetzlichen) Sequenz stehen.
  • Nachnamen (family) und ein eventuelles Trennzeichen (meistens ‘-‘) MÜSSEN in der offiziellen Sequenz stehen, abhängig von der Wahl bei der Eheschließung. 
  • Suffixe (suffix) MÜSSEN immer hinter dem Namen stehen, zu dem sie gehören.
Für die Namenselemente kann zur näheren Bestimmung ein Qualifier angegeben werden (aus dem Value Set ELGA_EntityNamePartQualifier“), v.a. für Präfix/Suffix.
Es gibt auch nicht näher bestimmte Präfixe/Suffixe, z.B. trifft das für die Angabe von "Junior" oder "Senior" bzw "Jun."/"Sen" oder "Jr."/"Sr" zu.
 1.2.40.0.34.6.0.11.9.11
 Record Target2026-01-19 (1.2.3+20260120)at-cda-bbr-
Das RecordTarget-Element enthält den " Patienten ": Die Person, die von einem Gesundheitsdiensteanbieter (Arzt, einer Ärztin oder einem Angehörigen anderer Heilberufe) behandelt wird und über die bzw. über deren Gesundheitsdaten im Dokument berichtet wird.
↔ Hinweis zum XDS-Mapping: Inhalte dieses Elementes werden in die XDS-Metadaten zu XDSDocumentEntry. sourcePatientId übernommen.
1.2.40.0.34.6.0.11.1.3
 Stylesheet Test eBefund2021-06-28 (1.0.1+20210628)at-cda-bbr- 1.2.40.0.34.6.0.11.9.33
 Symptom Entry2025-10-29 (1.0.0+20260223)

Dieses Entry enthält das im Rahmen der Abarbeitung eines Anrufprotokolls ermittelte Leitsymptom in codierter Form.

 1.2.40.0.34.6.0.11.3.191
 Time Interval Information minimal2021-06-28 (1.0.1+20210628)at-cda-bbr- 1.2.40.0.34.6.0.11.9.15
 Übersetzung2023-04-13 (1.0.2+20230717)at-cda-bbr-
Subsection für die Übersetzung des narrativen Textes
Die Angabe des languageCode erfolgt durch Angabe eines Codes aus dem Value Set ELGA_HumanLanguage. Optional kann an diesen, mit Bindestrich getrennt, die Angabe des Landes aus ISO-Codelisten angefügt werden.
 1.2.40.0.34.6.0.11.2.8

Zusammenfassung Templates

46Templates

Templates per Szenario

Templates für Szenario v1 at-gesber-scenario-1 vom 2025-11-19

Transaktion Repräsentierendes Template Id vom
Gesundheitsberatung 1450 Gesundheitsberatung 1450 1.2.40.0.34.6.0.11.0.27 2025-09-15

Item Labels per Template

Label Templatename Id vom
atgesber_entry_SymptomEntry Symptom Entry 1.2.40.0.34.6.0.11.3.191 2025-10-29
atgesber_header_DocumentPracticeSettingCode Document PracticeSettingCode - Gesundheitsberatung 1450 1.2.40.0.34.6.0.11.1.58 2026-02-02