[unmarkierte Version]

[geprüfte Version]

Version vom 15. Juni 2025, 21:13 Uhr

	Dieses Dokument gibt wieder: Implementierungsleitfaden e-Medikation (3.0.0+20250615), OID: 1.2.40.0.34.7.8.9.3, Datum: 28.02.2025, Status: Normativ. Die Teilmaterialien gehören der Kategorie ILF an.

ELGA CDA
Implementierungsleitfäden

HL7 Implementation Guide for CDA^® R2:
e-Medikation (Version 3)

Zur Anwendung im österreichischen
Gesundheitswesen [1.2.40.0.34.7.8.9.3]

28.02.2025

3.0.0+20250615

Normativ

Inhaltsverzeichnis

1 Zusammenfassung
2 Informationen über dieses Dokument
3 Leitfadenerstellungs- und Harmonisierungsprozess
- 3.1 Revision der Leitfäden
- 3.2 Autoren und Mitwirkende
  - 3.2.1 Version 3 (aktuell)
    - 3.2.1.1 Autoren
    - 3.2.1.2 Mitwirkende
  - 3.2.2 Version 1&2
    - 3.2.2.1 Autoren
    - 3.2.2.2 Mitwirkende
4 Technischer Hintergrund
5 Konformitätsprüfung
6 Datentypen
7 Technische Spezifikation
8 Anhang

1 Zusammenfassung

Dieses Dokument bildet den in Ballot befindlichen ELGA CDA Implementierungsleitfaden der e-Medikation in seiner Version 3 ab und richtet sich an Softwareentwickler und Berater. Zum besseren Verständnis empfehlen wir Ihnen den zusammenfassenden eMed-Guide im Vorfeld zu lesen.

Dieser Implementierungsleitfaden beschreibt das Datenaustauschformat der e-Medikation in Österreich. Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage des internationalen Standards ISO/HL7 27932:2009 HL7 Clinical Document Architecture, Release 2.0 (CDA) und ist ein nationaler Standard der HL7 Austria.

Die Grundlage der Datenaustauschformate ist der internationale CDA-Standard, der sich in ELGA bereits bewährt hat. Er erlaubt es Sender und Empfänger, sich ohne vorherige Absprache zu verstehen. Der Standard hat zum Ziel, einen umfassenden Austausch von semantisch interoperablen Informationen zwischen allen beteiligten Akteuren bei der Behandlung von Patienten zu ermöglichen. Der Datenaustausch findet hierbei nicht nur innerhalb einer Einrichtung, sondern auch zwischen kooperierenden Einrichtungen und über Sektorengrenzen hinaus statt. Die Empfänger der Dokumente sollen die Inhalte benutzen und weiterverwenden können, ohne sich vorher mit dem Ersteller absprechen zu müssen.

Die wesentliche Funktion von ELGA ist die Bereitstellung von patientenbezogenen medizinischen Dokumenten, die in vielen unterschiedlichen Informationssystemen der verschiedenen Gesundheitsdiensteanbieter erstellt werden. Zu den relevanten medizinischen Daten gehören auch die Medikationsdaten, die über die ELGA-Anwendung „e-Medikation“ verfügbar gemacht werden. Dazu errichtet und betreibt der Hauptverband der Sozialversicherungen ein Informationssystem, das Ärzten, Apothekern und den ELGA-Teilnehmern selbst eine Übersicht über verordnete und abgegebene Medikamente bietet. Diese Medikationsdaten sollen nicht nur von Benutzern gelesen, sondern auch wieder in die IT-Systeme integriert und dort weiterverwendet werden können („Semantische Interoperabilität“). Rechtsgrundlage für die Umsetzung der e-Medikation ist das „ELGA-Gesetz“ (GTelG 2012 §16a) sowie die „ELGA-Verordnung“ (ELGA-VO 2015 §14, 15 und 16).

Der Implementierungsleitfaden orientiert sich an den elementaren Konzepten und dem zugrunde liegenden Modell des Dokuments Allgemeiner Implementierungsleitfaden. Dort werden die notwendigen Datentypen, Dokument-Metadaten (Header), die Möglichkeiten der Textstrukturierung, grundlegende Vorgaben für die Anwendung von Terminologien, einige allgemein genutzten Inhaltsstrukturen (Sections) sowie Codebeispiele und praktische Implementierungshilfen gezeigt. Alle weiteren, für diesen Leitfaden benötigten Elemente werden hier erklärt. Die Notation der Spezifikation der Datenaustauschformate folgt der "Art-Decor"-Schreibweise, die auf einer eigenen Seite (Art-Decor-Tabellen verstehen) erläutert wird.

Der vorgesehene Ablauf des Datenaustausches wird im Kapitel Anwendungsfälle zur Nutzung der e-Medikation beschrieben.

Übersichtstabellen für Header und Body-Strukturen

Übersichtstabelle der CDA Strukturen des Headers (administrative Daten)
Übersichtstabelle der e-Medikation CDA Strukturen (medizinische Inhalte)

Auf der Diskussionsseite werden die Fehler und Änderungswünsche an dieser Version dokumentiert.

Parallelbetriebs-Informationen e-Medikation v2 und v3

Während der 18-monatigen Übergangszeit wird in den ersten zwölf Monaten die v2-Medikationsliste standardmäßig beim Abruf bereitgestellt. Anschließend wird für die verbleibende Übergangszeit sowie danach die v3-Medikationsliste standardmäßig geliefert. Nach der Übergangszeit werden nur noch v3 Dokumente akzeptiert. Beim Abruf einzelner Rezepte, Abgaben oder von Pharmazeutischen Empfehlungen werden die Dokumente in jeweils der Version geliefert, in welcher sie auch erstellt wurden. Weiters können v3 Abgaben auf v2 Rezepte folgen, wie auch v2 Abgaben auf v3 Rezepte. Das selbe gilt auch für die Pharmazeutische Empfehlung.

Eine Abwärtskompatibilität zwischen v2 und v3 ist nicht möglich. Sobald der v3 Leitfaden verordnet ist, werden die zusätzlich möglichen Inhalte der v3 Dokumente zumindest im narrativen Teil der v2 Dokumente abgebildet. Um die Maschinenlesbarkeit der neuen v3-Informationen zu erlangen, müssen die neuen v3-Dokumente selbst verwendet werden!

2 Informationen über dieses Dokument

2.1 Impressum

Medieneigentümer, Herausgeber, Hersteller, Verleger:
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050
Internet: [[10]]
E-Mail: [[11]]
Geschäftsführer: Mag. Dr. Stefan Sabutsch, Dr. Edith Bulant-Wodak, MBA

Redaktion, Projektleitung, Koordination:

Mag. Dr. Stefan Sabutsch, stefan.sabutsch@elga.gv.at
Dr. Emmanuel Helm, emmanuel.helm@elga.gv.at (Version 3)

Abbildungen: © ELGA GmbH

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

Download unter [[13]] und [[14]]

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 und über ein öffentliches Kommentierungsverfahren kontrolliert. 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 Autoren, Herausgeber oder Mitwirkenden erhoben und/oder abgeleitet werden. Ein allfälliger Widerspruch zum geltenden Recht ist jedenfalls nicht beabsichtigt und von den Erstellern des Dokumentes nicht gewünscht.

2.3 Sprachliche Gleichbehandlung

Soweit im Text Bezeichnungen nur im generischen Maskulinum angeführt sind, beziehen sie sich auf Männer, Frauen und andere Geschlechtsidentitäten 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 soweit 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 von 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 HL7 Austria.

HL7^® und CDA^® sind die eingetragenen Marken von Health Level Seven International. 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.4.1 Urheber- und Nutzungsrechte von anderen Quellen ("Third Party IP")

Third Party Intellectual Property

Der Nutzer dieses Dokuments (bzw. der Lizenznehmer) stimmt zu und erkennt an, dass HL7 Austria nicht alle Rechte und Ansprüche an den Materialien besitzt und dass diese Materialien geistiges Eigentum Dritter enthalten und / oder darauf verweisen können ("Third Party Intellectual Property (IP)").
Die Anerkennung dieser Lizenzbestimmungen gewährt dem Lizenznehmer keine Rechte in Bezug auf Third Party IP. Der Lizenznehmer ist allein verantwortlich für die Identifizierung sowie den Erwerb der notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig.
Jegliche Handlungen, Ansprüche oder Klagen Dritter, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, liegen in der alleinigen Verantwortung des Lizenznehmers.

2.4.2 SNOMED CT

Dieser Leitfaden enthält Material, das durch SNOMED International urheberrechtlich geschützt ist. Jede Verwendung von SNOMED CT in Österreich erfordert eine aufrechte Affiliate Lizenz oder eine Sublizenz. Die entsprechende Lizenz ist kostenlos, vorausgesetzt die Verwendung findet nur in Österreich statt und erfüllt die Bedingungen des Affiliate License Agreements. Affiliate Lizenzen können über das Member Licensing and Distribution Service (MLDS) direkt beim jeweiligen NRC beantragt werden: MLDS für Österreich.

2.4.3 Weitere Terminologien

Im Folgenden finden Sie eine nicht-exhaustive Liste von weiteren Terminologien, die eine solche separate Lizenz erfordern können:

Terminologie	Eigentümer, Kontaktinformation
Logical Observation Identifiers Names & Codes (LOINC) ^[1]	Regenstrief Institute, Inc. ^[2]
Unified Code for Units of Measure (UCUM) ^[3]	Regenstrief Institute, Inc. ^[2]
International Classification of Diseases (ICD) ^[4]	World Health Organization (WHO) ^[5]
Internationalen Klassifikation der Krankheiten (ICD) in der jeweils aktuellen Fassung des für Gesundheit zuständigen Bundesministeriums ^[6]	Bundesministerium für Soziales, Gesundheit, Pflege und Konsumentenschutz www.sozialministerium.at
Anatomical Therapeutic Chemical Classification System (ATC) ^[7]	World Health Organization (WHO)^[5]
Pharmazentralnummer (PZN)	ARGE Pharma im Fachverband der chemischen Industrie Österreichs (FCIO) der Wirtschaftskammern Österreichs (WKO) ^[8]
EDQM-Codes	Europäisches Direktorat für die Qualität von Arzneimitteln ^[9]
Medical Device Communications (MDC) vom ISO/IEEE 11073 Standard	MDC wird als Substandard 10101 "Nomenclature" in "Health informatics - Medical / health device communication standards", kurz 11073, geführt und werden mit einem Copyright bei IEEE SA am österreichischen Terminologiebrowser bereitgestellt. ^[10], ^[11]

Die Terminologien werden am österreichischen Terminologieserver zur Verfügung gestellt.^[12]

2.5 Verbindlichkeit

Die Verbindlichkeit und die Umsetzungsfrist dieses Leitfadens sind im Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.

Der Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf [[15]] zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten ("Mandatory" [M], "Required" [R] und "Fixed" [F]), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter [[16]]veröffentlicht werden.

Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit österreichischem und europäischem Recht, insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz, Gesundheitstelematikgesetz 2012, DSGVO) zu erfolgen. Technische Möglichkeiten können gesetzliche Bestimmungen selbstverständlich nicht verändern, vielmehr sind die technischen Möglichkeiten im Einklang mit den Gesetzen zu nutzen.

Die Einhaltung der gesetzlichen Bestimmungen liegt im Verantwortungsbereich der Ersteller der CDA-Dokumente.

2.6 Verwendete Grundlagen und Bezug zu anderen Standards

Grundlage dieses Implementierungsleitfadens ist der internationale Standard "HL7 Clinical Document Architecture, Release 2.0" (CDA ©), für die das Copyright © von Health Level Seven International^[13] gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert^[14].

CDA definiert die Struktur und Semantik von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und Patienten. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen. Das Datenmodell von CDA und seine Abbildung in XML^[15] folgen dem Basisstandard HL7 Version 3^[16] mit seinem Referenz-Informationsmodell (RIM). Dieser Leitfaden verwendet das HL7-Template-Austauschformat zur Definition der "Bausteine" (Templates) und ART-DECOR® ^[17] als Spezifikationsplattform.

HL7 Clinical Document Architecture (CDA) ^[18]
HL7 Referenz-Informationsmodell (RIM)^[19]
HL7 V3 Datentypen ^[20]
HL7 Template-Austauschformat Specification and Use of Reusable Information Constraint Templates, Release 1^[21]

Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)^[22], die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden. Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifikationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.

Die e-Medikation basiert auf den Vorgaben des Allgemeinen Implementierungsleitfadens (Version 3).

Für die Modellierung der technischen Spezifikation der Inhalte wurde bei dieser Hauptversion der e-Medikation die [Spezifikation des eHDSI CDA Leitfaden für "eHDSI ePrescription" und "eHDSI eDispensation"] als wesentliche Grundlage gewählt, um eine "Abwärtskompatibilität" herzustellen. Das Bedeutet, das jedes e-Medikation Rezept CDA nach eHDSI ePrescription Spezifikation valide ist und jedes e-Medikation Abgabe CDA nach eHDSI eDispensation Spezifikation valide ist. Für eine tatsächliche Übertragung in den eHDSI Kontext wären jedoch Transformations-Schritte notwendig! Darunter fallen die Auftrennung jeder Verordnung in einzelne Rezepte, die Auftrennung von jedem Abgabe-Entry in eine eigene Abgabe wie auch das Extrahieren der Informationen der Pharmazeutischen Empfehlung als einzelne ePrescription oder eDispensations. Zusätzlich sind Übersetzungen von Terminologien notwendig. Es ist jedoch zu beachten, dass umgekehrt nicht jede eHDSI ePrescription oder eHDSI eDispensation valide zur e-Medikation Spezifikation sind!

2.7 Wichtige unterstützende Materialien

Auf der Website e-Medikation Guide werden unter anderem folgende Materialien zur Verfügung gestellt:

die PDF-Version dieses Leitfadens
Beispieldokumente
Referenz-Stylesheet (Tool zur Darstellung im Browser - Konvertierung in HTML)
CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
ein erweitertes CDA-Schema
Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA-Dateien

Die im weiteren angeführten Templatespezifikationen wurden im Art-Decor Projektrepository [[17]] erstellt und können dort eingesehen werden.

Gemeinsam mit diesem Leitfaden werden in diesem Wiki weitere Dokumente zur Unterstützung bereitgestellt:

Vorgaben zur Registrierung von CDA-Dokumenten (Leitfaden für XDS-Metadaten)
Hinweise für die zu verwendenden Terminologien
Leitfaden zur richtigen Verwendung von Terminologien

Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [[18]] gesendet werden.

2.8 Bedienungshinweise

2.8.1 Farbliche Hervorhebungen und Hinweise

Themenbezogene Hinweise zur besonderen Beachtung:

Hinweis:
Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden.

Hinweis auf anderen Implementierungsleitfaden:

Verweis
Verweis auf den Allgemeinen Leitfaden:…

2.8.2 PDF-Navigation

Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:

Rücksprung: Alt + Pfeil links und Vorwärts: Alt + Pfeil rechts
Seitenweise blättern: "Bild" Tasten
Scrollen: Pfeil nach oben bzw. unten
Zoomen: Strg + Mausrad drehen
Suchen im Dokument: Strg + F

3 Leitfadenerstellungs- und Harmonisierungsprozess

Für die Ausgestaltung der Inhalte von "CDA Implementierungsleitfäden" ist eine breite Beteiligung der Stakeholder wesentlich, um die praktische Nutzbarkeit und die Akzeptanz durch die ELGA-Benutzer sicherzustellen. Für diese interdisziplinären Expertengruppen stehen nicht die technischen, sondern vor allem medizinisch-inhaltliche Aspekte im Vordergrund. Die technischen Inhalte werden Großteils von den Redaktionsteams beigetragen.

Ein wesentlicher Schritt auf dem Weg zur Interoperabilität der IT-Systeme im Gesundheitswesen ist die Einigung auf Vorgaben für eine einheitliche Dokumentation und Codierung der Informationen. Diese durch die Arbeitsgruppen erreichte "Harmonisierung" etabliert neue nationale Qualitätsstandards der medizinischen Dokumentation. Die Leitfäden werden über ein reguläres Standardisierungsverfahren ("Ballot") durch die HL7 Anwendergruppe Österreich (HL7 Austria) zu einem nationalen HL7 Standard.

Weitere Details zum Vorgehensmodell sind im Allgemeiner Leitfaden - Kapitel Leitfadenerstellungs- und Harmonisierungsprozess - Vorgehensmodell zu finden.

Dieser Implementierungsleitfaden entstand durch die Harmonisierungsarbeit der AG e-Medikation v3, die im Zeitraum von September 2024 bis Dezember 2024 tagte. Die Teilnehmer der Arbeitsgruppe wurden durch ihre Organisation delegiert.

Die Arbeitsgruppe harmonisierte primär die inhaltlichen Vorgaben und soweit möglich die zu verwendenden Terminologien (Value Sets). Die Formulierung der technischen Spezifikation des CDA Implementierungsleitfadens e-Medikation erfolgte durch die ELGA GmbH parallel bzw. nach der inhaltlichen Festlegung.

Der Leitfaden wird in einem technischen Abstimmungsverfahren durch die HL7 Austria ("Ballot") zu einem österreichischen Standard. Die Verbindlichkeit zur Anwendung soll durch eine Novellierung des Gesundheitstelematikgesetzes 2012, BGBl.I Nr.111/2012 begründet werden.

3.1 Revision der Leitfäden

Neue und geänderte Anforderungen sowie Verbesserungen können neue Versionen der bestehenden Spezifikationen notwendig machen.

Der CDA-Koordinator evaluiert in regelmäßigen Abständen, ob, und welche Änderungen (etwa durch neue medizinische oder gesetzliche Anforderungen) notwendig sind. Aufgrund des Berichts des CDA-Koordinators empfiehlt die ELGA GmbH die Erstellung von Revisionsversionen der bestehenden Leitfäden. Die geplanten Änderungen sollen mit den maßgeblichen Stakeholdern abgestimmt werden.

Neue Versionen, die "verpflichtende Elemente" (Sections oder Entries) neu einführen oder entfernen, sind "Hauptversionen", die jedenfalls über eine Durchführungsverordnung verbindlich gemacht und veröffentlicht werden. Andere Versionen sind "Nebenversionen". Alle verbindlichen Versionen sind auf [[19]] zu veröffentlichen.

3.2 Autoren und Mitwirkende

Der vorliegende Leitfaden wurde unter der Leitung der ELGA GmbH von den Autoren und unter Mitwirkung der genannten Personen (Mitglieder der Arbeitsgruppe) erstellt. Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht. Die HL7 Austria und die ELGA GmbH genehmigen ausdrücklich die Anwendung des Leitfadens ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente und weisen darauf hin, dass dies mit dem Einverständnis aller Mitwirkenden erfolgt.

3.2.1 Version 3 (aktuell)

3.2.1.1 Autoren

Das Redaktionsteam für die Hauptversion v3 bestand aus folgenden Personen¹:

Name	Organisation	Rolle
Nikola Tanjga	ELGA GmbH	Autor
Emmanuel Helm	ELGA GmbH, HL7 Austria	Herausgeber
Georg Stockinger	SVC	Mitautor
Martin Steiner	SVC	Mitautor
Leander Kirchpfening	SVC	Mitautor

3.2.1.2 Mitwirkende

Teilnehmer der Arbeitsgruppe e-Medikation v3¹: Matthias Frankfurt (Österreichische Ordensprovinz des Hospitalordens des heiligen Johannes von Gott), Gerhard Stimac (Sprecher Plattform für Digitale Gesundheit – FEEI), Alexander Moussa (Arzt für Allgemeinmedizin, Vorsorgemedizin; ÖÄK), Gmeiner Stefanie (ÖÄK), Johann Kerschbaum (ÖAK), Herwig Loidl (LOIDL Consulting & IT Services GmbH), Annemarie Goldmann (LOIDL Consulting & IT Services GmbH), Schnurer Florian (Fachverband der Elektro- und Elektronikindustrie), Christoph Unfried (CGM Arztsysteme Österreich Gmbh, HCS Gmbh, HL7 Austria), Elisabeth Strahser (Fachverband UBIT), Andreas Voelkerer (Gemeinnützige Oberndorfer Krankenhausbetriebsgesellschaft m.b.H.), Jürgen Brandstätter (IHE Austria), Gergely Mentsik (Latido Health Tech GmbH), Moritz Buchmann (ELGA GmbH), Katharina Künstner (FEEI), Rainer Schmidradler (SVC - Sozialversicherungs-Chipkarten Betriebs- und Errichtungsgesellschaft m.b.H.), Ruprecht Leitner (Österreichische Apotheker-Verlagsgesellschaft m.b.H.), Harald Kornfeil (ÖGAM / ÖÄK) Alexander Mense (HL7 Austria), Stefan Sabutsch (ELGA GmbH, HL7 Austria),

¹ Personen sind ohne Titel angegeben

3.2.2 Version 1&2

3.2.2.1 Autoren

Das Redaktionsteam für die Hauptversion v1&2 bestand aus folgenden Personen¹:

Name	Organisation	Rolle
Stefan Sabutsch	ELGA GmbH, HL7 Austria	Herausgeber, Projektleiter, CDA Koordinator
Jürgen Brandstätter	CodeWerk Software Services and Development GmbH	Autor, Fachkoordinator

3.2.2.2 Mitwirkende

Teilnehmer der Arbeitsgruppe e-Medikation v1&2 2015¹: Michael Bauer (SVC - Sozialversicherungs-Chipkarten Betriebs- und Errichtungsgesellschaft m.b.H.), Michael Deimel (SVC), Tanja Krammer (SVC), Martin Asenbaum (SVC), Alexander Kollmann (ELGA GmbH), Oliver Kuttin (ELGA GmbH), Carina Seerainer (ELGA GmbH)

4 Technischer Hintergrund

Der technische Hintergrund soll im allgemeinen Leitfaden nachgelesen werden.

4.1 Allgemeine Richtlinien für ELGA CDA-Implementierungsleitfäden

Die allgemeinen Richtlinien für ELGA CDA-Implementierungsleitfäden sollen beachtet werden.

4.2 Voraussetzungen für den Zugriff auf e-Medikation in ELGA

Der ELGA-GDA muss in ELGA angemeldet und berechtigt sein sowie eine gültige Kontaktbestätigung für den Patienten besitzen. Zudem muss der Patient ELGA-Teilnehmer sein und darf keinen generellen, partiellen oder situativen Widerspruch gegen ELGA oder die e-Medikation eingelegt haben.

4.3 Anwendungsfälle des Dokumentenmanagements

Die folgenden Kapitel aus dem allgemeinen Leitfaden stellen eine Zusammenfassung der Inhalte der ELGA-Gesamtarchitektur, des Leitfadens XDS Metadaten und Usability Styleguides zum Thema e-Befunde dar. Detailinformationen sind in den entsprechenden Dokumenten nachzulesen (verfügbar auf der Homepage der [GmbH]). Die wesentlichen Anwendungsfälle sind

4.4 Anwendungsfälle zur Nutzung der e-Medikation

Die Einsatzszenarien für dieses Datenaustauschformat werden in Form von Anwendungsfällen beschrieben, um dem Leser den Hintergrund zu vermitteln. Diese Anwendungsfälle bieten zusätzlichen Einblick in die aktuelle Umsetzung der ELGA-Anwendung e-Medikation sowie dem Zusammenspiel der CDA-Dokumente.

Folgende Akteure werden in der ELGA-Anwendung e-Medikation (eMEDAT) definiert:

Akteure im niedergelassenen Bereich
- Arzt
  - Allgemeinmediziner mit und ohne Kassenvertrag
  - Facharzt mit und ohne Kassenvertrag
  - Hausapotheker (Da im GDA-Index jeder GDA nur eine Rolle besitzt und es die Rolle „Hausapotheker“ nicht gibt, haben Hausapotheker dieselbe Rolle wie niedergelassene Ärzte ohne Hausapotheke. Somit hat jeder Arzt auch die Funktionalitäten zur Abgabe zur Verfügung.)
  - etc.
- Arztpraxisassistent
Krankenanstalt
- In der e-Medikation erfolgt keine Unterscheidung zwischen stationären und ambulanten Bereich.
Akteure in der Apotheke
- Pharmazeut
- Pharmazeutisch-kaufmännischer Assistent
- Pharmazeutisch-technischer Assistent
Einrichtung der Pflege
- Die GDA-Software muss eine klare Identifikation des ärztlichen Personals ermöglichen, so das nur diese eine Verordnung durchführen können! Wenn die Pflegesoftware keine Möglichkeit dazu hat, dann können auch keine Verordnungen ausgestellt werden.
ELGA-Teilnehmer
- Patient
- Vertreter
  - ELGA-Ombudsstelle
  - Vollmachtnehmer
  - Gesetzlicher Vertreter
  - etc.

Der gegenständliche Implementierungsleitfaden „e-Medikation“ definiert die folgenden CDA-Dokumente: Rezept, Abgabe, Korrekturmeldung (Pharmazeutische Empfehlung) und Medikationsliste. Eine Korrekturmeldung jeglicher Rezepte oder Abgaben erfolgt immer mit der Pharmazeutischen Empfehlung. Um den Medikationsprozess und die folgend beschriebenen Anwendungsfälle abbilden zu können, werden diese Dokumente mit den folgenden Status in der e-Medikation abgebildet:

Rezept (PRESCRIPTION; Ein Rezept wird durch ein Prescription Dokument abgebildet und kann eine oder mehrere Verordnungen enthalten. Bezüglich der möglichen Statuswerte unterscheiden sich das Prescription Dokument und die einzelnen Verordnungen.)
- OFFEN
- EINGELÖST
- STORNIERT
- ABGELAUFEN
Verordnung
- OFFEN
- EINGELÖST
- STORNIERT
- NICHT_DISPENSIERT
Abgabe (DISPENSE)
- ABGEGEBEN
- ABGESETZT (Korrekturmeldung vorhanden)
- STORNIERT (deprecated)
Korrekturmeldung (Pharmazeutische Empfehlung, Pharmaceutical Advice)
- GÜLTIG
- STORNIERT (deprecated)
Medikationsliste
- GÜLTIG
- ERSETZT (deprecated)

4.4.1 Verordnung(en) mit Rezept anlegen

Im Zuge der Behandlung stellt der Arzt fest, dass dem ELGA-Teilnehmer ein oder mehrere Arzneimittel verordnet werden müssen. Eine Verordnung besteht immer nur aus genau einer Medikation (= ein Arzneimittel). Das Rezept kann aus mehreren Verordnungen bestehen und bildet somit die Klammer über die Verordnungen. Das Rezept mit den Verordnungen wird mit einer eindeutigen eMED-ID versehen. Eine Speicherung von Verordnungen ohne Zuordnung eines Rezeptes ist nicht gültig. Die Prüfungen der Arzneimittel z.B. auf potenzielle Wechselwirkungen, Kontraindikationen, Dosierungen, etc. wie auch Bewilligungen von Arzneimitteln erfolgen in der Eigenverantwortung des Arztes und sind nicht Gegenstand der e-Medikation. Die Verordnung wird als geprüft und ggf. bewilligt angesehen, wenn das zugeordnete Rezept in der e-Medikation gespeichert ist. Jede Verordnung ist gültig, sobald sie in der e-Medikation gespeichert ist, somit ist eine Verordnung in der Zukunft nicht möglich! Außnahmen gelten nur für das Substitutionsrezept.

4.4.1.1 Vorbedingung

ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
e-Medikation Vorbedingung: keine

4.4.1.2 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Einrichtung der Pflege

4.4.1.3 Ablauf

Die Erfassung eines Rezepts mit Verordnung stellt folgende Prozessschritte in der GDA-Software dar:

Arzneimittel auswählen: Der Arzt wählt eine oder mehrere Arzneimittelspezialitäten aus einem Katalog („ASP-Liste“, die Liste der humanen Arzneispezialitäten gelistet nach PZN) aus, wobei Handelsname, Pharmazentralnummer (PZN) sowie andere Daten zur Beschreibung des Arzneimittels (Stärke, Darreichungsform, Packungsgröße, Zulassungsnummer etc.) automatisch aus einem Katalog mit allen ELGA-relevanten Arzneimittelspezialitäten übernommen werden können. Alternativ zu einer Arzeimittelspezialität kann auch eine magsitrale Zubereitung gespeichert werden. In diesem Fall ist zwingend mindestens ein Wirkstoff codiert anzugeben.
eMED-ID anfordern: Die Vergabe der eindeutigen eMED-ID erfolgt zentral durch die Serverkomponente e-Medikation und kann über eine entsprechende Schnittstelle angefordert werden.
Arzneimittel ausnehmen: Arzneimittel können von der Speicherung in e-Medikation ausgenommen werden (funktionale Anforderung an die GDA-Software)
Rezept mit Verordnung in e-Medikation speichern: Prüfung der Eingabedaten
Rezept drucken (Anforderung an die GDA-Software, kein Teil in der e-Medikation). Die eMED-ID soll, sofern technisch möglich, sowohl als Klartext als auch als maschinenlesbarer Code (2D-Matrix-Code) auf dem e-Rezept-Ausdruck bzw. einem Papierrezept aufgedruckt werden (§18 Abs. 4 Z. 4 GTelG 2012) um die Versorgungskontinuität (verbesserte Arbeitsabläufe) als auch die anwenderfreundlichen Umsetzung der e-Medikation zu unterstützen.

Der Arzt kann pro „Patientenkontakt“ (Besuch) mehrere Rezepte mit Verordnungen in e-Medikation speichern; Rezepte können jedoch nur einzeln übermittelt werden. Das Rezept mit den Verordnungen ist sofort nach Speicherung in e-Medikation gültig.

Der aktuelle Katalog „Liste der humanen Arzneispezialitäten gelistet nach PZN“ (ASP-Liste) wird von der AGES, der Österreichischen Agentur für Ernährungssicherheit bereitgestellt und kann über den [[20]] frei bezogen werden.

4.4.1.3.1 Anmerkungen zu den Datenfeldern

Das Rezept wird durch eine Rezeptart gekennzeichnet, um die Gültigkeitsdauer prüfen zu können. In e-Medikation werden folgende Rezeptarten berücksichtigt:

Kassenrezept – Gültig für einen Monat vom Ausstellungszeitpunkt bis zum gleichen Tag des Folgemonats 23:59 Uhr; eine Einlösung möglich; im Zuge des Prozesses „Besorger“ (siehe unten) wird bei einer gespeicherten Teilabgabe die gesamte Gültigkeitsdauer auf 3 Monate verlängert; es ist nicht möglich, zusätzliche Einlösungen anzugeben.
- Beispiel: Wenn ein Kassenrezept am 1.4., 16:45 Uhr ausgestellt wird, dann ist es bis 1.5., 23:59 Uhr gültig.
Privatrezept - 12 Monate gültig, sofern die erste Einlösung innerhalb von 1 Monat ab Erstelldatum erfolgt ist
- Die maximale Gültigkeitsdauer beträgt 365 Tage bzw. sind bis zu 6 Einlösungen möglich, wobei Gültigkeitsdauer und Anzahl der möglichen Einlösungen vom Arzt definiert werden können. (§ 4 Abs. 1 RezeptpflichtG).
Substitutionsrezept – Maximale Gültigkeitsdauer von 12 Monaten. Das "GültigVon" Datum darf maximal einen Monat in der Zukunft liegen. Es ist nicht möglich, zusätzliche Einlösungen anzugeben.

Die Gültigkeitsdauer je Rezeptart folgt den rechtlichen Vorgaben. Es wird daher der Ausstellungstag in die Berechnung der Einlösefrist nicht mit eingerechnet. Die Gültigkeiten von Rezepten und somit die Verfügbarkeit in e-Medikation ergeben sich folgendermaßen:

Wenn ein Rezept mit den Verordnungen in e-Medikation gespeichert ist, dann erhält das Rezept und seine Verordnungen den Status OFFEN.
Ein Kassenrezept muss innerhalb von 1 Monat eingelöst werden, sonst erhält das Rezept den Status ABGELAUFEN.
Ein Privatrezept muss innerhalb von 1 Monat eingelöst werden, sonst erhält es den Status ABGELAUFEN.
Ein Substitutionsrezept ist im Status ABGELAUFEN, wenn das „bis Datum“ erreicht ist.
Die Anzahl der Einlösungen bei Privatrezepten werden auf Verordnungsebene geprüft. Sobald die maximale Anzahl der Einlösungen für jede einzelne Verordnung erreicht ist, erhält das Rezept den Status EINGELÖST. Solange die Anzahl der Einlösungen (Abgaben) nicht erreicht wurde, hat die Verordnung und das Rezept den Status OFFEN.
Die Rezeptart beeinflusst die Regeln, die bei der Einlösung der Verordnung zur Anwendung kommen. Siehe dazu Use Cases „Abgabe mittels eMED-ID durchführen“ und „Abgabe über e-card durchführen“.

Es können nur Arzneimittel verordnet werden, die in der Liste der Arzneimittelspezialitäten („ASP-Liste“) vorkommen und als gültig vermerkt sind (ELGA_Gültigkeit = true). Ohne Verordnungsbezug kann nur die Abgabe jener OTC-Präparate in der e-Medikation gespeichert werden, die auch wechselwirkungsrelevant (ELGA_MedikationWechselwirkungsRelevant = true) sind.

Bei Kassen- und Substitutionsrezepten müssen alle Verordnungen mit einer Abgabe oder Leerabgabe (Abgabe von 0 Packungen) referenziert werden.

4.4.1.3.2 Ergebnis im Gutfall

Die im Rezept angegebenen Verordnungen sind im Status OFFEN in e-Medikation gespeichert. Die zuvor vom Server erstellte eMED-ID wurde für die Dokumentenerstellung verwendet und dem e-Rezept Service als Parameter übergeben.

4.4.1.3.3 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler. Es können die folgenden Fehlerfälle aus der Schnittstelle zur e-Medikation heraus auftreten:

Speichern der Verordnung in e-Medikation nicht möglich
eMED-ID nicht ermittelbar

Hinweis: Die Ausstellung eines e-Rezepts bzw. eines Papierrezepts darf durch ein etwaiges „Nicht-funktionieren“ der e-Medikation nicht verhindert werden.

4.4.2 Rezept mit Verordnung(en) abrufen

Im Zuge der Abgabe eines Arzneimittels in zum Beispiel einer Apotheke kann der Akteur die Rezepte samt Verordnungen zu einem ELGA-Teilnehmer abrufen. Alternativ zu einer gültigen Kontaktbestätigung kann das Rezept mittels eMED-ID abgerufen werden.

4.4.2.1 Vorbedingung

ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt (z.B. durch Identifikation mittels e-card).
e-Medikation Vorbedingung: Verordnungen vorhanden

4.4.2.2 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Apotheke
Einrichtung der Pflege

4.4.2.3 Ablauf

Der Akteur kann die Verordnungen des ELGA-Teilnehmers abfragen. Es stehen grundsätzlich zwei Suchvarianten zur Verfügung:

Alle Verordnungen von noch nicht eingelösten und noch nicht abgelaufenen Rezepten (findPrescriptionsForDispense)
Alle Verordnungen in einem bestimmten Zeitraum (findPrescriptions)

Für diese beiden Abfragen gibt es zwei mögliche „Startpunkte“:

Startpunkt 1: Suche mit eMED-ID Assertion
- Suche ohne einem Patientenkontakt im ELGA-Berechtigungssystem, auf Basis der eMED-ID Assertion, welche aufgrund der Angabe einer eMED-ID ausgestellt wurde. Mit dieser Assertion können ausschließlich Dokumente gefunden werden, die mit der betreffenden eMED-ID zusammenhängen (Rezept und zugehörige Abgaben, bzw. Pharmaceutical Advices).
Startpunkt 2: Suche mit Patientenkontakt
- Bei der Suche nach Rezepten mit einem Patientenkontakt im ELGA-Berechtigungssystem (z.B. auf Basis einer vorhandenen und gültigen Kontaktbestätigung), können alle Rezepte des ELGA-Teilnehmers gesucht werden.

Es gibt keine Einschränkung bei der Anzeige der Datenfelder (z.B. ausstellender GDA darf angezeigt werden). Es werden über die Schnittstelle alle verfügbaren Datenfelder zu einer Verordnung/Rezept geliefert (lt. Datenmodell).

4.4.2.3.1 Ergebnis im Gutfall

Im Gutfall werden dem Akteur die angeforderten Rezepte/Verordnungen sowie die dazugehörigen Korrekturmeldungen (Pharmazeutischen Empfehlungen) zurückgeliefert und stehen zur weiteren Verwendung zur Verfügung.

4.4.2.3.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.

4.4.3 Verordnung stornieren

Der Akteur muss die Verordnung stornieren können. Es sind folgende Fälle möglich:

einzelne Verordnung stornieren (über eine Korrekturmeldung). Dieses Storno ist von allen berechtigten Akteuren (siehe unten) durchführbar.
ganzes Rezept stornieren (über ein Update der XDS-Metadaten oder alle Verordnungen über eine Korrekturmeldung stornieren). Dieses Storno ist nur durch den Ersteller des Dokuments durchführbar.

4.4.3.1 Vorbedingung

ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
e-Medikation Vorbedingung: Verordnung mit dem Status OFFEN ist vorhanden

4.4.3.2 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Einrichtung der Pflege

4.4.3.3 Ablauf

Einzelne Verordnung stornieren:
- Eine Verordnung kann mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) storniert werden. Der Akteur bestimmt die Verordnung (oder mehrere), welche storniert werden soll/sollen. Die Auswahl erfolgt über die VerordnungsID. Die Verordnung erhält den Status STORNIERT. Eine Stornierung ist nur zulässig, falls die referenzierte Verordnung bereits in e-Medikation vorhanden ist und den Status OFFEN besitzt. Bereits abgegebene Verordnungen können nicht mehr verändert werden.
Ganzes Rezept stornieren:
- Ein Rezept gilt als storniert, wenn einer der folgenden beiden Methoden angewandt wird:
  - Der Akteur bestimmt alle Verordnung des Rezepts und storniert jede einzelne Verordnung des Rezepts. Das Rezept erhält den Status STORNIERT, wenn alle zugeordneten Verordnungen den Status STORNIERT aufweisen.
  - Der Akteur bestimmt das Rezept mit den Verordnungen (über eMED-ID). Es wird ein Update der Metadaten des Rezepts ausgeführt. Dies kann nur vom Ersteller des Rezepts durchgeführt werden.

4.4.3.3.1 Ergebnis im Gutfall

Die Verordnung bzw. das Rezept erhalten den Status STORNIERT.

4.4.3.3.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Die Verordnung behält den Status OFFEN.

4.4.4 Verordnung/Rezept ändern

Der Arzt muss eine bereits in e-Medikation gespeicherte Verordnung ändern können. Die Änderungen darf von jedem Arzt vorgenommen werden, unabhängig davon, ob der Arzt die Verordnung erstellt hat oder nicht.

4.4.4.1 Vorbedingung

ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
e-Medikation Vorbedingung: Verordnung mit dem Status OFFEN ist vorhanden.

4.4.4.2 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Einrichtung der Pflege

4.4.4.3 Ablauf

Eine Verordnung kann mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) geändert werden. Der Arzt kann nur die folgenden Datenfelder einer Verordnung ändern, jedoch nicht das verordnete Arzneimittel oder die Menge selbst:

Art der Anwendung
Zusatzinformation
Ergänzende Information
Alternative Einnahme
Tagesdosierung
Morgen Dosierung
Mittags Dosierung
Abends Dosierung
Nachts Dosierung
Frequenz
Therapieart
Tagesangabe
Einnahmestart/-ende/-dauer
Indikation
Verifizierungsdatum

Verordnungen mit dem Status ABGELAUFEN, NICHT DISPENSIERT, EINGELÖST oder STORNIERT können nicht geändert werden. Die Medikation (z.B. Handelsname) einer Verordnung kann NICHT geändert werden. Ist eine Änderung der Medikation notwendig, kann der Akteur eine neue Verordnung anlegen und eine Stornierung der zu ändernden Verordnung veranlassen (Rücksprache). Das Gleiche gilt für die Angabe „Menge“, dazu muss der Arzt ein weiteres Rezept mit einer entsprechenden Verordnung ausstellen. Die Verringerung der Menge kann nicht abgebildet werden. Die eMED-ID am Rezept muss bei einer Änderung der Verordnung gleich bleiben. Jede Änderung ist zu protokollieren; Es muss nachvollziehbar sein,

wann die Änderung der Verordnung durchgeführt wurde.
welcher GDA die Änderung der Verordnung durchgeführt hat.

Der Aussteller des Rezepts mit der entsprechenden Verordnung bleibt gleich und darf nicht durch die Änderung der Verordnung verändert werden.

4.4.4.3.1 Ergebnis im Gutfall

Im Gutfall wird die Änderung der Datenfelder der Verordnung über eine Korrekturmeldung durchgeführt und in e-Medikation gespeichert.

4.4.4.3.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Die in e-Medikation gespeicherte Verordnung wurde nicht verändert. Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.

4.4.5 Abgabe mit Verordnungsbezug durchführen

Eine Apotheke bzw. ein hausapothekenführender Arzt möchte ein Rezept für einen ELGA-Teilnehmer einlösen, dessen Verordnungen bereits in der e-Medikation gespeichert wurden. Hierzu müssen zunächst die Verordnungsdaten abgerufen werden und anschließend die Abgaben mit dem entsprechenden Verordnungsbezug gespeichert werden. Abgaben können rückdatiert erstellt werden! Für die Abfrage der Verordnungen aus der e-Medikation bestehen grundsätzlich 2 Möglichkeiten:

Abfrage der Verordnungsdaten mittels eMED-ID
Abfrage der Verordnungsdaten auf Basis einer bestehenden ELGA-Kontaktbestätigung

4.4.5.1 Vorbedingung

ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
e-Medikation Vorbedingung: Verordnung mit dem Status OFFEN ist vorhanden

4.4.5.2 Akteure

Arzt im niedergelassenen Bereich
Apotheke

4.4.5.3 Ablauf

Rezept mit Verordnungen abrufen
- Üblicherweise wird in einem e-Rezept-Datensatz die korrespondierende eMED-ID gespeichert und liegt daher beim Abruf des e-Rezepts elektronisch als Zusatzinformation vor. Alternativ kann die eMED-ID durch Scannen des Matrix-Codes auf dem e-Rezept-Ausdruck oder durch manuelle Eingabe erfolgen. In diesem Fall ist keine ELGA-Kontaktbestätigung erforderlich. Allerdings ist hierdurch ausschließlich der Zugriff auf die Daten des durch die eMED-ID referenzierten Rezepts möglich und nicht auf andere in der e-Medikation gespeicherte Daten (z.B. komplette e-Medikationsliste des Patienten).
- Sämtliche zu einem ELGA-Teilnehmer in der e-Medikation gespeicherten Verordnungsdaten können auf Basis einer bestehenden ELGA-Kontaktbestätigung abgerufen werden.
Abgabe in der e-Medikation speichern
- Die Daten aus der Verordnung sind in der Regel vollständig für die Abgabe zu übernehmen. In Sonderfällen (z.B. Austausch eines Medikaments nach Rücksprache mit dem Arzt) können die aus der Verordnung übernommenen Daten geändert werden.
- Falls bereits erfolgte Abgaben nacherfasst werden sollen (z. B. aufgrund technischer Probleme zum Zeitpunkt der eigentlichen Abgabe), wird als Erfassungsdatum der Zeitpunkt der Nacherfassung gesetzt, während als Abgabedatum das tatsächliche Abgabedatum in der Vergangenheit gesetzt wird.

In der Fachlogik gelten folgende Prüfregeln:

Damit die Verordnung eingelöst werden kann, muss diese den Status OFFEN haben.
Rezepte mit der Rezeptart Privatrezepte können von mehreren Akteuren eingelöst werden, z.B. verschiedene Apotheken.
Rezepte mit der Rezeptart Kassenrezept und Substitutionsrezept können nur von einem Akteur eingelöst werden. Somit müssen alle Verordnungen zu einem Rezept abgegeben werden. Verordnungen, die nicht abgegeben werden, erhalten den Status NICHT DISPENSIERT.
Zu Rezepten mit dem Status ABGELAUFEN können keine Abgaben mehr gespeichert werden. Die (nachträgliche) Speicherung von Abgaben zu einem abgelaufenen Rezept kann im Anlassfall allerdings ohne Verordnungsbezug erfolgen (siehe Kapitel „Abgabe ohne Verordnungsbezug durchführen“.

4.4.5.3.1 Sonderfälle

Austausch: Wird ein Arzneimittel verordnet, das in der Apotheke nicht vorrätig ist, kann der Apotheker bzw. der hausapothekenführende Arzt im Rahmen der gesetzlichen Bestimmungen ein wirkstoffgleiches Arzneimittel bzw. nach Rücksprache mit dem Arzt ein alternatives Arzneimittel abgeben. Jedenfalls ist das tatsächlich abgegebene Arzneimittel in e-Medikation zu speichern und der Verordnung/dem Rezept zuzuordnen, um die zugrundeliegende Verordnung einzulösen.

Besorger: Der Prozess des „Besorgers“ (wenn ein Arzneimittel nicht lagernd ist und bestellt werden muss) wird in der e-Medikation abgebildet. Dabei wird das Rezept von der Apotheke eingelöst, und die Abgabe wird als Teilabgabe gekennzeichnet (siehe Markierung FFP „First Fill, Part Fill“ oder RFP „Refill - Part Fill“). Die Verordnung wird nicht in den Status EINGELÖST versetzt und es können solange weitere Abgaben dispensiert werden, bis eine Abgabe mit der Markierung RFC „Refill - Complete“ gespeichert wird. Die Kennzeichnung zeigt, dass das Arzneimittel dem Patienten noch nicht ausgehändigt wurde. Die Kennzeichnung zeigt auch, ob alle Packungen einer Verordnung bzw. teilweise Packungen einer Verordnung bestellt werden. Solange eine Abgabe mit der Kennzeichnung „Besorger“ vorhanden ist, muss die Abgabe mit der eMED-ID abrufbar sein.

OTC:

Erfolgt die Abgabe eines OTC auf Basis einer Verordnung, wird die Abgabe immer in e-Medikation gespeichert, auch wenn dieses OTC nicht in der ASP-Liste als wechselwirkungsrelevante Arzneispezialität geführt ist.
Erfolgt die Abgabe eines OTC ohne Verordnungsbezug (siehe Kapitel „Abgabe ohne Verordnungsbezug durchführen“), darf die Abgabe nur in e-Medikation gespeichert werden, wenn dieses OTC in der ASP-Liste als wechselwirkungsrelevante Arzneispezialität geführt ist.

4.4.5.3.2 Ergebnis im Gutfall

Die Verordnung ist eingelöst und die Medikationsabgabe ist gespeichert. Die Verknüpfung von Verordnung und Abgabe ist vorhanden. Teilabgaben im „Besorger“-Prozess sind entsprechend gekennzeichnet.

4.4.5.3.3 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Die in e-Medikation gespeicherte Verordnung wird nicht verändert.

4.4.6 Abgabe ohne Verordnungsbezug durchführen

Der Akteur speichert die tatsächlich abgegeben Arzneimittel in e-Medikation. Dieser Prozess wird durchgeführt:

bei Abgabe von nicht verordneten Arzneimitteln (Abgabe von wechselwirkungsrelevanten OTC)
wenn ein e-Rezept-Eintrag oder ein Papierrezept vorhanden ist und keine Verordnungen in e-Medikation eingetragen wurden
bei der Abgabe eines Arztmusters
bei der Nacherfassung bereits abgegebener Arzneimittel (z. B. wenn eine Speicherung zum Zeitpunkt der Abgabe aus technischen Gründen nicht möglich war oder bei Arzneimittelbezug aus dem Ausland)

4.4.6.1 Vorbedingung

ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
e-Medikation Vorbedingung: keine

4.4.6.2 Akteure

Arzt im niedergelassenen Bereich
Apotheke
Krankenanstalt
Einrichtung der Pflege

4.4.6.3 Ablauf

Der Akteur erfasst die Medikationsabgabe. Die Prüfungen der Arzneimittel z.B. auf Wechselwirkungen, Kontraindikationen, Dosierungen erfolgt in der Eigenverantwortung des Akteurs und ist nicht Gegenstand des Informationssystems „e-Medikation“.

Wenn eine Medikationsabgabe (ohne Rezept/Verordnung) in e-Medikation gespeichert wird, dann gilt die Medikationsabgabe als vom Akteur geprüft. Wenn ein e-Rezept-Eintrag oder ein Papierrezept ohne e-Medikations-Verordnung vorhanden ist, dann obliegt es dem abgebenden Akteur, diese zu prüfen.

Im Rahmen der Nacherfassung bereits erfolgter Abgaben wird als Erfassungsdatum der Zeitpunkt der Nacherfassung gesetzt, während als Abgabedatum das tatsächliche Datum der Abgabe in der Vergangenheit eingetragen wird.

4.4.6.3.1 Ergebnis im Gutfall

Die Medikationsabgabe ist in e-Medikation gespeichert.

4.4.6.3.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden.

Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.

4.4.7 Abgabe abrufen

Im Zuge der Behandlung eines ELGA-Teilnehmers kann der Akteur die Medikationsabgaben eines ELGA-Teilnehmers abrufen.

4.4.7.1 Vorbedingung

ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
e-Medikation Vorbedingung: Abgaben in den letzten 18 Monaten vorhanden

4.4.7.2 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Apotheke
Einrichtung der Pflege

4.4.7.3 Ablauf

Der Akteur fragt die Medikationsabgabe des identifizierten ELGA-Teilnehmers ab. Folgende Filterungen/Suchfunktionen können vorgenommen werden:

eMED-ID
Zeitraum

Es gibt keine Einschränkung bei der Anzeige der Datenfelder (z.B. abgebender GDA darf angezeigt werden). Es werden alle Datenfelder zu einer Abgabe über die Schnittstelle zur Verfügung gestellt. Hinweis: Stornierte Abgaben können nicht abgerufen werden.

4.4.7.3.1 Ergebnis im Gutfall

Im Gutfall werden dem Akteur die angeforderten Medikationsabgaben als auch zugehörige Korrekturmeldungen zurückgeliefert und stehen zur weiteren Verwendung zur Verfügung.

4.4.7.3.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.

4.4.8 Abgabe stornieren

Der Akteur muss die Abgabe stornieren können (z.B. wenn irrtümlich eine Abgabe gespeichert wurde). Das Stornieren der Abgabe ist jederzeit möglich und darf nur vom Ersteller der Abgabe durchgeführt werden.

4.4.8.1 Vorbedingung

ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
e-Medikation Vorbedingung: Abgabe vorhanden, Status ABGEGEBEN

4.4.8.2 Akteure

Arzt im niedergelassenen Bereich
Apotheke
Krankenanstalt
Einrichtung der Pflege

4.4.8.3 Ablauf

Der Akteur wählt die Medikationsabgabe, die storniert werden soll. Die Stornierung von Abgaben ist jederzeit möglich. Die Abgabe erhält den Status STORNIERT und kann nicht mehr abgerufen werden. Handelt es sich bei der Abgabe um eine Medikation mit Verordnungsbezug, bleibt die Verordnung OFFEN, wenn sie weiterhin gültig ist. Ist der Gültigkeitszeitraum des zugrunde liegenden Rezepts jedoch bereits überschritten, erhält sie den Status ABGELAUFEN.

4.4.8.3.1 Ergebnis im Gutfall

Im Gutfall wird die Stornierung der Medikationsabgabe durchgeführt. Die Abgabe erhält den Status STORNIERT, und die zugrunde liegende Verordnung erhält den Status OFFEN oder ABGELAUFEN.

4.4.8.3.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.

4.4.9 Abgabe absetzen

Im Patientengespräch erfährt der Akteur, dass eine erfolgte Medikationsabgabe vom ELGA-Teilnehmer nicht eingenommen wird. In diesem Fall wurde ein Arzneimittel zwar in der Apotheke abgegeben, es wird bzw. wurde aber nicht mehr (z.B. aufgrund von Unverträglichkeiten) eingenommen. Ein Absetzen einer Medikationsabgabe kann von jedem Akteur (außer ELGA-Teilnehmer selbst) durchgeführt werden.

4.4.9.1 Vorbedingung

Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
e-Medikation Vorbedingung: Abgabe vorhanden, Status ABGEGEBEN

4.4.9.2 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Apotheke
Einrichtung der Pflege

4.4.9.3 Ablauf

Eine Abgabe kann mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) abgesetzt werden. Der Akteur bestimmt die abzusetzende Medikationsabgabe durch Übergabe der AbgabeID.

Der Akteur muss das Datum der Absetzung angeben.

Das Datum der Absetzung muss beim Abruf der Medikationsabgaben und bei der Medikationsliste dargestellt werden. Solange eine Medikationsabgabe abgerufen werden kann, kann die Medikationsabgabe auch abgesetzt werden. Im Zuge einer Absetzung erfolgen keine weiteren Prüfungen. Das Absetzen kann via Metadatenupdate der entsprechenden Pharmazeutischen Empfehlung wieder rückgängig gemacht werden.

4.4.9.3.1 Ergebnis im Gutfall

Im Gutfall wird das Absetzen der Medikationsabgabe durchgeführt und in e-Medikation gespeichert (Status ABGESETZT). Das Absetzdatum ist in den Abgabedatenfeldern vorhanden.

4.4.9.3.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Status der Abgabe ist ABGEGEBEN. Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden.

4.4.10 Abgabe ändern

Der Akteur muss die Daten einer Medikationsabgabe ändern können (z.B. bei Einstellungen der Dosierung eines Arzneimittels). Es dürfen nur definierte Datenfelder geändert werden.

4.4.10.1 Vorbedingung

Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
e-Medikation Vorbedingung: Abgabe vorhanden, Status ABGEGEBEN

4.4.10.2 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Apotheke
Einrichtung der Pflege

4.4.10.3 Ablauf

Der Akteur bestimmt die zu ändernde Medikationsabgabe durch Übergabe der AbgabeID. Der Akteur kann nur bestimmte Datenfelder einer Medikationsabgabe ändern, nicht aber das Arzneimittel oder die Menge selbst. Folgende Datenfelder können verändert werden:

Art der Anwendung
Zusatzinformation
Alternative Einnahme
Ergänzende Information
Tagesdosierung
Morgen Dosierung
Mittags Dosierung
Abends Dosierung
Nachts Dosierung
Tagesangabe
Frequenz
Therapieart

Die Medikation (z.B. Handelsname) einer Medikationsabgabe kann NICHT geändert werden. Der GDA der Medikationsabgabe bleibt der gleiche und darf nicht durch die Änderung verändert werden.

4.4.10.3.1 Ergebnis im Gutfall

Im Gutfall wird die Änderung der Medikationsabgabe durchgeführt und in e-Medikation gespeichert.

4.4.10.3.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.

4.4.11 Medikationsliste abrufen

Im Zuge der Behandlung eines ELGA-Teilnehmers möchte der Akteur die Medikationsliste des ELGA-Teilnehmers abrufen. Die Medikationsliste fasst offene Verordnungen und Abgaben zusammen.

4.4.11.1 Vorbedingung

Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
e-Medikation Vorbedingung: keine

4.4.11.2 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Apotheke
Einrichtung der Pflege
ELGA-Teilnehmer

4.4.11.3 Ablauf

Der Akteur kann die gesamte, konsolidierte Medikationsliste (sortierbare Zusammenfassung über Zulassungsnummer und Abgabe bzw. Verordnungsdatum) abrufen. Die Medikationsliste wird bei Aufruf serverseitig erstellt und enthält die aktuell gültigen Abgaben bzw. Verordnungen (z.B. bei einer Änderung wird nur die geänderte Dosierung angezeigt).

4.4.11.3.1 Ergebnis im Gutfall

Im Gutfall wird dem Akteur die angeforderte Medikationsliste zurückgeliefert und steht zur weiteren Verwendung zur Verfügung. Sind keine relevanten Verordnungen und Abgaben vorhanden, so wird eine „leere Liste“ retourniert.

4.4.11.3.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.

4.4.11.4 Alternativer Ablauf

Bei der Ermittlung der aktuellen Medikation eines Patienten ist die Verwendung der konsolidierten Medikationsliste optional. Alternativ können die verfügbaren (Quell-)Daten Rezept (Prescription), Abgabe (Dispense) und die entsprechenden Korrekturmeldungen bzw. Pharmazeutische Empfehlungen (Pharmaceutical Advice) separat entsprechend dem im IHE Pharmacy Profil definierten Abfragen („Queries“) abgerufen und in der lokalen Software weiterverarbeitet werden. Dies hat den Vorteil, dass die Änderungen der Medikationsliste nachvollziehbar sind.

5 Konformitätsprüfung

Ein zu diesem Implementierungsleitfaden konformes CDA-Dokument ist zunächst ein valides CDA Release 2.0 XML-Dokument mit Header und Body. Darüber hinaus erfüllt es alle in diesem Leitfaden festgelegten "Geschäftsregeln".

Dies spiegelt ein generelles Konzept im Umgang mit Dokumenten wieder: die Validierung in zwei Schritten. Im ersten Schritt stellt dies die Validierung gegen zugehörige W3C Schemas dar. Das verwendete Schema ist das geringfügig erweiterte offizielle CDA Release 2.0 Schema (siehe Schema-Prüfung). Darüber hinaus existieren eine Reihe von Schematron Regeln, die für einen zweiten Validierungsschritt genutzt werden und letztlich die Detailregelungen in diesem Leitfaden wiedergeben, sowie die Einhaltung der Geschäftsregeln (Optionalität, Kardinalität/Multiplizität, Datentypen, Wertebereiche, Abhängigkeiten) sicherstellen (siehe Schematron-Prüfung). Geschäftsregeln für Abschnitte oder Elemente werden auch technisch zu "Templates" zusammengefasst. Eine XML-Instanz, die kein valides CDA-Dokument ist oder sich nicht gegen das XSD-Schema validieren lässt oder im Widerspruch zu den angegebenen Geschäftsregeln steht, ist kein gültiges CDA-Dokument im Sinne dieses Implementierungsleitfadens.

Hinweis: Nicht alle Geschäftsregeln können mit Schema oder Schematron geprüft werden (etwa Inhalte von Multimedia-Attachments, Dokumentengröße). Zusätzliche Validierungsschritte sind gegebenenfalls notwendig, um alle Regeln zu überprüfen zu können.

Die Kapitel zu den technischen Konformitätsprüfungen von CDA-Dokumenten, gemäß diesem Dokumentleitfaden mittels Schema und Schematron, sind im allgemeinen Leitfaden unter den folgenden Links zu finden:

6 Datentypen

Im Kapitel Datentypen im allgemeinen Leitfaden werden nur die Datentypen beschrieben, die in ELGA CDA-Dokumenten wie diesem zur Anwendung kommen. Für weiterführende Informationen wird auf den zugrundeliegenden Standard Health Level Seven Version 3 (V3), Normative Edition verwiesen.

7 Technische Spezifikation

Die Struktur des CDA Austauschformats ist in den nachfolgenden Kapiteln im Detail beschrieben.

Der Header entspricht im Wesentlichen den Vorgaben im allgemeinen Leitfaden. Der Body enthält die tatsächlichen (medizinischen) Inhalte des Dokuments. Dieses Dokument existiert ausschließlich in einer voll strukturierten Form, eine Unterscheidung der Interoperabilitätsstufen ist daher nicht notwendig.

7.1 Übersichtstabelle der CDA Strukturen des Headers

Dieses Kapitel gibt einen Überblick über die Elemente des CDA Headers und den Vorgaben bezüglich Kardinalität und Konformität.

Die jeweiligen Links in der letzten Spalte zeigen auf die einzelnen Header Elemente im allgemeinen Leitfaden.

Element	Kard/Konf ELGA	Bedeutung / Link zum Kapitel
realmCode	1..1 M	Hoheitsbereich des Dokuments
typeId	1..1 M	Kennzeichnung CDA R2
templateId	4..4 M	Kennzeichnung von Strukturvorschriften
id	1..1 M	Dokumenten-Id
code translation	1..1 M 1..1 M	Klassifikation des Dokuments (fein und grob)
title	1..1 M	Titel des Dokuments
sdtc:statusCode	0..0 NP	Status des Dokuments (immer completed, deswegen verboten)
hl7at:terminologyDate	1..1 M	Terminologie-Datum des Dokuments
hl7at:formatCode	1..1 M	FormatCode des Dokuments
hl7at:practiceSettingCode	0..0 NP	Fachliche Zuordnung des Dokuments (keinen Mehrwert für die e-Medikation)
effectiveTime	1..1 M	Erstellungsdatum des Dokuments (Bei Medikationsliste die Zeitspanne vom ersten bis letztem Eintrag, sonst Erstellungszeitpunkt)
confidentialityCode	1..1 M	Vertraulichkeitscode
languageCode	1..1 M	Sprachcode des Dokuments
setId versionNumber	1..1 M 1..1 M	Versionierung des Dokuments
recordTarget v2	1..1 M	Record Target v2
author v2 / author v2 Prescriber (nur bei Rezept)	1..1 M	Author v2 / Author v2 beim Rezept
custodian v2	1..1 M	Custodian v2
legalAuthenticator v2	1..* M	Legal Authenticator v2
documentationOf serviceEvent	1..* M 1..1 M	Gesundheitsdienstleistungen
relatedDocument[@typeCode="XFRM"]	1..1 M	siehe direkt im Rezept Dokument
relatedDocument[@typeCode="RPLC"]	0..1 R	Bezug zu vorgehenden Dokumenten

^{[Tabelle 1]}:Übersichtstabelle der CDA Strukturen des Headers

7.2 Übersichtstabelle der e-Medikation CDA Strukturen

Dieses Kapitel gibt einen Überblick über die Body-Elemente der vier Dokumententypen und deren Vorgaben bezüglich Kardinalität und Konformität.

Element	Kard/Konf	Link zum Kapitel
Rezept		Rezept Dokument
Rezept - kodiert	1..1 M	Rezept Sektion
Verordnung	1..* M	Verordnungs Entry
Abgabe		Abgabe Dokument
Abgabe - kodiert	1..1 M	Abgabe Sektion
Abgabe	1..* M	Abgabe Entry
Pharmazeutische Empfehlung		Pharmazeutische Empfehlung Dokument
Pharmazeutische Empfehlung - kodiert	1..1 M	Pharmazeutische Empfehlung Sektion
Pharmazeutische Empfehlung	1..* M	Pharmazeutische Empfehlung Entry
Medikationsliste		Medikationsliste Dokument
Medikationsliste - kodiert	1..1 M	Medikationsliste Sektion
Verordnung	0..* M	Verordnungs Entry
Abgabe	0..* M	Abgabe Entry
Pharmazeutische Empfehlung	0..* M	Pharmazeutische Empfehlung Entry

^{[Tabelle 2]}:Übersichtstabelle der e-Medikation CDA Strukturen

7.3 CDA Templates

7.3.1 Document Level Templates

7.3.1.1 Rezept

Id

1.2.40.0.34.6.0.11.0.20

Gültigkeit ab

2024‑06‑10 15:39:41

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atemed_document_rezept

Bezeichnung

Rezept

Beschreibung

In diesem Dokument ist ein ärztliches Rezept mit seinen einzelnen Verordnungen aufgeführt. Diese Informationen stehen ebenfalls in maschinenlesbarer Form zur Verfügung. Ein Rezept ist eine schriftliche Anweisung einer Ärztin oder eines Arztes an die Apotheke, bestimmte Arzneimittel oder andere apothekenpflichtige Produkte für einen Patienten bereitzustellen. Jede Verordnung auf dem Rezept enthält Angaben zum verordneten Medikament, zur Dosierung, zur Darreichungsform, zur Anwendungsdauer, Packungsgröße wie auch weiteren Details.

Kontext

Pfadname /

Klassifikation

CDA Document Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 14 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.1.10	Inklusion	Document Realm (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.1.30	Inklusion	Document TypeId (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.1	Inklusion	Document Id (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.46	Inklusion	Document TerminologyDate (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.11	Inklusion	Document Effective Time (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.1.12	Inklusion	Document Confidentiality Code (1.0.2+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.1.13	Inklusion	Document Language (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.15	Inklusion	Document Set Id and Version Number (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.3.2	Inklusion	Record Target v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.2.2.1	Inklusion	Author v2 Prescriber (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.4.2	Inklusion	Custodian v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.5.2	Inklusion	Legal Authenticator v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.14	Inklusion	Document Replacement - Related Document (1.0.1+20210628)	DYNAMIC
1.2.40.0.34.6.0.11.2.137	Containment	Rezept - kodiert (3.0.0+20250228)	DYNAMIC

Beispiel

<cda:ClinicalDocument>
  
  
  
  <cda:realmCode code="AT"/>  
  <cda:typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>  
  
  <cda:templateId root="1.2.40.0.34.6.0.11.0.1"/>  
  <cda:templateId root="1.2.40.0.34.7.8.9.3"/>  
  <cda:templateId root="1.2.40.0.34.6.0.11.0.20"/>  
  <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.1.1"/>  
  <cda:id root="1.2.40.0.34.99.4613.3.1" extension="123456.1" assigningAuthorityName="Amadeus Spital"/>  
  <cda:code codeSystemName="LOINC" code="57833-6" codeSystem="2.16.840.1.113883.6.1" displayName="Prescription for medication">
    
    <cda:translation codeSystemName="LOINC" code="52471-0" codeSystem="2.16.840.1.113883.6.1" displayName="Medications"/>  </cda:code>  
  <cda:title>Rezept</cda:title>  
  <hl7at:terminologyDate value="20250610"/>  
  <cda:formatCode code="urn:hl7-at:emedat:3.0.0+20250615" codeSystem="1.2.40.0.34.5.37" displayName="HL7 Austria e-Medikation 3.0.0+20250615"/>  
  <cda:effectiveTime value="20250615063500+0200"/>  
  <cda:confidentialityCode code="N" displayName="normal" codeSystem="2.16.840.1.113883.5.25" codeSystemName="HL7:Confidentiality"/>  
  <cda:languageCode code="de-AT"/>  
  <cda:setId root="1.2.40.0.34.99.4613.3.1" extension="123456" assigningAuthorityName="Amadeus Spital"/>  <cda:versionNumber value="1"/>  
  <cda:recordTarget>
    <cda:patientRole>
      
      <cda:id root="1.2.40.0.34.99.4613.3.2" extension="121212" assigningAuthorityName="Amadeus Spital"/>      
      <cda:id root="1.2.40.0.10.1.4.3.1" extension="1111241261" assigningAuthorityName="Österreichische Sozialversicherung"/>      
      <cda:addr use="HP">
        <cda:streetAddressLine>Musterstraße 13a</cda:streetAddressLine>        <cda:postalCode>7000</cda:postalCode>        <cda:city>Eisenstadt</cda:city>        <cda:state>Burgenland</cda:state>        <cda:country>AT</cda:country>      </cda:addr>      
      <cda:telecom use="H" value="tel:+43.2682.40400"/>      <cda:telecom use="MC" value="tel:+43.664.1234567"/>      <cda:telecom value="mailto:musterfrau@provider.at"/>      <cda:patient>
        
        <cda:name>
          <cda:prefix qualifier="AC">Dr.</cda:prefix>          <cda:given>Maria</cda:given>          <cda:given>Johanna</cda:given>          <cda:family>Musterfrau</cda:family>          <cda:family qualifier="BR">VorDerHeirat</cda:family>          <cda:suffix qualifier="AC">BSc</cda:suffix>        </cda:name>        
        <cda:administrativeGenderCode code="F" displayName="Female" codeSystem="2.16.840.1.113883.5.1" codeSystemName="HL7:AdministrativeGender"/>        
        <cda:birthTime value="19611224"/>        
        <cda:maritalStatusCode code="M" displayName="Married" codeSystem="2.16.840.1.113883.5.2" codeSystemName="HL7:MaritalStatus"/>        
        <cda:religiousAffiliationCode code="101" codeSystem="2.16.840.1.113883.2.16.1.4.1" codeSystemName="HL7.AT:ReligionAustria" displayName="Römisch-Katholisch"/>        
        <cda:birthplace>
          <cda:place>
            <cda:addr>
              <cda:streetAddressLine>Musterstraße 23b</cda:streetAddressLine>              <cda:postalCode>8011</cda:postalCode>              <cda:city>Graz</cda:city>              <cda:state>Steiermark</cda:state>              <cda:country>AT</cda:country>            </cda:addr>          </cda:place>        </cda:birthplace>        
        <cda:languageCommunication>
          <cda:languageCode code="de-AT"/>          <cda:modeCode code="ESP" displayName="Expressed spoken" codeSystem="2.16.840.1.113883.5.60" codeSystemName="HL7:LanguageAbilityMode"/>          <cda:proficiencyLevelCode code="E" displayName="Excellent" codeSystem="2.16.840.1.113883.5.61" codeSystemName="HL7:LanguageAbilityProficiency"/>          <cda:preferenceInd value="false"/>        </cda:languageCommunication>        <cda:languageCommunication>
          <cda:languageCode code="en"/>          <cda:modeCode code="ESP" displayName="Expressed spoken" codeSystem="2.16.840.1.113883.5.60" codeSystemName="HL7:LanguageAbilityMode"/>          <cda:proficiencyLevelCode code="F" displayName="Fair" codeSystem="2.16.840.1.113883.5.61" codeSystemName="HL7:LanguageAbilityProficiency"/>          <cda:preferenceInd value="false"/>        </cda:languageCommunication>      </cda:patient>    </cda:patientRole>  </cda:recordTarget>  
  <cda:author>
    
    <cda:functionCode code="2211" codeSystem="2.16.840.1.113883.2.9.6.2.7" codeSystemName="ISCO-08" displayName="Generalist medical practitioners"/>    
    <cda:time value="20250615130100+0200"/>    <cda:assignedAuthor>
      
      <cda:id root="1.2.40.0.34.99.4613.3.3" extension="1111" assigningAuthorityName="Amadeus Spital"/>      
      <cda:code code="116" codeSystem="1.2.40.0.34.5.160" codeSystemName="ELGA_Fachaerzte" displayName="Fachärztin/Facharzt für Innere Medizin">
        
        <cda:addr>
          <cda:streetName>Währinger Gürtel</cda:streetName>          <cda:houseNumber>18-20</cda:houseNumber>          <cda:postalCode>1090</cda:postalCode>          <cda:city>Wien</cda:city>          <cda:state>Wien</cda:state>          <cda:country>AT</cda:country>        </cda:addr>        
        <cda:telecom use="WP" value="tel:+43.1.3453446.1111"/>        
        <cda:assignedPerson>
          <cda:name>
            <cda:prefix>Dr.</cda:prefix>            <cda:family>Dominik</cda:family>            <cda:given>Matic</cda:given>          </cda:name>        </cda:assignedPerson>        
        <cda:representedOrganization>
          
          <cda:id root="1.2.40.0.34.99.4613" assigningAuthorityName="GDA Index"/>          
          <cda:name>Amadeus Spital</cda:name>          
          <cda:telecom value="tel:+43.1.3453446.0"/>          <cda:telecom value="fax:+43.1.3453446.4589"/>          <cda:telecom value="mailto:info@amadeusspital.at"/>          <cda:telecom value="http://www.amadeusspital.at"/>          
          <cda:addr>
            <cda:streetName>Währinger Gürtel</cda:streetName>            <cda:houseNumber>18-20</cda:houseNumber>            <cda:postalCode>1090</cda:postalCode>            <cda:city>Wien</cda:city>            <cda:state>Wien</cda:state>            <cda:country>AT</cda:country>          </cda:addr>        </cda:representedOrganization>      </cda:code>    </cda:assignedAuthor>  </cda:author>  
  <cda:custodian>
    <cda:assignedCustodian>
      <cda:representedCustodianOrganization>
        
        <cda:id root="1.2.40.0.34.99.4613" assigningAuthorityName="GDA Index"/>        
        <cda:name>Amadeus Spital</cda:name>        
        <cda:telecom value="tel:+43.1.3453446.0"/>        
        <cda:addr>
          <cda:streetName>Währinger Gürtel</cda:streetName>          <cda:houseNumber>18-20</cda:houseNumber>          <cda:postalCode>1090</cda:postalCode>          <cda:city>Wien</cda:city>          <cda:state>Wien</cda:state>          <cda:country>AT</cda:country>        </cda:addr>      </cda:representedCustodianOrganization>    </cda:assignedCustodian>  </cda:custodian>  
  <cda:legalAuthenticator>
    
    <cda:time value="20250615135400+0200"/>    
    <cda:signatureCode code="S"/>    
    <cda:assignedEntity>
      
      <cda:id root="1.2.40.0.34.99.4613.3.3" extension="2222" assigningAuthorityName="Amadeus Spital"/>      
      <cda:addr>
        <cda:streetName>Währinger Gürtel</cda:streetName>        <cda:houseNumber>18-20</cda:houseNumber>        <cda:postalCode>1090</cda:postalCode>        <cda:city>Wien</cda:city>        <cda:state>Wien</cda:state>        <cda:country>AT</cda:country>      </cda:addr>      
      <cda:telecom use="WP" value="tel:+43.1.3453446.2222"/>      
      <cda:assignedPerson>
        
        <cda:name>
          <cda:prefix>Univ.-Prof.Dr.</cda:prefix>          <cda:family>Dom</cda:family>          <cda:given>Turio</cda:given>        </cda:name>      </cda:assignedPerson>      
      <cda:representedOrganization>
        
        <cda:id root="1.2.40.0.34.99.4613" assigningAuthorityName="GDA Index"/>        
        <cda:name>Amadeus Spital</cda:name>        
        <cda:telecom value="tel:+43.1.3453446.0"/>        <cda:telecom value="fax:+43.1.3453446.4589"/>        <cda:telecom value="mailto:info@amadeusspital.at"/>        <cda:telecom value="http://www.amadeusspital.at"/>        
        <cda:addr>
          <cda:streetName>Währinger Gürtel</cda:streetName>          <cda:houseNumber>18-20</cda:houseNumber>          <cda:postalCode>1090</cda:postalCode>          <cda:city>Wien</cda:city>          <cda:state>Wien</cda:state>          <cda:country>AT</cda:country>        </cda:addr>      </cda:representedOrganization>    </cda:assignedEntity>  </cda:legalAuthenticator>  
  <cda:documentationOf>
    <cda:serviceEvent>
      <cda:code code="KASSEN" codeSystemName="MedikationRezeptart" codeSystem="1.2.40.0.10.1.4.3.4.3.3" displayName="Kassenrezept">
        
        <cda:effectiveTime>
          
          <cda:low value="20250615135400+0200"/>          
          <cda:high value="20250630135400+0200"/>        </cda:effectiveTime>      </cda:code>    </cda:serviceEvent>  </cda:documentationOf>  <cda:component>
    <cda:structuredBody>
      <cda:component>
        <cda:section>
          <cda:templateId root="1.2.40.0.34.6.0.11.2.137"/>          <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.2.1"/>          <cda:id root="1.2.3.999" extension="extension" assigningAuthorityName="assigningAuthorityName"/>          <cda:code code="57828-6" codeSystem="2.16.840.1.113883.6.1" displayName="Prescription list">
            <cda:title>title</cda:title>            <cda:text/>            <cda:entry typeCode="COMP">
              <cda:substanceAdministration classCode="SBADM" moodCode="INT">
                <cda:templateId root="1.2.40.0.34.6.0.11.3.185"/>                <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.3.2"/>                <cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>                <cda:templateId root="2.16.840.1.113883.10.20.1.24"/>                <cda:templateId root="1.3.6.1.4.1.19376.1.9.1.3.6"/>                
                <cda:id root="1.2.3.999" extension="extension"/>                <cda:id root="1.2.3.999" extension="extension"/>                <cda:text>
                  <cda:reference value="--TODO--"/>                </cda:text>                <cda:statusCode code="completed"/>                
                
                <cda:repeatNumber/>                <routeCode/>                
                <cda:consumable typeCode="CSM">
                  <cda:manufacturedProduct classCode="MANU">
                    <cda:templateId root="1.2.40.0.34.6.0.11.3.186"/>                    <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.3.29"/>                    <cda:manufacturedMaterial classCode="MMAT" determinerCode="KIND">
                      <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.3.30"/>                      <cda:code nullFlavor="NA" code="--code--" codeSystem="1.2.40.0.34.4.16">
                        
                        <cda:translation code="--code--" codeSystem="1.2.40.0.34.4.17"/>                      </cda:code>                      <cda:name nullFlavor="NA">name</cda:name>                      <formCode nullFlavor="NI"/>                      <cda:asContent classCode="CONT">
                        <cda:quantity unit="%" value="1">
                          <cda:translation>
                            
                          </cda:translation>                        </cda:quantity>                        <cda:containerPackagedProduct classCode="CONT" determinerCode="KIND">
                          <formCode nullFlavor="NI"/>                        </cda:containerPackagedProduct>                      </cda:asContent>                      <cda:ingredient classCode="ACTI">
                        <cda:ingredientSubstance classCode="MMAT" determinerCode="KIND">
                          <cda:code>
                            
                            <cda:translation/>                          </cda:code>                          <cda:name>name</cda:name>                        </cda:ingredientSubstance>                      </cda:ingredient>                    </cda:manufacturedMaterial>                  </cda:manufacturedProduct>                </cda:consumable>                
                
                
                <cda:entryRelationship typeCode="COMP">
                  <cda:supply classCode="SPLY" moodCode="RQO">
                    <cda:independentInd value="false"/>                    <cda:quantity value="1" unit="1"/>                  </cda:supply>                </cda:entryRelationship>                <cda:entryRelationship typeCode="SUBJ" inversionInd="true">
                  
                </cda:entryRelationship>                <cda:entryRelationship typeCode="SUBJ" inversionInd="true">
                  
                </cda:entryRelationship>                
                <cda:entryRelationship typeCode="SUBJ" inversionInd="true">
                  
                </cda:entryRelationship>                
              </cda:substanceAdministration>            </cda:entry>          </cda:code>        </cda:section>      </cda:component>    </cda:structuredBody>  </cda:component></cda:ClinicalDocument>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:ClinicalDocument

Rezept Dokument

@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)

hl7:realmCode

CS

1 … 1

M

Hoheitsbereich des Dokuments.

Fester Wert: @code = AT

(aus Value Set „ELGA_RealmCode“)

@code

1 … 1

F

AT

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.30 Document TypeId (DYNAMIC)

hl7:typeId

II

1 … 1

M

Dokumentformat CDA R2

@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

Fixe OID für alle Dokumente, die in der Governance-Gruppe "eHealth Austria" abgestimmt werden und von einem zentralen Art-Decor-Repository abgeleitet werden (AT-CDA-BBR).

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.0.1

hl7:templateId

II

1 … 1

M

Root-OID des Implementierungsleitfadens (Dokument-OID). Dient als informative Referenz.

@root

uid

1 … 1

F

1.2.40.0.34.7.8.9.3

hl7:templateId

II

1 … 1

M

Template Spezieller Implementierungsleitfaden ELGA eMedikation v3 Rezept

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.0.20

hl7:templateId

II

1 … 1

M

eHDSI ePrescription

@root

uid

1 … 1

F

1.3.6.1.4.1.12559.11.10.1.3.1.1.1

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.1 Document Id (DYNAMIC)

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.

@root

uid

1 … 1

R

hl7:code

CE

1 … 1

M

Für das e-Medikations Rezept ist als Dokumententyp (/ClinicalDocument/code) "57833-6 - Prescription for medication" und als Dokumentenklasse (/ClinicalDocument/code/translation) "52471-0 - Medications" anzugeben.

↔ Hinweis zum XDS-Mapping:

Das code-Element wird in das XDS-Metadaten-Attribut XDSDocumentEntry.typeCode übernommen.
Das translation-Element wird in das XDS-Metadaten-Attribut XDSDocumentEntry.classCode übernommen.

@codeSystemName

st

0 … 1

F

LOINC

@code

CONF

1 … 1

F

57833-6

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

Prescription for medication

hl7:translation

CD

1 … 1

M

Fixe Dokumentenklasse "52471-0 - Medications"

@codeSystemName

st

0 … 1

F

LOINC

@code

CONF

1 … 1

F

52471-0

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

Medications

hl7:title

ST

1 … 1

M

Der Titel des Dokuments muss mit "Rezept" oder "Recipe" beginnen und ist für den lesenden Dokumentempfänger das sichtbare Element. Dieser wird nicht dem Attribut displayName des Elements code entnommen, sondern dem (verpflichtenden) Element title.

sdtc:statusCode

CS

NP

e-Medikations Dokumente sind immer abgeschlossene bzw. "fertige" Dokumente - in diesem Fall erübrigt sich die Angabe eines Status.

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.46 Document TerminologyDate (DYNAMIC)

hl7at:terminologyDate

TS.DATE.FULL

1 … 1

M

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.

Constraint

Das Datum der letzten Terminologie-Aktualisierung MUSS entsprechend klassischer HL7 V3 Notation im Format "YYYYMMDD" angegeben werden.
Beispiel: 20200527

hl7at:formatCode

CD

1 … 1

M

↔ Hinweis zum XDS-Mapping: @code wird in das XDS-Attribut XDSDocumentEntry.formatCode übernommen.

@code

CONF

1 … 1

F

urn:hl7-at:emedat:3.0.0+20250615

@codeSystem

1 … 1

F

1.2.40.0.34.5.37

@displayName

1 … 1

F

HL7 Austria e-Medikation 3.0.0+20250615

hl7at:practiceSettingCode

CD

NP

e-Medikations Dokumente werden keinem Fach zugewiesen - in diesem Fall erübrigt sich die Angabe eines practiceSettingCodes.

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.


	at-cda-bbr-dataelement-11	Erstellungsdatum	Dataset A Allgemeiner Leitfaden

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 Value Set „ELGA_Confidentiality“.


	at-cda-bbr-dataelement-13	Vertraulichkeitscode	Dataset A Allgemeiner Leitfaden

@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:languageCode

CS.LANG

1 … 1

M

Sprachcode des Dokuments.


	at-cda-bbr-dataelement-14	Sprachcode	Dataset A Allgemeiner Leitfaden

@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 ELGA_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.

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.

@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.3.2 Record Target v2 (DYNAMIC)

hl7:recordTarget

1 … 1

M

Komponente für die Patientendaten.


	at-cda-bbr-dataelement-64	Patient	Dataset A Allgemeiner Leitfaden

@typeCode

cs

0 … 1

F

RCT

@contextControlCode

cs

0 … 1

F

OP

hl7:patientRole

1 … 1

M

Patientendaten

@classCode

cs

0 … 1

F

PAT

hl7:id

II

2 … *

R

Patientenidentifikatoren


at-cda-bbr-dataelement-193	EKVK	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-65	LokaleID	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-66	SVNr	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-67	bPK-GH	Dataset A Allgemeiner Leitfaden

Constraint

Hinweis: Die Reihenfolge der id-Elemente MUSS unbedingt eingehalten werden!

* id[1] Identifikation des Patienten im lokalen System (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[@root="1.2.40.0.10.2.1.1.149"] Bereichsspezifisches Personenkennzeichen (0..1 O):
- @root : OID der österreichischen bPK, fester Wert: 1.2.40.0.10.2.1.1.149 (1..1 M)
- @extension : bPK des Patienten: concat(Bereichskürzel, ":", bPK) (Base64,28 Zeichen). Typischerweise bPK-GH (Gesundheit). Kann im Zusammenhang mit E-ID auch andere Bereichskürzel tragen.
Anmerkung : Das bPK dient ausschließlich technisch der Zuordnung der elektronischen Identität und darf daher weder angezeigt werden noch am Ausdruck erscheinen noch in allfälligen Downloads enthalten sein (1..1 M)
- @assigningAuthorityName : Fester Wert: Österreichische Stammzahlenregisterbehörde (0..1 O)

* id[@root="1.2.40.0.34.4.21"] Europäische Krankenversicherungskarte kurz (0..1 O):

- @root: OID der EKVK, fester Wert: 1.2.40.0.34.4.21 (1..1 M)

- @extension: Datenfeld 6 der EKVK

- @assigningAuthorityName : Fester Wert: Nationaler Krankenversicherungsträger (0..1 O)

* id[@root="1.2.40.0.10.1.4.3.8"] Europäische Krankenversicherungskarte lang (0..1 O):
- @root: OID der EKVK, fester Wert: 1.2.40.0.10.1.4.3.8 (1..1 M)

- @extension: Datenfelder der EKVK nach folgender Bildungsvorschrift: concat(Feld 6,"^",Feld 7,"^",Feld 8,"^",Feld 9) wobei Feld 6 "Persönliche Kennnummer" angegeben sein MUSS (1..1 M). Die übrigen Datenfelder sind optional (0..1 O). In Feld 9 MUSS die Datumsangabe im Format YYYMMDD erfolgen.

- @assigningAuthorityName : Fester Wert: Nationaler Krankenversicherungsträger (0..1 O)

Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen.

Beispiel

Europäische Krankenversicherungskarte kurz

Beispiel

Europäische Krankenversicherungskarte lang

hl7:addr

1 … *

R

Adresse des Patienten.

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „NI“ und es dürfen keine Adressteile vorhanden sein.
Es MUSS eine mögliche Adresse unterstützt werden. Spezielle Leitfäden (z.B. Entlassungsbrief Pflege) können es erforderlich machen, dass mehr als eine Adresse unterstützt werden muss.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)


	at-cda-bbr-dataelement-68	Adresse	Dataset A Allgemeiner Leitfaden

@nullFlavor

cs

0 … 1

F

NI

Constraint

Werden mehrere gleichartige address-Elemente strukturiert (z.B. Home, Pflege), MUSS jeweils das Attribut @use angeführt sein.

hl7:telecom

TEL.AT

1 … *

R

Kontakt-Element. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „NI“ und die Attribute „value“ und „use“ wie auch alle inneren Elemente entfallen.


	at-cda-bbr-dataelement-72	Kontaktdaten	Dataset A Allgemeiner Leitfaden

@nullFlavor

cs

0 … 1

F

NI

@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 gleichartige 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.


	at-cda-bbr-dataelement-70	Name	Dataset A Allgemeiner Leitfaden

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Namen-Element (Person)

@use

cs

0 … 1

Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.

Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“.

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

hl7:prefix

ENXP

0 … *

Beliebig viele Präfixe zum Namen, z.B. Akademische Titel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!

@qualifier

cs

0 … 1

Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:family

ENXP

1 … *

M

Mindestens ein Hauptname (Nachname).

@qualifier

cs

0 … 1

Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:given

ENXP

1 … *

M

Mindestens ein Vorname

@qualifier

cs

0 … 1

Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:suffix

ENXP

0 … *

Beliebig viele Suffixe zum Namen

@qualifier

cs

0 … 1

Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

Auswahl

1 … 1

Das "administrative Geschlecht" ist das soziale oder gesellschaftliche Geschlecht ("Gender"). Das administrative Geschlecht ist daher grundsätzlich getrennt von den biologischen Merkmalen der Person zu sehen. Grundsätzlich soll das administrative Geschlecht dem im Zentralen Melderegister (ZMR) eingetragenen Geschlecht entsprechen.

Über ein Translation-Element können weitere Angaben zum Geschlecht gemacht werden, wenn diese abweichend vom administrativen Geschlecht sind, z.B.:

Biologisches Geschlecht
Geschlecht in der Sozialversicherung
Geschlecht für die Stations-/Bettenbelegung im Krankenhaus

Codierung des Geschlechts des Patienten aus ValueSet "ELGA_AdministrativeGender".

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „UNK“ und alle Attribute wie auch alle inneren Elemente entfallen.

Elemente in der Auswahl:

hl7:administrativeGenderCode[not(@nullFlavor)]
hl7:administrativeGenderCode[@nullFlavor='UNK']

hl7:administrativeGenderCode

CE

0 … 1

wo [not(@nullFlavor)]


	at-cda-bbr-dataelement-74	Geschlecht	Dataset A Allgemeiner Leitfaden

@displayName

st

1 … 1

R

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

R

@codeSystemName

st

0 … 1

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC)

hl7:translation

CD

0 … *

R

Über ein Translation-Element können weitere Angaben zum Geschlecht gemacht werden, wenn diese abweichend vom administrativen Geschlecht sind, z.B.: Biologisches Geschlecht, Geschlecht in der Sozialversicherung, Geschlecht für die Stations-/Bettenbelegung im Krankenhaus

@displayName

st

1 … 1

R

Beispiel

Beispiel für eine SNOMED CT Angabe

hl7:administrativeGenderCode

CE

0 … 1

Mittels nullFlavor="UNK" wird "Unbekannt" abgebildet. Dies schließt die Ausprägung "Keine Angabe" mit ein.

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:birthTime

TS.AT.VAR

1 … 1

M

Geburtsdatum des Patienten. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. Das Geburtsdatum des Patienten kann ein Teildatum sein, z. B. nur die Jahreszahl.


	at-cda-bbr-dataelement-75	Geburtsdatum	Dataset A Allgemeiner Leitfaden

sdtc:deceasedInd

BL

0 … 1

R

Kennzeichen, dass die Person verstorben ist. Kann alternativ zum Todesdatum angegeben werden, v.a. wenn der Todeszeitpunkt nicht bekannt ist.


	at-cda-bbr-dataelement-192	Verstorben-Kennzeichen	Dataset A Allgemeiner Leitfaden

sdtc:deceasedTime

TS.AT.TZ

0 … 1

R

Todesdatum der Person.


	at-cda-bbr-dataelement-191	Todesdatum	Dataset A Allgemeiner Leitfaden

hl7:maritalStatusCode

CE

0 … 1

R

Codierung des Familienstands des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“


	at-cda-bbr-dataelement-98	Familienstand	Dataset A Allgemeiner Leitfaden

@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:religiousAffiliationCode

CE

0 … 1

R

Codierung des Religionsbekenntnisses des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“


	at-cda-bbr-dataelement-99	Religionsbekenntnis	Dataset A Allgemeiner Leitfaden

@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!

hl7:ethnicGroupCode

NP

Ethnische Zugehörigkeit des Patienten.

Darf nicht verwendet werden!

hl7:guardian

0 … *

R

Gesetzlicher Vertreter:

Vorsorgebevollmächtigte/r (Bevollmächtigte/r durch Vorsorgevollmacht)
Gewählte/r ErwachsenenvertreterIn
Gesetzliche/r ErwachsenenvertreterIn
Gerichtliche/r ErwachsenenvertreterIn (Sachwalter)

Der gesetzliche Vetreter kann entweder eine Person (guardianPerson) oder eine Organisation (guardianOrganization) sein.

Beim Patienten können optional ein oder mehrere gesetzliche Vetreter angegeben werden. Wenn ein gesetzliche Vetreter bekannt ist, SOLL diese Information auch angegeben werden.


	at-cda-bbr-dataelement-88	Gesetzlicher Vertreter	Dataset A Allgemeiner Leitfaden

@classCode

cs

1 … 1

F

GUARD

@nullFlavor

cs

0 … 1

Verwenden Sie einen nullFlavor, wenn aus bestimmten Gründen keine Informationen vorliegen.

hl7:templateId

II

1 … 1

M

Template id für IHE PCC Patient Contacts.

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.2.4

hl7:code

CE

0 … 1

R

Die Beziehung zwischen dem Patienten und dem gesetzlicher Vertreter kann im Code-Element erfasst werden.

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.38 eHDSIPersonalRelationship (DYNAMIC)

hl7:addr

1 … 1

R

Die Adresse des gesetzlichen Vertreters oder der Organisation ist verpflichtend.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Adressteile vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens einer der nachstehend aufgeführten Adressteile vorhanden sein

Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

@nullFlavor

cs

0 … 1

F

NI

hl7:telecom

TEL.AT

1 … *

R

Beliebig viele Kontaktdaten des gesetzlichen Vertreters als Person oder Organisation.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Kontaktdaten vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens einer der nachstehend aufgeführten Kontaktdaten vorhanden sein

Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.

@nullFlavor

cs

0 … 1

F

NI

@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 gleichartige 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:guardianPerson welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
hl7:guardianPerson welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
hl7:guardianOrganization welches enthält Template 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)

hl7:guardianPerson

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)

hl7:guardianPerson

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)

hl7:guardianOrganization

0 … 1

R

Name des gesetzlichen Vertreters (Organisation)
Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)

hl7:birthplace

0 … 1

R

Geburtsort des Patienten.


	at-cda-bbr-dataelement-76	Geburtsort	Dataset A Allgemeiner Leitfaden

@classCode

cs

0 … 1

F

BIRTHPL

hl7:place

1 … 1

M

Ort

@classCode

cs

0 … 1

F

PLC

@determinerCode

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.2 Address Compilation Minimal v2 (DYNAMIC)
hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:addr

AD

0 … 1

Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional.

Beinhaltet 1.2.40.0.34.6.0.11.9.10.2 Address Compilation Minimal v2 (DYNAMIC)

hl7:addr

AD

0 … 1

Die Adresse des Geburtsorts, struktuiert.
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:languageCommunication

0 … *

R

Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten.


	at-cda-bbr-dataelement-100	Sprachfähigkeit	Dataset A Allgemeiner Leitfaden

hl7:languageCode

CS

1 … 1

M

Sprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen).

In der Klasse languageCommunication können Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform (z.B. gesprochen oder geschrieben) des Patienten angegeben werden.
Dieser Leitfaden schränkt die möglichen Werte für die Sprache auf Werte aus dem Value Set ELGA_HumanLanguage ein.

Die Gebärdensprache ist als eigene Sprache inkl. Ländercode anzugeben, mit der Ergänzung des Länder-/Regional-Codes (z.B. sgn-at), die Ausdrucksweise (MoodCode) wird in diesem Fall nicht angegeben (denn expressed / received signed wären redundant).


	at-cda-bbr-dataelement-101	Sprache	Dataset A Allgemeiner Leitfaden

@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

C

Ausdrucksform der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_LanguageAbilityMode“

@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

Constraint

Bei Strukturierung einer Gebärdensprache ist dieses Element NICHT ERLAUBT, NP [0..0] und MUSS daher komplett entfallen

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC)

hl7:proficiencyLevelCode

CE

0 … 1

R

Grad der Sprachkenntnis in der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“


	at-cda-bbr-dataelement-102	Grad der Sprachkenntnis	Dataset A Allgemeiner Leitfaden

@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:preferenceInd

BL

0 … 1

R

Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.


	at-cda-bbr-dataelement-103	Sprachpräferenz	Dataset A Allgemeiner Leitfaden

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.2.1 Author v2 Prescriber (DYNAMIC)

hl7:author

1 … 1

M

Verfasser des Dokuments.

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

1 … 1

M

Internationaler Funktionscode des Verfassers des Dokuments, z.B: „Generalist medical practitioners“, „Specialist medical practitioners“,„Nursing professionals“.

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

F

2.16.840.1.113883.2.9.6.2.7

@codeSystemName

st

1 … 1

F

ISCO-08

@displayName

st

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.1 eHDSIHealthcareProfessionalRole (DYNAMIC)

Auswahl

1 … 1

Der Zeitpunkt, zu 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

wo [not(@nullFlavor)]

hl7:time

TS.AT.TZ

0 … 1

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:assignedAuthor

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software.

ODER Identifikation des/der datenerstellenden Gerätes/Software.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NA“ haben und es dürfen keine anderen Attribute vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens ein Attribut vorhanden sein

@nullFlavor

cs

0 … 1

F

NA

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.

@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:addr

AD

1 … *

R

Angabe der Adresse des Verfassers des Dokuments
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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.

hl7:assignedPerson

1 … 1

M

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)

hl7:representedOrganization

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 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.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

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.2 Custodian v2 (DYNAMIC)

hl7:custodian

1 … 1

M

Verwahrer des Dokuments.


	at-cda-bbr-dataelement-24	Verwahrer	Dataset A Allgemeiner Leitfaden

@typeCode

cs

0 … 1

F

CST

hl7:assignedCustodian

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:representedCustodianOrganization

1 … 1

M

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … *

M

Identifikation des Verwahrers des Dokuments. Wenn dieser im GDA-I angeführt ist, ist die entsprechende OID zu verwenden.
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

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.

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verwahrers des originalen Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.
Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Kontaktdaten vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es müssen Kontaktdaten vorhanden sein.

@value

st

1 … 1

R

@use

set_cs

0 … 1

Bedeutung des angegebenen Kontakts gemäß Value-Set „ELGA_TelecomAddressUse“

@nullFlavor

cs

0 … 1

F

NI

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.2 Address Compilation v2 (DYNAMIC)

Eingefügt

1 … *

M

von 1.2.40.0.34.6.0.11.1.5.2 Legal Authenticator v2 (DYNAMIC)

hl7:legalAuthenticator

1 … *

M

Hauptunterzeichner, Rechtlicher Unterzeichner


	at-cda-bbr-dataelement-1	Rechtlicher Unterzeichner	Dataset A Allgemeiner Leitfaden

@contextControlCode

cs

0 … 1

F

OP

@typeCode

cs

0 … 1

F

LA

hl7:time

TS.AT.TZ

1 … 1

M

Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.


	at-cda-bbr-dataelement-5	Zeitpunkt der Unterzeichnung	Dataset A Allgemeiner Leitfaden

hl7:signatureCode

CS

1 … 1

M

Signaturcode gibt an, dass das Originaldokument unterzeichnet wurde.


	at-cda-bbr-dataelement-6	Signatur	Dataset A Allgemeiner Leitfaden

@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.41.2 Assigned Entity with id, name, addr and telecom v2 (DYNAMIC)

hl7:documentationOf

1 … *

M

Beginn und Ende des Gültigkeitszeitraums wie auch Rezeptart

Beispiel

hl7:serviceEvent

1 … 1

M

hl7:code

CE

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.68 ELGA_MedikationRezeptart (DYNAMIC)

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:effectiveTime[not(@nullFlavor)]
hl7:effectiveTime[@nullFlavor]

hl7:effectiveTime

IVL_TS

wo [not(@nullFlavor)]

hl7:low

TS

1 … 1

M

Beginn des Gültigkeitszeitraums
Befüllungsvorschrift gemäß Rezeptpflichtgesetz:
Bei Kassen- und Privatrezepten: Muss immer mit dem aktuellen Datum befüllt sein.
Bei Substitutionsrezepten: Datum frei wählbar.

hl7:high

TS

1 … 1

M

Ende des Gültigkeitszeitraums
Befüllungsvorschrift gemäß Rezeptpflichtgesetz:
Bei Kassenrezepten: Fix: Beginn des Gültigkeitszeitraums + 1 Monat + 1 Tag
Bei Privatrezepten: Mindestens: Beginn des Gültigkeitszeitraums + 1 Monat + 1 Tag; Maximal: Beginn des Gültigkeitszeitraums + 1 Jahr
Bei Substitutionsrezepten: Datum frei wählbar, aber später als das Beginndatum.

Schematron assert

role

error

test

string-length(hl7:low/@value)<=8 and string-length(hl7:high/@value)<=8

Meldung

Datumsangaben für Beginn- und Ende des Gültigkeitszeitraums sind immer ohne Zeitangabe vorzunehmen (z.B. „20141224“ für den 24.12.2014).

hl7:effectiveTime

IVL_TS

Gültigkeitsdauer nicht angegeben

wo [@nullFlavor]

@nullFlavor

cs

1 … 1

F

MSK

hl7:relatedDocument

1 … 1

M

@typeCode

cs

1 … 1

F

XFRM

hl7:parentDocument

1 … 1

M

@classCode

cs

0 … 1

F

DOCCLIN

@moodCode

cs

0 … 1

F

EVN

hl7:id

II.EPSOS

1 … *

R

@nullFlavor

cs

0 … 1

F

NA

hl7:code

CD.EPSOS

0 … 1

R

@codeSystem

CONF

0 … 1

F

2.16.840.1.113883.6.1 (LOINC)

hl7:text

ED

0 … 1

R

hl7:setId

II.EPSOS

0 … 1

R

hl7:versionNumber

INT

0 … 1

R

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.1.14 Document Replacement - Related Document (DYNAMIC)

hl7:relatedDocument

0 … 1

R


	at-cda-bbr-dataelement-15	Bezug zu vorgehenden Dokumenten	Dataset A Allgemeiner Leitfaden

@typeCode

cs

1 … 1

R

Art des Bezugs zum Vordokument.

Constraint

Erlaubte @typeCodes:

RPLC - replaces: Das Dokument ersetzt ein existierendes Dokument. Der Status des zu ersetzenden Dokumentes wird auf "deprecated" gesetzt, das ursprüngliche Dokument bleibt aber noch im System als historische Referenz verfügbar.

APND - append: Zusammenhängen von Dokumenten. Dies ist in ELGA bereits über das Einbetten von Dokumenten realisiert.

XFRM - transformed: Das Dokument ist Ergebnis eines Transformationsprozesses, d.h. ist aus einem anderen Originaldokument hervorgegangen.

Hinweis: Die parallele Ablage von CDA-Dokumenten, welche vom Dokumentersteller bereits mit einem Stylesheet zu einem PDF Dokument gerendert wurden, kann mit der XFRM – Transaktion vorgenommen werden. Es ist nicht auszuschließen, dass die Transformation in lokalen Affinity Domains Anwendung findet. Für ELGA ist die Transformation jedoch kein Anwendungsfall.

hl7:parentDocument

1 … 1

M

Vorhergehendes Dokument.

@classCode

cs

0 … 1

F

DOCCLIN

@moodCode

cs

0 … 1

F

EVN

hl7:id

II

1 … 1

M

Dokumenten-Id des vorgehenden Dokuments.

Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

hl7:component

@typeCode

cs

0 … 1

F

COMP

@contextConductionInd

bl

0 … 1

F

true

hl7:structuredBody

@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.137 Rezept - kodiert (DYNAMIC)

@typeCode

cs

0 … 1

F

COMP

@contextConductionInd

bl

0 … 1

F

true

7.3.1.2 Abgabe

Id

1.2.40.0.34.6.0.11.0.22

Gültigkeit ab

2024‑06‑10 15:45:57

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atemed_document_abgabe

Bezeichnung

Abgabe

Beschreibung

In diesem Dokument sind die an den Patienten abgegebenen Arzneimittel aufgeführt. Die entsprechenden Informationen liegen zudem in maschinenlesbarer Form vor. Unter einer Abgabe versteht man die Ausgabe von Arzneimitteln oder anderen apothekenpflichtigen Produkten an den Patienten.

Kontext

Pfadname /

Klassifikation

CDA Document Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 14 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.1.10	Inklusion	Document Realm (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.1.30	Inklusion	Document TypeId (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.1	Inklusion	Document Id (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.46	Inklusion	Document TerminologyDate (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.11	Inklusion	Document Effective Time (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.1.12	Inklusion	Document Confidentiality Code (1.0.2+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.1.13	Inklusion	Document Language (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.15	Inklusion	Document Set Id and Version Number (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.3.2	Inklusion	Record Target v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.2.2	Inklusion	Author v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.4.2	Inklusion	Custodian v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.5.2	Inklusion	Legal Authenticator v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.14	Inklusion	Document Replacement - Related Document (1.0.1+20210628)	DYNAMIC
1.2.40.0.34.6.0.11.2.138	Containment	Abgabe - kodiert (3.0.0+20250228)	DYNAMIC

Beispiel

<cda:ClinicalDocument>
  
  
  
  <cda:realmCode code="AT"/>  
  <cda:typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>  
  
  <cda:templateId root="1.2.40.0.34.6.0.11.0.1"/>  
  <cda:templateId root="1.2.40.0.34.7.8.9.3"/>  
  <cda:templateId root="1.2.40.0.34.6.0.11.0.22"/>  
  <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.1.2"/>  
  <cda:id root="1.2.40.0.34.99.4613.3.1" extension="123456.1" assigningAuthorityName="Amadeus Spital"/>  <cda:code codeSystemName="LOINC" code="60593-1" codeSystem="2.16.840.1.113883.6.1" displayName="Medication dispensed.extended Document">
    <cda:translation codeSystemName="LOINC" code="52471-0" codeSystem="2.16.840.1.113883.6.1" displayName="Medications"/>  </cda:code>  <cda:title>Abgabe</cda:title>  
  <hl7at:terminologyDate value="20250610"/>  <cda:formatCode code="urn:hl7-at:emedat:3.0.0+20250615" codeSystem="1.2.40.0.34.5.37" displayName="HL7 Austria e-Medikation 3.0.0+20250615"/>  
  <cda:effectiveTime value="20250615063500+0200"/>  
  <cda:confidentialityCode code="N" displayName="normal" codeSystem="2.16.840.1.113883.5.25" codeSystemName="HL7:Confidentiality"/>  
  <cda:languageCode code="de-AT"/>  
  <cda:setId root="1.2.40.0.34.99.4613.3.1" extension="123456" assigningAuthorityName="Amadeus Spital"/>  <cda:versionNumber value="1"/>  
  <cda:recordTarget>
    <cda:patientRole>
      
      <cda:id root="1.2.40.0.34.99.4613.3.2" extension="121212" assigningAuthorityName="Amadeus Spital"/>      
      <cda:id root="1.2.40.0.10.1.4.3.1" extension="1111241261" assigningAuthorityName="Österreichische Sozialversicherung"/>      
      <cda:addr use="HP">
        <cda:streetAddressLine>Musterstraße 13a</cda:streetAddressLine>        <cda:postalCode>7000</cda:postalCode>        <cda:city>Eisenstadt</cda:city>        <cda:state>Burgenland</cda:state>        <cda:country>AT</cda:country>      </cda:addr>      
      <cda:telecom use="H" value="tel:+43.2682.40400"/>      <cda:telecom use="MC" value="tel:+43.664.1234567"/>      <cda:telecom value="mailto:musterfrau@provider.at"/>      <cda:patient>
        
        <cda:name>
          <cda:prefix qualifier="AC">Dr.</cda:prefix>          <cda:given>Maria</cda:given>          <cda:given>Johanna</cda:given>          <cda:family>Musterfrau</cda:family>          <cda:family qualifier="BR">VorDerHeirat</cda:family>          <cda:suffix qualifier="AC">BSc</cda:suffix>        </cda:name>        
        <cda:administrativeGenderCode code="F" displayName="Female" codeSystem="2.16.840.1.113883.5.1" codeSystemName="HL7:AdministrativeGender"/>        
        <cda:birthTime value="19611224"/>        
        <cda:maritalStatusCode code="M" displayName="Married" codeSystem="2.16.840.1.113883.5.2" codeSystemName="HL7:MaritalStatus"/>        
        <cda:religiousAffiliationCode code="101" codeSystem="2.16.840.1.113883.2.16.1.4.1" codeSystemName="HL7.AT:ReligionAustria" displayName="Römisch-Katholisch"/>        
        <cda:birthplace>
          <cda:place>
            <cda:addr>
              <cda:streetAddressLine>Musterstraße 23b</cda:streetAddressLine>              <cda:postalCode>8011</cda:postalCode>              <cda:city>Graz</cda:city>              <cda:state>Steiermark</cda:state>              <cda:country>AT</cda:country>            </cda:addr>          </cda:place>        </cda:birthplace>        
        <cda:languageCommunication>
          <cda:languageCode code="de-AT"/>          <cda:modeCode code="ESP" displayName="Expressed spoken" codeSystem="2.16.840.1.113883.5.60" codeSystemName="HL7:LanguageAbilityMode"/>          <cda:proficiencyLevelCode code="E" displayName="Excellent" codeSystem="2.16.840.1.113883.5.61" codeSystemName="HL7:LanguageAbilityProficiency"/>          <cda:preferenceInd value="false"/>        </cda:languageCommunication>        <cda:languageCommunication>
          <cda:languageCode code="en"/>          <cda:modeCode code="ESP" displayName="Expressed spoken" codeSystem="2.16.840.1.113883.5.60" codeSystemName="HL7:LanguageAbilityMode"/>          <cda:proficiencyLevelCode code="F" displayName="Fair" codeSystem="2.16.840.1.113883.5.61" codeSystemName="HL7:LanguageAbilityProficiency"/>          <cda:preferenceInd value="false"/>        </cda:languageCommunication>      </cda:patient>    </cda:patientRole>  </cda:recordTarget>  
  <cda:author>
    
    <cda:functionCode code="2211" codeSystem="2.16.840.1.113883.2.9.6.2.7" codeSystemName="ISCO-08" displayName="Generalist medical practitioners"/>    
    <cda:time value="20250615130100+0200"/>    <cda:assignedAuthor>
      
      <cda:id root="1.2.40.0.34.99.4613.3.3" extension="1111" assigningAuthorityName="Amadeus Spital"/>      
      <cda:code code="116" codeSystem="1.2.40.0.34.5.160" codeSystemName="ELGA_Fachaerzte" displayName="Fachärztin/Facharzt für Innere Medizin">
        
        <cda:addr>
          <cda:streetName>Währinger Gürtel</cda:streetName>          <cda:houseNumber>18-20</cda:houseNumber>          <cda:postalCode>1090</cda:postalCode>          <cda:city>Wien</cda:city>          <cda:state>Wien</cda:state>          <cda:country>AT</cda:country>        </cda:addr>        
        <cda:telecom use="WP" value="tel:+43.1.3453446.1111"/>        
        <cda:assignedPerson>
          <cda:name>
            <cda:prefix>Dr.</cda:prefix>            <cda:family>Dominik</cda:family>            <cda:given>Matic</cda:given>          </cda:name>        </cda:assignedPerson>        
        <cda:representedOrganization>
          
          <cda:id root="1.2.40.0.34.99.4613" assigningAuthorityName="GDA Index"/>          
          <cda:name>Amadeus Spital</cda:name>          
          <cda:telecom value="tel:+43.1.3453446.0"/>          <cda:telecom value="fax:+43.1.3453446.4589"/>          <cda:telecom value="mailto:info@amadeusspital.at"/>          <cda:telecom value="http://www.amadeusspital.at"/>          
          <cda:addr>
            <cda:streetName>Währinger Gürtel</cda:streetName>            <cda:houseNumber>18-20</cda:houseNumber>            <cda:postalCode>1090</cda:postalCode>            <cda:city>Wien</cda:city>            <cda:state>Wien</cda:state>            <cda:country>AT</cda:country>          </cda:addr>        </cda:representedOrganization>      </cda:code>    </cda:assignedAuthor>  </cda:author>  
  <cda:custodian>
    <cda:assignedCustodian>
      <cda:representedCustodianOrganization>
        
        <cda:id root="1.2.40.0.34.99.4613" assigningAuthorityName="GDA Index"/>        
        <cda:name>Amadeus Spital</cda:name>        
        <cda:telecom value="tel:+43.1.3453446.0"/>        
        <cda:addr>
          <cda:streetName>Währinger Gürtel</cda:streetName>          <cda:houseNumber>18-20</cda:houseNumber>          <cda:postalCode>1090</cda:postalCode>          <cda:city>Wien</cda:city>          <cda:state>Wien</cda:state>          <cda:country>AT</cda:country>        </cda:addr>      </cda:representedCustodianOrganization>    </cda:assignedCustodian>  </cda:custodian>  
  <cda:legalAuthenticator>
    
    <cda:time value="20250615135400+0200"/>    
    <cda:signatureCode code="S"/>    
    <cda:assignedEntity>
      
      <cda:id root="1.2.40.0.34.99.4613.3.3" extension="2222" assigningAuthorityName="Amadeus Spital"/>      
      <cda:addr>
        <cda:streetName>Währinger Gürtel</cda:streetName>        <cda:houseNumber>18-20</cda:houseNumber>        <cda:postalCode>1090</cda:postalCode>        <cda:city>Wien</cda:city>        <cda:state>Wien</cda:state>        <cda:country>AT</cda:country>      </cda:addr>      
      <cda:telecom use="WP" value="tel:+43.1.3453446.2222"/>      
      <cda:assignedPerson>
        
        <cda:name>
          <cda:prefix>Univ.-Prof.Dr.</cda:prefix>          <cda:family>Dom</cda:family>          <cda:given>Turio</cda:given>        </cda:name>      </cda:assignedPerson>      
      <cda:representedOrganization>
        
        <cda:id root="1.2.40.0.34.99.4613" assigningAuthorityName="GDA Index"/>        
        <cda:name>Amadeus Spital</cda:name>        
        <cda:telecom value="tel:+43.1.3453446.0"/>        <cda:telecom value="fax:+43.1.3453446.4589"/>        <cda:telecom value="mailto:info@amadeusspital.at"/>        <cda:telecom value="http://www.amadeusspital.at"/>        
        <cda:addr>
          <cda:streetName>Währinger Gürtel</cda:streetName>          <cda:houseNumber>18-20</cda:houseNumber>          <cda:postalCode>1090</cda:postalCode>          <cda:city>Wien</cda:city>          <cda:state>Wien</cda:state>          <cda:country>AT</cda:country>        </cda:addr>      </cda:representedOrganization>    </cda:assignedEntity>  </cda:legalAuthenticator>  <cda:inFulfillmentOf>
    <cda:order nullFlavor="NI" classCode="ACT" moodCode="RQO">
      <cda:id root="1.2.40.0.34.99.4613.3.1" extension="123456.1.1"/>    </cda:order>  </cda:inFulfillmentOf>  <cda:component>
    <cda:structuredBody>
      <cda:component>
        <cda:section>
          
          <cda:templateId root="1.2.40.0.34.6.0.11.2.138"/>          
          <cda:templateId root="1.3.6.1.4.1.19376.1.9.1.2.2"/>          
          <cda:templateId root="2.16.840.1.113883.10.20.1.8"/>          
          <cda:id root="1.2.3.999" extension="extension" assigningAuthorityName="assigningAuthorityName"/>          
          <cda:code code="60590-7" displayName="Medication dispensed" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC">
            
            <cda:title>Abgabe</cda:title>            
            <cda:text> ... Lesbarer Textbereich ... </cda:text>            
            <cda:entry>
              <cda:supply classCode="SPLY" moodCode="EVN">
                <cda:templateId root="1.2.40.0.34.6.0.11.3.187"/>                <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.3.3"/>                <cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.3"/>                <cda:templateId root="2.16.840.1.113883.10.20.1.34"/>                <cda:id root="1.2.3.999" extension="extension"/>                <cda:id root="1.2.3.999" extension="extension"/>                <cda:code code="FFC" codeSystem="2.16.840.1.113883.5.4" displayName="First Fill - Complete">
                  
                </cda:code>                <cda:text>
                  <cda:reference value="--TODO--"/>                </cda:text>                <cda:quantity value="1" unit="1"/>                <cda:product typeCode="PRD">
                  <cda:manufacturedProduct classCode="MANU">
                    <cda:templateId root="1.2.40.0.34.6.0.11.3.186"/>                    <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.3.29"/>                    <cda:manufacturedMaterial classCode="MMAT" determinerCode="KIND">
                      <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.3.30"/>                      <cda:code nullFlavor="NA" code="--code--" codeSystem="1.2.40.0.34.4.16">
                        
                        <cda:translation code="--code--" codeSystem="1.2.40.0.34.4.17"/>                      </cda:code>                      <cda:name nullFlavor="NA">name</cda:name>                      <cda:formCode nullFlavor="NI"/>                      <cda:asContent classCode="CONT">
                        <cda:quantity unit="%" value="1">
                          <cda:translation>
                            
                          </cda:translation>                        </cda:quantity>                        <cda:containerPackagedProduct classCode="CONT" determinerCode="KIND">
                          <cda:formCode nullFlavor="NI"/>                        </cda:containerPackagedProduct>                      </cda:asContent>                      <cda:ingredient classCode="ACTI">
                        <cda:ingredientSubstance classCode="MMAT" determinerCode="KIND">
                          <cda:code>
                            
                            <cda:translation/>                          </cda:code>                          <cda:name>name</cda:name>                        </cda:ingredientSubstance>                      </cda:ingredient>                    </cda:manufacturedMaterial>                  </cda:manufacturedProduct>                </cda:product>                <cda:performer nullFlavor="NI" typeCode="PRF">
                  <cda:time value="20250615"/>                  <cda:assignedEntity>
                    
                  </cda:assignedEntity>                </cda:performer>                
                <cda:entryRelationship typeCode="REFR">
                  <cda:substanceAdministration classCode="SBADM" moodCode="INT">
                    <cda:id root="1.2.40.0.10.1.4.3.4.2.2" extension="extension"/>                    <cda:consumable nullFlavor="NA"/>                  </cda:substanceAdministration>                </cda:entryRelationship>                
                
                <cda:entryRelationship typeCode="SUBJ" inversionInd="true">
                  
                </cda:entryRelationship>                <cda:entryRelationship typeCode="SUBJ" inversionInd="true">
                  
                </cda:entryRelationship>                
                <cda:entryRelationship typeCode="COMP">
                  
                </cda:entryRelationship>                <cda:entryRelationship typeCode="COMP">
                  <cda:act classCode="ACT" moodCode="EVN">
                    <cda:code code="SUBST" codeSystem="2.16.840.1.113883.5.6"/>                  </cda:act>                </cda:entryRelationship>                
              </cda:supply>            </cda:entry>          </cda:code>        </cda:section>      </cda:component>    </cda:structuredBody>  </cda:component></cda:ClinicalDocument>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:ClinicalDocument

@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)

hl7:realmCode

CS

1 … 1

M

Hoheitsbereich des Dokuments.

Fester Wert: @code = AT

(aus Value Set „ELGA_RealmCode“)

@code

1 … 1

F

AT

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.30 Document TypeId (DYNAMIC)

hl7:typeId

II

1 … 1

M

Dokumentformat CDA R2

@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

Fixe OID für alle Dokumente, die in der Governance-Gruppe "eHealth Austria" abgestimmt werden und von einem zentralen Art-Decor-Repository abgeleitet werden (AT-CDA-BBR).

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.0.1

hl7:templateId

II

1 … 1

M

Root-OID des Implementierungsleitfadens (Dokument-OID). Dient als informative Referenz.

@root

uid

1 … 1

F

1.2.40.0.34.7.8.9.3

hl7:templateId

II

1 … 1

M

Template Spezieller Implementierungsleitfaden ELGA eMedikation v3 Abgabe

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.0.22

hl7:templateId

II

1 … 1

M

eHDSI Dispensation

@root

uid

1 … 1

F

1.3.6.1.4.1.12559.11.10.1.3.1.1.2

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.1 Document Id (DYNAMIC)

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.

@root

uid

1 … 1

R

hl7:code

CE

1 … 1

M

Für die e-Medikations Abgabe ist als Dokumententyp (/ClinicalDocument/code) "60593-1 - Medication dispensed.extended Document" und als Dokumentenklasse (/ClinicalDocument/code/translation) "52471-0 - Medications" anzugeben.

↔ Hinweis zum XDS-Mapping:

Das code-Element wird in das XDS-Metadaten-Attribut XDSDocumentEntry.typeCode übernommen.
Das translation-Element wird in das XDS-Metadaten-Attribut XDSDocumentEntry.classCode übernommen.

@codeSystemName

st

0 … 1

F

LOINC

@code

CONF

1 … 1

F

60593-1

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

Medication dispensed.extended Document

hl7:translation

CD

1 … 1

M

Fixe Dokumentenklasse "52471-0 - Medications"

@codeSystemName

st

0 … 1

F

LOINC

@code

CONF

1 … 1

F

52471-0

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

Medications

hl7:title

ST

1 … 1

M

Der Titel des Dokuments muss mit "Abgabe" oder "Dispense" beginnen und ist für den lesenden Dokumentempfänger das sichtbare Element. Dieser wird nicht dem Attribut displayName des Elements code entnommen, sondern dem (verpflichtenden) Element title.

sdtc:statusCode

CS

NP

e-Medikations Dokumente sind immer abgeschlossene bzw. "fertige" Dokumente - in diesem Fall erübrigt sich die Angabe eines Status.

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.46 Document TerminologyDate (DYNAMIC)

hl7at:terminologyDate

TS.DATE.FULL

1 … 1

M

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.

Constraint

Das Datum der letzten Terminologie-Aktualisierung MUSS entsprechend klassischer HL7 V3 Notation im Format "YYYYMMDD" angegeben werden.
Beispiel: 20200527

hl7at:formatCode

CD

1 … 1

M

↔ Hinweis zum XDS-Mapping: @code wird in das XDS-Attribut XDSDocumentEntry.formatCode übernommen.

@code

CONF

1 … 1

F

urn:hl7-at:emedat:3.0.0+20250615

@codeSystem

1 … 1

F

1.2.40.0.34.5.37

@displayName

1 … 1

F

HL7 Austria e-Medikation 3.0.0+20250615

hl7at:practiceSettingCode

CD

NP

e-Medikations Dokumente werden keinem Fach zugewiesen - in diesem Fall erübrigt sich die Angabe eines practiceSettingCodes.

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.


	at-cda-bbr-dataelement-11	Erstellungsdatum	Dataset A Allgemeiner Leitfaden

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 Value Set „ELGA_Confidentiality“.


	at-cda-bbr-dataelement-13	Vertraulichkeitscode	Dataset A Allgemeiner Leitfaden

@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:languageCode

CS.LANG

1 … 1

M

Sprachcode des Dokuments.


	at-cda-bbr-dataelement-14	Sprachcode	Dataset A Allgemeiner Leitfaden

@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 ELGA_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.

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.

@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.3.2 Record Target v2 (DYNAMIC)

hl7:recordTarget

1 … 1

M

Komponente für die Patientendaten.


	at-cda-bbr-dataelement-64	Patient	Dataset A Allgemeiner Leitfaden

@typeCode

cs

0 … 1

F

RCT

@contextControlCode

cs

0 … 1

F

OP

hl7:patientRole

1 … 1

M

Patientendaten

@classCode

cs

0 … 1

F

PAT

hl7:id

II

2 … *

R

Patientenidentifikatoren


at-cda-bbr-dataelement-193	EKVK	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-65	LokaleID	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-66	SVNr	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-67	bPK-GH	Dataset A Allgemeiner Leitfaden

Constraint

Hinweis: Die Reihenfolge der id-Elemente MUSS unbedingt eingehalten werden!

* id[1] Identifikation des Patienten im lokalen System (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[@root="1.2.40.0.10.2.1.1.149"] Bereichsspezifisches Personenkennzeichen (0..1 O):
- @root : OID der österreichischen bPK, fester Wert: 1.2.40.0.10.2.1.1.149 (1..1 M)
- @extension : bPK des Patienten: concat(Bereichskürzel, ":", bPK) (Base64,28 Zeichen). Typischerweise bPK-GH (Gesundheit). Kann im Zusammenhang mit E-ID auch andere Bereichskürzel tragen.
Anmerkung : Das bPK dient ausschließlich technisch der Zuordnung der elektronischen Identität und darf daher weder angezeigt werden noch am Ausdruck erscheinen noch in allfälligen Downloads enthalten sein (1..1 M)
- @assigningAuthorityName : Fester Wert: Österreichische Stammzahlenregisterbehörde (0..1 O)

* id[@root="1.2.40.0.34.4.21"] Europäische Krankenversicherungskarte kurz (0..1 O):

- @root: OID der EKVK, fester Wert: 1.2.40.0.34.4.21 (1..1 M)

- @extension: Datenfeld 6 der EKVK

- @assigningAuthorityName : Fester Wert: Nationaler Krankenversicherungsträger (0..1 O)

* id[@root="1.2.40.0.10.1.4.3.8"] Europäische Krankenversicherungskarte lang (0..1 O):
- @root: OID der EKVK, fester Wert: 1.2.40.0.10.1.4.3.8 (1..1 M)

- @extension: Datenfelder der EKVK nach folgender Bildungsvorschrift: concat(Feld 6,"^",Feld 7,"^",Feld 8,"^",Feld 9) wobei Feld 6 "Persönliche Kennnummer" angegeben sein MUSS (1..1 M). Die übrigen Datenfelder sind optional (0..1 O). In Feld 9 MUSS die Datumsangabe im Format YYYMMDD erfolgen.

- @assigningAuthorityName : Fester Wert: Nationaler Krankenversicherungsträger (0..1 O)

Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen.

Beispiel

Europäische Krankenversicherungskarte kurz

Beispiel

Europäische Krankenversicherungskarte lang

hl7:addr

1 … *

R

Adresse des Patienten.

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „NI“ und es dürfen keine Adressteile vorhanden sein.
Es MUSS eine mögliche Adresse unterstützt werden. Spezielle Leitfäden (z.B. Entlassungsbrief Pflege) können es erforderlich machen, dass mehr als eine Adresse unterstützt werden muss.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)


	at-cda-bbr-dataelement-68	Adresse	Dataset A Allgemeiner Leitfaden

@nullFlavor

cs

0 … 1

F

NI

Constraint

Werden mehrere gleichartige address-Elemente strukturiert (z.B. Home, Pflege), MUSS jeweils das Attribut @use angeführt sein.

hl7:telecom

TEL.AT

1 … *

R

Kontakt-Element. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „NI“ und die Attribute „value“ und „use“ wie auch alle inneren Elemente entfallen.


	at-cda-bbr-dataelement-72	Kontaktdaten	Dataset A Allgemeiner Leitfaden

@nullFlavor

cs

0 … 1

F

NI

@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 gleichartige 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.


	at-cda-bbr-dataelement-70	Name	Dataset A Allgemeiner Leitfaden

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Namen-Element (Person)

@use

cs

0 … 1

Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.

Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“.

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

hl7:prefix

ENXP

0 … *

Beliebig viele Präfixe zum Namen, z.B. Akademische Titel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!

@qualifier

cs

0 … 1

Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:family

ENXP

1 … *

M

Mindestens ein Hauptname (Nachname).

@qualifier

cs

0 … 1

Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:given

ENXP

1 … *

M

Mindestens ein Vorname

@qualifier

cs

0 … 1

Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:suffix

ENXP

0 … *

Beliebig viele Suffixe zum Namen

@qualifier

cs

0 … 1

Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

Auswahl

1 … 1

Das "administrative Geschlecht" ist das soziale oder gesellschaftliche Geschlecht ("Gender"). Das administrative Geschlecht ist daher grundsätzlich getrennt von den biologischen Merkmalen der Person zu sehen. Grundsätzlich soll das administrative Geschlecht dem im Zentralen Melderegister (ZMR) eingetragenen Geschlecht entsprechen.

Über ein Translation-Element können weitere Angaben zum Geschlecht gemacht werden, wenn diese abweichend vom administrativen Geschlecht sind, z.B.:

Biologisches Geschlecht
Geschlecht in der Sozialversicherung
Geschlecht für die Stations-/Bettenbelegung im Krankenhaus

Codierung des Geschlechts des Patienten aus ValueSet "ELGA_AdministrativeGender".

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „UNK“ und alle Attribute wie auch alle inneren Elemente entfallen.

Elemente in der Auswahl:

hl7:administrativeGenderCode[not(@nullFlavor)]
hl7:administrativeGenderCode[@nullFlavor='UNK']

hl7:administrativeGenderCode

CE

0 … 1

wo [not(@nullFlavor)]


	at-cda-bbr-dataelement-74	Geschlecht	Dataset A Allgemeiner Leitfaden

@displayName

st

1 … 1

R

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

R

@codeSystemName

st

0 … 1

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC)

hl7:translation

CD

0 … *

R

Über ein Translation-Element können weitere Angaben zum Geschlecht gemacht werden, wenn diese abweichend vom administrativen Geschlecht sind, z.B.: Biologisches Geschlecht, Geschlecht in der Sozialversicherung, Geschlecht für die Stations-/Bettenbelegung im Krankenhaus

@displayName

st

1 … 1

R

Beispiel

Beispiel für eine SNOMED CT Angabe

hl7:administrativeGenderCode

CE

0 … 1

Mittels nullFlavor="UNK" wird "Unbekannt" abgebildet. Dies schließt die Ausprägung "Keine Angabe" mit ein.

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:birthTime

TS.AT.VAR

1 … 1

M

Geburtsdatum des Patienten. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. Das Geburtsdatum des Patienten kann ein Teildatum sein, z. B. nur die Jahreszahl.


	at-cda-bbr-dataelement-75	Geburtsdatum	Dataset A Allgemeiner Leitfaden

sdtc:deceasedInd

BL

0 … 1

R

Kennzeichen, dass die Person verstorben ist. Kann alternativ zum Todesdatum angegeben werden, v.a. wenn der Todeszeitpunkt nicht bekannt ist.


	at-cda-bbr-dataelement-192	Verstorben-Kennzeichen	Dataset A Allgemeiner Leitfaden

sdtc:deceasedTime

TS.AT.TZ

0 … 1

R

Todesdatum der Person.


	at-cda-bbr-dataelement-191	Todesdatum	Dataset A Allgemeiner Leitfaden

hl7:maritalStatusCode

CE

0 … 1

R

Codierung des Familienstands des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“


	at-cda-bbr-dataelement-98	Familienstand	Dataset A Allgemeiner Leitfaden

@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:religiousAffiliationCode

CE

0 … 1

R

Codierung des Religionsbekenntnisses des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“


	at-cda-bbr-dataelement-99	Religionsbekenntnis	Dataset A Allgemeiner Leitfaden

@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!

hl7:ethnicGroupCode

NP

Ethnische Zugehörigkeit des Patienten.

Darf nicht verwendet werden!

hl7:guardian

0 … *

R

Gesetzlicher Vertreter:

Vorsorgebevollmächtigte/r (Bevollmächtigte/r durch Vorsorgevollmacht)
Gewählte/r ErwachsenenvertreterIn
Gesetzliche/r ErwachsenenvertreterIn
Gerichtliche/r ErwachsenenvertreterIn (Sachwalter)

Der gesetzliche Vetreter kann entweder eine Person (guardianPerson) oder eine Organisation (guardianOrganization) sein.

Beim Patienten können optional ein oder mehrere gesetzliche Vetreter angegeben werden. Wenn ein gesetzliche Vetreter bekannt ist, SOLL diese Information auch angegeben werden.


	at-cda-bbr-dataelement-88	Gesetzlicher Vertreter	Dataset A Allgemeiner Leitfaden

@classCode

cs

1 … 1

F

GUARD

@nullFlavor

cs

0 … 1

Verwenden Sie einen nullFlavor, wenn aus bestimmten Gründen keine Informationen vorliegen.

hl7:templateId

II

1 … 1

M

Template id für IHE PCC Patient Contacts.

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.2.4

hl7:code

CE

0 … 1

R

Die Beziehung zwischen dem Patienten und dem gesetzlicher Vertreter kann im Code-Element erfasst werden.

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.38 eHDSIPersonalRelationship (DYNAMIC)

hl7:addr

1 … 1

R

Die Adresse des gesetzlichen Vertreters oder der Organisation ist verpflichtend.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Adressteile vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens einer der nachstehend aufgeführten Adressteile vorhanden sein

Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

@nullFlavor

cs

0 … 1

F

NI

hl7:telecom

TEL.AT

1 … *

R

Beliebig viele Kontaktdaten des gesetzlichen Vertreters als Person oder Organisation.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Kontaktdaten vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens einer der nachstehend aufgeführten Kontaktdaten vorhanden sein

Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.

@nullFlavor

cs

0 … 1

F

NI

@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 gleichartige 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:guardianPerson welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
hl7:guardianPerson welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
hl7:guardianOrganization welches enthält Template 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)

hl7:guardianPerson

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)

hl7:guardianPerson

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)

hl7:guardianOrganization

0 … 1

R

Name des gesetzlichen Vertreters (Organisation)
Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)

hl7:birthplace

0 … 1

R

Geburtsort des Patienten.


	at-cda-bbr-dataelement-76	Geburtsort	Dataset A Allgemeiner Leitfaden

@classCode

cs

0 … 1

F

BIRTHPL

hl7:place

1 … 1

M

Ort

@classCode

cs

0 … 1

F

PLC

@determinerCode

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.2 Address Compilation Minimal v2 (DYNAMIC)
hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:addr

AD

0 … 1

Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional.

Beinhaltet 1.2.40.0.34.6.0.11.9.10.2 Address Compilation Minimal v2 (DYNAMIC)

hl7:addr

AD

0 … 1

Die Adresse des Geburtsorts, struktuiert.
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:languageCommunication

0 … *

R

Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten.


	at-cda-bbr-dataelement-100	Sprachfähigkeit	Dataset A Allgemeiner Leitfaden

hl7:languageCode

CS

1 … 1

M

Sprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen).

In der Klasse languageCommunication können Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform (z.B. gesprochen oder geschrieben) des Patienten angegeben werden.
Dieser Leitfaden schränkt die möglichen Werte für die Sprache auf Werte aus dem Value Set ELGA_HumanLanguage ein.

Die Gebärdensprache ist als eigene Sprache inkl. Ländercode anzugeben, mit der Ergänzung des Länder-/Regional-Codes (z.B. sgn-at), die Ausdrucksweise (MoodCode) wird in diesem Fall nicht angegeben (denn expressed / received signed wären redundant).


	at-cda-bbr-dataelement-101	Sprache	Dataset A Allgemeiner Leitfaden

@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

C

Ausdrucksform der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_LanguageAbilityMode“

@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

Constraint

Bei Strukturierung einer Gebärdensprache ist dieses Element NICHT ERLAUBT, NP [0..0] und MUSS daher komplett entfallen

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC)

hl7:proficiencyLevelCode

CE

0 … 1

R

Grad der Sprachkenntnis in der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“


	at-cda-bbr-dataelement-102	Grad der Sprachkenntnis	Dataset A Allgemeiner Leitfaden

@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:preferenceInd

BL

0 … 1

R

Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.


	at-cda-bbr-dataelement-103	Sprachpräferenz	Dataset A Allgemeiner Leitfaden

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.2 Author v2 (DYNAMIC)

hl7:author

1 … 1

M

Verfasser des Dokuments.

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

1 … 1

M

Internationaler Funktionscode des Verfassers des Dokuments, z.B: „Generalist medical practitioners“, „Specialist medical practitioners“,„Nursing professionals“.

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

F

2.16.840.1.113883.2.9.6.2.7

@codeSystemName

st

1 … 1

F

ISCO-08

@displayName

st

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.1 eHDSIHealthcareProfessionalRole (DYNAMIC)

Auswahl

1 … 1

Der Zeitpunkt, zu 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

wo [not(@nullFlavor)]

hl7:time

TS.AT.TZ

0 … 1

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:assignedAuthor

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software.

ODER Identifikation des/der datenerstellenden Gerätes/Software.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NA“ haben und es dürfen keine anderen Attribute vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens ein Attribut vorhanden sein

@nullFlavor

cs

0 … 1

F

NA

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.

@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:addr

AD

1 … *

R

Angabe der Adresse des Verfassers des Dokuments
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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:assignedPerson welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
hl7:assignedAuthoringDevice welches enthält Template 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC)

hl7:assignedPerson

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)

hl7:assignedAuthoringDevice

0 … 1

Datenerstellende/s Software/Gerät
Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC)

hl7:representedOrganization

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 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.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

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“

Ausnahme: Wenn als Author ein/e Software/Gerät fungiert und keine OID aus dem GDA-I angegeben werden kann, MÜSSEN die Angaben der Organisation des Geräte-/Software-Betreibers oder Herstellers entsprechen.

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.4.2 Custodian v2 (DYNAMIC)

hl7:custodian

1 … 1

M

Verwahrer des Dokuments.


	at-cda-bbr-dataelement-24	Verwahrer	Dataset A Allgemeiner Leitfaden

@typeCode

cs

0 … 1

F

CST

hl7:assignedCustodian

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:representedCustodianOrganization

1 … 1

M

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … *

M

Identifikation des Verwahrers des Dokuments. Wenn dieser im GDA-I angeführt ist, ist die entsprechende OID zu verwenden.
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

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.

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verwahrers des originalen Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.
Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Kontaktdaten vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es müssen Kontaktdaten vorhanden sein.

@value

st

1 … 1

R

@use

set_cs

0 … 1

Bedeutung des angegebenen Kontakts gemäß Value-Set „ELGA_TelecomAddressUse“

@nullFlavor

cs

0 … 1

F

NI

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.2 Address Compilation v2 (DYNAMIC)

Eingefügt

1 … *

M

von 1.2.40.0.34.6.0.11.1.5.2 Legal Authenticator v2 (DYNAMIC)

hl7:legalAuthenticator

1 … *

M

Hauptunterzeichner, Rechtlicher Unterzeichner


	at-cda-bbr-dataelement-1	Rechtlicher Unterzeichner	Dataset A Allgemeiner Leitfaden

@contextControlCode

cs

0 … 1

F

OP

@typeCode

cs

0 … 1

F

LA

hl7:time

TS.AT.TZ

1 … 1

M

Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.


	at-cda-bbr-dataelement-5	Zeitpunkt der Unterzeichnung	Dataset A Allgemeiner Leitfaden

hl7:signatureCode

CS

1 … 1

M

Signaturcode gibt an, dass das Originaldokument unterzeichnet wurde.


	at-cda-bbr-dataelement-6	Signatur	Dataset A Allgemeiner Leitfaden

@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.41.2 Assigned Entity with id, name, addr and telecom v2 (DYNAMIC)

hl7:inFulfillmentOf

1 … *

M

@typeCode

cs

0 … 1

F

FLFS

hl7:order

1 … 1

R

@nullFlavor

cs

0 … 1

F

NI

@classCode

cs

0 … 1

F

ACT

@moodCode

cs

1 … 1

F

RQO

hl7:id

II

1 … *

R

hl7:code

CE

0 … 1

@codeSystem

CONF

0 … 1

F

2.16.840.1.113883.5.4 (Act Code)

hl7:priorityCode

CE

0 … 1

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.16866 ActPriority (DYNAMIC)

hl7:relatedDocument

0 … 1

R

@typeCode

cs

1 … 1

F

XFRM

hl7:parentDocument

1 … 1

R

@classCode

cs

0 … 1

F

DOCCLIN

@moodCode

cs

0 … 1

F

EVN

hl7:id

II.EPSOS

1 … *

M

hl7:code

CD.EPSOS

0 … 1

R

@codeSystem

CONF

0 … 1

F

2.16.840.1.113883.6.1 (LOINC)

hl7:text

ED

0 … 1

R

hl7:setId

II.EPSOS

0 … 1

R

hl7:versionNumber

INT

0 … 1

R

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.1.14 Document Replacement - Related Document (DYNAMIC)

hl7:relatedDocument

0 … 1

R


	at-cda-bbr-dataelement-15	Bezug zu vorgehenden Dokumenten	Dataset A Allgemeiner Leitfaden

@typeCode

cs

1 … 1

R

Art des Bezugs zum Vordokument.

Constraint

Erlaubte @typeCodes:

RPLC - replaces: Das Dokument ersetzt ein existierendes Dokument. Der Status des zu ersetzenden Dokumentes wird auf "deprecated" gesetzt, das ursprüngliche Dokument bleibt aber noch im System als historische Referenz verfügbar.

APND - append: Zusammenhängen von Dokumenten. Dies ist in ELGA bereits über das Einbetten von Dokumenten realisiert.

XFRM - transformed: Das Dokument ist Ergebnis eines Transformationsprozesses, d.h. ist aus einem anderen Originaldokument hervorgegangen.

Hinweis: Die parallele Ablage von CDA-Dokumenten, welche vom Dokumentersteller bereits mit einem Stylesheet zu einem PDF Dokument gerendert wurden, kann mit der XFRM – Transaktion vorgenommen werden. Es ist nicht auszuschließen, dass die Transformation in lokalen Affinity Domains Anwendung findet. Für ELGA ist die Transformation jedoch kein Anwendungsfall.

hl7:parentDocument

1 … 1

M

Vorhergehendes Dokument.

@classCode

cs

0 … 1

F

DOCCLIN

@moodCode

cs

0 … 1

F

EVN

hl7:id

II

1 … 1

M

Dokumenten-Id des vorgehenden Dokuments.

Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

hl7:component

@typeCode

cs

0 … 1

F

COMP

@contextConductionInd

bl

0 … 1

F

true

hl7:structuredBody

@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.138 Abgabe - kodiert (DYNAMIC)

@typeCode

cs

0 … 1

F

COMP

@contextConductionInd

bl

0 … 1

F

true

7.3.1.3 Pharmazeutische Empfehlung

Id

1.2.40.0.34.6.0.11.0.21

Gültigkeit ab

2024‑06‑10 15:49:13

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atemed_document_pharmazeutische_empfehlung

Bezeichnung

Pharmazeutische Empfehlung

Beschreibung

In diesem Dokument sind die Korrekturmeldungen (Pharmazeutische Empfehlungen) aufgeführt. Diese Informationen stehen ebenfalls in maschinenlesbarer Form zur Verfügung. Einzelne Verordnungen können mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) verändert wie auch storniert werden. Abgaben können mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) abgesetzt werden.

Kontext

Pfadname /

Klassifikation

CDA Document Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 14 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.1.10	Inklusion	Document Realm (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.1.30	Inklusion	Document TypeId (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.1	Inklusion	Document Id (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.46	Inklusion	Document TerminologyDate (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.11	Inklusion	Document Effective Time (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.1.12	Inklusion	Document Confidentiality Code (1.0.2+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.1.13	Inklusion	Document Language (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.15	Inklusion	Document Set Id and Version Number (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.3.2	Inklusion	Record Target v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.2.2	Inklusion	Author v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.4.2	Inklusion	Custodian v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.5.2	Inklusion	Legal Authenticator v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.14	Inklusion	Document Replacement - Related Document (1.0.1+20210628)	DYNAMIC
1.2.40.0.34.6.0.11.2.139	Containment	Pharmazeutische Empfehlung - kodiert (3.0.0+20250228)	DYNAMIC

Beispiel

<cda:ClinicalDocument>
  
  
  
  <cda:realmCode code="AT"/>  
  <cda:typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>  
  
  <cda:templateId root="1.2.40.0.34.6.0.11.0.1"/>  
  <cda:templateId root="1.2.40.0.34.7.8.9.3"/>  
  <cda:templateId root="1.2.40.0.34.6.0.11.0.21"/>  
  <cda:id root="1.2.40.0.34.99.4613.3.1" extension="123456.1" assigningAuthorityName="Amadeus Spital"/>  <cda:code codeSystemName="LOINC" code="61356-2" codeSystem="2.16.840.1.113883.6.1" displayName="Medication pharmaceutical advice.extended Document">
    <cda:translation codeSystemName="LOINC" code="52471-0" codeSystem="2.16.840.1.113883.6.1" displayName="Medications"/>  </cda:code>  <cda:title>Pharmazeutische Empfehlung</cda:title>  
  <hl7at:terminologyDate value="20250610"/>  <cda:formatCode code="urn:hl7-at:emedat:3.0.0+20250615" codeSystem="1.2.40.0.34.5.37" displayName="HL7 Austria e-Medikation 3.0.0+20250615"/>  
  <cda:effectiveTime value="20250615063500+0200"/>  
  <cda:confidentialityCode code="N" displayName="normal" codeSystem="2.16.840.1.113883.5.25" codeSystemName="HL7:Confidentiality"/>  
  <cda:languageCode code="de-AT"/>  
  <cda:setId root="1.2.40.0.34.99.4613.3.1" extension="123456" assigningAuthorityName="Amadeus Spital"/>  <cda:versionNumber value="1"/>  
  <cda:recordTarget>
    <cda:patientRole>
      
      <cda:id root="1.2.40.0.34.99.4613.3.2" extension="121212" assigningAuthorityName="Amadeus Spital"/>      
      <cda:id root="1.2.40.0.10.1.4.3.1" extension="1111241261" assigningAuthorityName="Österreichische Sozialversicherung"/>      
      <cda:addr use="HP">
        <cda:streetAddressLine>Musterstraße 13a</cda:streetAddressLine>        <cda:postalCode>7000</cda:postalCode>        <cda:city>Eisenstadt</cda:city>        <cda:state>Burgenland</cda:state>        <cda:country>AT</cda:country>      </cda:addr>      
      <cda:telecom use="H" value="tel:+43.2682.40400"/>      <cda:telecom use="MC" value="tel:+43.664.1234567"/>      <cda:telecom value="mailto:musterfrau@provider.at"/>      <cda:patient>
        
        <cda:name>
          <cda:prefix qualifier="AC">Dr.</cda:prefix>          <cda:given>Maria</cda:given>          <cda:given>Johanna</cda:given>          <cda:family>Musterfrau</cda:family>          <cda:family qualifier="BR">VorDerHeirat</cda:family>          <cda:suffix qualifier="AC">BSc</cda:suffix>        </cda:name>        
        <cda:administrativeGenderCode code="F" displayName="Female" codeSystem="2.16.840.1.113883.5.1" codeSystemName="HL7:AdministrativeGender"/>        
        <cda:birthTime value="19611224"/>        
        <cda:maritalStatusCode code="M" displayName="Married" codeSystem="2.16.840.1.113883.5.2" codeSystemName="HL7:MaritalStatus"/>        
        <cda:religiousAffiliationCode code="101" codeSystem="2.16.840.1.113883.2.16.1.4.1" codeSystemName="HL7.AT:ReligionAustria" displayName="Römisch-Katholisch"/>        
        <cda:birthplace>
          <cda:place>
            <cda:addr>
              <cda:streetAddressLine>Musterstraße 23b</cda:streetAddressLine>              <cda:postalCode>8011</cda:postalCode>              <cda:city>Graz</cda:city>              <cda:state>Steiermark</cda:state>              <cda:country>AT</cda:country>            </cda:addr>          </cda:place>        </cda:birthplace>        
        <cda:languageCommunication>
          <cda:languageCode code="de-AT"/>          <cda:modeCode code="ESP" displayName="Expressed spoken" codeSystem="2.16.840.1.113883.5.60" codeSystemName="HL7:LanguageAbilityMode"/>          <cda:proficiencyLevelCode code="E" displayName="Excellent" codeSystem="2.16.840.1.113883.5.61" codeSystemName="HL7:LanguageAbilityProficiency"/>          <cda:preferenceInd value="false"/>        </cda:languageCommunication>        <cda:languageCommunication>
          <cda:languageCode code="en"/>          <cda:modeCode code="ESP" displayName="Expressed spoken" codeSystem="2.16.840.1.113883.5.60" codeSystemName="HL7:LanguageAbilityMode"/>          <cda:proficiencyLevelCode code="F" displayName="Fair" codeSystem="2.16.840.1.113883.5.61" codeSystemName="HL7:LanguageAbilityProficiency"/>          <cda:preferenceInd value="false"/>        </cda:languageCommunication>      </cda:patient>    </cda:patientRole>  </cda:recordTarget>  
  <cda:author>
    
    <cda:functionCode code="2211" codeSystem="2.16.840.1.113883.2.9.6.2.7" codeSystemName="ISCO-08" displayName="Generalist medical practitioners"/>    
    <cda:time value="20250615130100+0200"/>    <cda:assignedAuthor>
      
      <cda:id root="1.2.40.0.34.99.4613.3.3" extension="1111" assigningAuthorityName="Amadeus Spital"/>      
      <cda:code code="116" codeSystem="1.2.40.0.34.5.160" codeSystemName="ELGA_Fachaerzte" displayName="Fachärztin/Facharzt für Innere Medizin">
        
        <cda:addr>
          <cda:streetName>Währinger Gürtel</cda:streetName>          <cda:houseNumber>18-20</cda:houseNumber>          <cda:postalCode>1090</cda:postalCode>          <cda:city>Wien</cda:city>          <cda:state>Wien</cda:state>          <cda:country>AT</cda:country>        </cda:addr>        
        <cda:telecom use="WP" value="tel:+43.1.3453446.1111"/>        
        <cda:assignedPerson>
          <cda:name>
            <cda:prefix>Dr.</cda:prefix>            <cda:family>Dominik</cda:family>            <cda:given>Matic</cda:given>          </cda:name>        </cda:assignedPerson>        
        <cda:representedOrganization>
          
          <cda:id root="1.2.40.0.34.99.4613" assigningAuthorityName="GDA Index"/>          
          <cda:name>Amadeus Spital</cda:name>          
          <cda:telecom value="tel:+43.1.3453446.0"/>          <cda:telecom value="fax:+43.1.3453446.4589"/>          <cda:telecom value="mailto:info@amadeusspital.at"/>          <cda:telecom value="http://www.amadeusspital.at"/>          
          <cda:addr>
            <cda:streetName>Währinger Gürtel</cda:streetName>            <cda:houseNumber>18-20</cda:houseNumber>            <cda:postalCode>1090</cda:postalCode>            <cda:city>Wien</cda:city>            <cda:state>Wien</cda:state>            <cda:country>AT</cda:country>          </cda:addr>        </cda:representedOrganization>      </cda:code>    </cda:assignedAuthor>  </cda:author>  
  <cda:custodian>
    <cda:assignedCustodian>
      <cda:representedCustodianOrganization>
        
        <cda:id root="1.2.40.0.34.99.4613" assigningAuthorityName="GDA Index"/>        
        <cda:name>Amadeus Spital</cda:name>        
        <cda:telecom value="tel:+43.1.3453446.0"/>        
        <cda:addr>
          <cda:streetName>Währinger Gürtel</cda:streetName>          <cda:houseNumber>18-20</cda:houseNumber>          <cda:postalCode>1090</cda:postalCode>          <cda:city>Wien</cda:city>          <cda:state>Wien</cda:state>          <cda:country>AT</cda:country>        </cda:addr>      </cda:representedCustodianOrganization>    </cda:assignedCustodian>  </cda:custodian>  
  <cda:legalAuthenticator>
    
    <cda:time value="20250615135400+0200"/>    
    <cda:signatureCode code="S"/>    
    <cda:assignedEntity>
      
      <cda:id root="1.2.40.0.34.99.4613.3.3" extension="2222" assigningAuthorityName="Amadeus Spital"/>      
      <cda:addr>
        <cda:streetName>Währinger Gürtel</cda:streetName>        <cda:houseNumber>18-20</cda:houseNumber>        <cda:postalCode>1090</cda:postalCode>        <cda:city>Wien</cda:city>        <cda:state>Wien</cda:state>        <cda:country>AT</cda:country>      </cda:addr>      
      <cda:telecom use="WP" value="tel:+43.1.3453446.2222"/>      
      <cda:assignedPerson>
        
        <cda:name>
          <cda:prefix>Univ.-Prof.Dr.</cda:prefix>          <cda:family>Dom</cda:family>          <cda:given>Turio</cda:given>        </cda:name>      </cda:assignedPerson>      
      <cda:representedOrganization>
        
        <cda:id root="1.2.40.0.34.99.4613" assigningAuthorityName="GDA Index"/>        
        <cda:name>Amadeus Spital</cda:name>        
        <cda:telecom value="tel:+43.1.3453446.0"/>        <cda:telecom value="fax:+43.1.3453446.4589"/>        <cda:telecom value="mailto:info@amadeusspital.at"/>        <cda:telecom value="http://www.amadeusspital.at"/>        
        <cda:addr>
          <cda:streetName>Währinger Gürtel</cda:streetName>          <cda:houseNumber>18-20</cda:houseNumber>          <cda:postalCode>1090</cda:postalCode>          <cda:city>Wien</cda:city>          <cda:state>Wien</cda:state>          <cda:country>AT</cda:country>        </cda:addr>      </cda:representedOrganization>    </cda:assignedEntity>  </cda:legalAuthenticator>  <cda:component>
    <cda:structuredBody>
      <cda:component>
        <cda:section>
          
          <cda:templateId root="1.2.40.0.34.6.0.11.2.139"/>          
          <cda:templateId root="1.3.6.1.4.1.19376.1.9.1.2.2"/>          
          <cda:id root="1.2.3.999" extension="extension" assigningAuthorityName="assigningAuthorityName"/>          
          <cda:code code="61357-0" displayName="Medication Pharmaceutical Advice.Brief" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC">
            
            <cda:title>Pharmazeutische Empfehlung</cda:title>            
            <cda:text> ... Lesbarer Textbereich ... </cda:text>            
            <cda:entry typeCode="DRIV">
               :               <cda:observation classCode="OBS" moodCode="EVN">
                <cda:templateId root="1.2.40.0.34.6.0.11.3.188"/>                <cda:id root="1.2.40.0.10.1.4.3.4.2.4" extension="extension"/>                <cda:code code="CANCEL" codeSystem="1.3.6.1.4.1.19376.1.9.2.1" displayName="Absetzen">
                  
                  <cda:translation code="BRIEFT" codeSystem="1.2.40.0.34.5.40" displayName="Brieftext"/>                </cda:code>                <cda:text>
                  <cda:reference value="--TODO--"/>                </cda:text>                <cda:statusCode code="completed"/>                
              </cda:observation>            </cda:entry>          </cda:code>        </cda:section>      </cda:component>    </cda:structuredBody>  </cda:component></cda:ClinicalDocument>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:ClinicalDocument

@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)

hl7:realmCode

CS

1 … 1

M

Hoheitsbereich des Dokuments.

Fester Wert: @code = AT

(aus Value Set „ELGA_RealmCode“)

@code

1 … 1

F

AT

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.30 Document TypeId (DYNAMIC)

hl7:typeId

II

1 … 1

M

Dokumentformat CDA R2

@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

Fixe OID für alle Dokumente, die in der Governance-Gruppe "eHealth Austria" abgestimmt werden und von einem zentralen Art-Decor-Repository abgeleitet werden (AT-CDA-BBR)."

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.0.1

hl7:templateId

II

1 … 1

M

Root-OID des Implementierungsleitfadens (Dokument-OID). Dient als informative Referenz.

@root

uid

1 … 1

F

1.2.40.0.34.7.8.9.3

hl7:templateId

II

1 … 1

M

Template Spezieller Implementierungsleitfaden ELGA eMedikation v3 Pharmazeutische Empfehlung

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.0.21

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.1 Document Id (DYNAMIC)

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.

@root

uid

1 … 1

R

hl7:code

CE

1 … 1

M

Für die e-Medikations Pharmazeutische Empfehlung ist als Dokumententyp (/ClinicalDocument/code) "61356-2 - Medication pharmaceutical advice.extended Document" und als Dokumentenklasse (/ClinicalDocument/code/translation) "52471-0 - Medications" anzugeben.

↔ Hinweis zum XDS-Mapping:

Das code-Element wird in das XDS-Metadaten-Attribut XDSDocumentEntry.typeCode übernommen.
Das translation-Element wird in das XDS-Metadaten-Attribut XDSDocumentEntry.classCode übernommen.

@codeSystemName

st

0 … 1

F

LOINC

@code

CONF

1 … 1

F

61356-2

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

Medication pharmaceutical advice.extended Document

hl7:translation

CD

1 … 1

M

Fixe Dokumentenklasse "52471-0 - Medications"

@codeSystemName

st

0 … 1

F

LOINC

@code

CONF

1 … 1

F

52471-0

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

Medications

hl7:title

ST

1 … 1

M

Der Titel des Dokuments muss mit "Pharmazeutische Empfehlung" oder "Pharmaceutical advice" beginnen und ist für den lesenden Dokumentempfänger das sichtbare Element. Dieser wird nicht dem Attribut displayName des Elements code entnommen, sondern dem (verpflichtenden) Element title.

sdtc:statusCode

CS

NP

e-Medikations Dokumente sind immer abgeschlossene bzw. "fertige" Dokumente - in diesem Fall erübrigt sich die Angabe eines Status.

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.46 Document TerminologyDate (DYNAMIC)

hl7at:terminologyDate

TS.DATE.FULL

1 … 1

M

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.

Constraint

Das Datum der letzten Terminologie-Aktualisierung MUSS entsprechend klassischer HL7 V3 Notation im Format "YYYYMMDD" angegeben werden.
Beispiel: 20200527

hl7at:formatCode

CD

1 … 1

M

↔ Hinweis zum XDS-Mapping: @code wird in das XDS-Attribut XDSDocumentEntry.formatCode übernommen.

@code

CONF

1 … 1

F

urn:hl7-at:emedat:3.0.0+20250615

@codeSystem

1 … 1

F

1.2.40.0.34.5.37

@displayName

1 … 1

F

HL7 Austria e-Medikation 3.0.0+20250615

hl7at:practiceSettingCode

CD

NP

e-Medikations Dokumente werden keinem Fach zugewiesen - in diesem Fall erübrigt sich die Angabe eines practiceSettingCodes.

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.


	at-cda-bbr-dataelement-11	Erstellungsdatum	Dataset A Allgemeiner Leitfaden

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 Value Set „ELGA_Confidentiality“.


	at-cda-bbr-dataelement-13	Vertraulichkeitscode	Dataset A Allgemeiner Leitfaden

@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:languageCode

CS.LANG

1 … 1

M

Sprachcode des Dokuments.


	at-cda-bbr-dataelement-14	Sprachcode	Dataset A Allgemeiner Leitfaden

@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 ELGA_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.

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.

@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.3.2 Record Target v2 (DYNAMIC)

hl7:recordTarget

1 … 1

M

Komponente für die Patientendaten.


	at-cda-bbr-dataelement-64	Patient	Dataset A Allgemeiner Leitfaden

@typeCode

cs

0 … 1

F

RCT

@contextControlCode

cs

0 … 1

F

OP

hl7:patientRole

1 … 1

M

Patientendaten

@classCode

cs

0 … 1

F

PAT

hl7:id

II

2 … *

R

Patientenidentifikatoren


at-cda-bbr-dataelement-193	EKVK	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-65	LokaleID	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-66	SVNr	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-67	bPK-GH	Dataset A Allgemeiner Leitfaden

Constraint

Hinweis: Die Reihenfolge der id-Elemente MUSS unbedingt eingehalten werden!

* id[1] Identifikation des Patienten im lokalen System (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[@root="1.2.40.0.10.2.1.1.149"] Bereichsspezifisches Personenkennzeichen (0..1 O):
- @root : OID der österreichischen bPK, fester Wert: 1.2.40.0.10.2.1.1.149 (1..1 M)
- @extension : bPK des Patienten: concat(Bereichskürzel, ":", bPK) (Base64,28 Zeichen). Typischerweise bPK-GH (Gesundheit). Kann im Zusammenhang mit E-ID auch andere Bereichskürzel tragen.
Anmerkung : Das bPK dient ausschließlich technisch der Zuordnung der elektronischen Identität und darf daher weder angezeigt werden noch am Ausdruck erscheinen noch in allfälligen Downloads enthalten sein (1..1 M)
- @assigningAuthorityName : Fester Wert: Österreichische Stammzahlenregisterbehörde (0..1 O)

* id[@root="1.2.40.0.34.4.21"] Europäische Krankenversicherungskarte kurz (0..1 O):

- @root: OID der EKVK, fester Wert: 1.2.40.0.34.4.21 (1..1 M)

- @extension: Datenfeld 6 der EKVK

- @assigningAuthorityName : Fester Wert: Nationaler Krankenversicherungsträger (0..1 O)

* id[@root="1.2.40.0.10.1.4.3.8"] Europäische Krankenversicherungskarte lang (0..1 O):
- @root: OID der EKVK, fester Wert: 1.2.40.0.10.1.4.3.8 (1..1 M)

- @extension: Datenfelder der EKVK nach folgender Bildungsvorschrift: concat(Feld 6,"^",Feld 7,"^",Feld 8,"^",Feld 9) wobei Feld 6 "Persönliche Kennnummer" angegeben sein MUSS (1..1 M). Die übrigen Datenfelder sind optional (0..1 O). In Feld 9 MUSS die Datumsangabe im Format YYYMMDD erfolgen.

- @assigningAuthorityName : Fester Wert: Nationaler Krankenversicherungsträger (0..1 O)

Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen.

Beispiel

Europäische Krankenversicherungskarte kurz

Beispiel

Europäische Krankenversicherungskarte lang

hl7:addr

1 … *

R

Adresse des Patienten.

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „NI“ und es dürfen keine Adressteile vorhanden sein.
Es MUSS eine mögliche Adresse unterstützt werden. Spezielle Leitfäden (z.B. Entlassungsbrief Pflege) können es erforderlich machen, dass mehr als eine Adresse unterstützt werden muss.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)


	at-cda-bbr-dataelement-68	Adresse	Dataset A Allgemeiner Leitfaden

@nullFlavor

cs

0 … 1

F

NI

Constraint

Werden mehrere gleichartige address-Elemente strukturiert (z.B. Home, Pflege), MUSS jeweils das Attribut @use angeführt sein.

hl7:telecom

TEL.AT

1 … *

R

Kontakt-Element. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „NI“ und die Attribute „value“ und „use“ wie auch alle inneren Elemente entfallen.


	at-cda-bbr-dataelement-72	Kontaktdaten	Dataset A Allgemeiner Leitfaden

@nullFlavor

cs

0 … 1

F

NI

@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 gleichartige 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.


	at-cda-bbr-dataelement-70	Name	Dataset A Allgemeiner Leitfaden

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Namen-Element (Person)

@use

cs

0 … 1

Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.

Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“.

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

hl7:prefix

ENXP

0 … *

Beliebig viele Präfixe zum Namen, z.B. Akademische Titel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!

@qualifier

cs

0 … 1

Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:family

ENXP

1 … *

M

Mindestens ein Hauptname (Nachname).

@qualifier

cs

0 … 1

Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:given

ENXP

1 … *

M

Mindestens ein Vorname

@qualifier

cs

0 … 1

Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:suffix

ENXP

0 … *

Beliebig viele Suffixe zum Namen

@qualifier

cs

0 … 1

Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

Auswahl

1 … 1

Das "administrative Geschlecht" ist das soziale oder gesellschaftliche Geschlecht ("Gender"). Das administrative Geschlecht ist daher grundsätzlich getrennt von den biologischen Merkmalen der Person zu sehen. Grundsätzlich soll das administrative Geschlecht dem im Zentralen Melderegister (ZMR) eingetragenen Geschlecht entsprechen.

Über ein Translation-Element können weitere Angaben zum Geschlecht gemacht werden, wenn diese abweichend vom administrativen Geschlecht sind, z.B.:

Biologisches Geschlecht
Geschlecht in der Sozialversicherung
Geschlecht für die Stations-/Bettenbelegung im Krankenhaus

Codierung des Geschlechts des Patienten aus ValueSet "ELGA_AdministrativeGender".

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „UNK“ und alle Attribute wie auch alle inneren Elemente entfallen.

Elemente in der Auswahl:

hl7:administrativeGenderCode[not(@nullFlavor)]
hl7:administrativeGenderCode[@nullFlavor='UNK']

hl7:administrativeGenderCode

CE

0 … 1

wo [not(@nullFlavor)]


	at-cda-bbr-dataelement-74	Geschlecht	Dataset A Allgemeiner Leitfaden

@displayName

st

1 … 1

R

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

R

@codeSystemName

st

0 … 1

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC)

hl7:translation

CD

0 … *

R

Über ein Translation-Element können weitere Angaben zum Geschlecht gemacht werden, wenn diese abweichend vom administrativen Geschlecht sind, z.B.: Biologisches Geschlecht, Geschlecht in der Sozialversicherung, Geschlecht für die Stations-/Bettenbelegung im Krankenhaus

@displayName

st

1 … 1

R

Beispiel

Beispiel für eine SNOMED CT Angabe

hl7:administrativeGenderCode

CE

0 … 1

Mittels nullFlavor="UNK" wird "Unbekannt" abgebildet. Dies schließt die Ausprägung "Keine Angabe" mit ein.

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:birthTime

TS.AT.VAR

1 … 1

M

Geburtsdatum des Patienten. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. Das Geburtsdatum des Patienten kann ein Teildatum sein, z. B. nur die Jahreszahl.


	at-cda-bbr-dataelement-75	Geburtsdatum	Dataset A Allgemeiner Leitfaden

sdtc:deceasedInd

BL

0 … 1

R

Kennzeichen, dass die Person verstorben ist. Kann alternativ zum Todesdatum angegeben werden, v.a. wenn der Todeszeitpunkt nicht bekannt ist.


	at-cda-bbr-dataelement-192	Verstorben-Kennzeichen	Dataset A Allgemeiner Leitfaden

sdtc:deceasedTime

TS.AT.TZ

0 … 1

R

Todesdatum der Person.


	at-cda-bbr-dataelement-191	Todesdatum	Dataset A Allgemeiner Leitfaden

hl7:maritalStatusCode

CE

0 … 1

R

Codierung des Familienstands des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“


	at-cda-bbr-dataelement-98	Familienstand	Dataset A Allgemeiner Leitfaden

@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:religiousAffiliationCode

CE

0 … 1

R

Codierung des Religionsbekenntnisses des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“


	at-cda-bbr-dataelement-99	Religionsbekenntnis	Dataset A Allgemeiner Leitfaden

@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!

hl7:ethnicGroupCode

NP

Ethnische Zugehörigkeit des Patienten.

Darf nicht verwendet werden!

hl7:guardian

0 … *

R

Gesetzlicher Vertreter:

Vorsorgebevollmächtigte/r (Bevollmächtigte/r durch Vorsorgevollmacht)
Gewählte/r ErwachsenenvertreterIn
Gesetzliche/r ErwachsenenvertreterIn
Gerichtliche/r ErwachsenenvertreterIn (Sachwalter)

Der gesetzliche Vetreter kann entweder eine Person (guardianPerson) oder eine Organisation (guardianOrganization) sein.

Beim Patienten können optional ein oder mehrere gesetzliche Vetreter angegeben werden. Wenn ein gesetzliche Vetreter bekannt ist, SOLL diese Information auch angegeben werden.


	at-cda-bbr-dataelement-88	Gesetzlicher Vertreter	Dataset A Allgemeiner Leitfaden

@classCode

cs

1 … 1

F

GUARD

@nullFlavor

cs

0 … 1

Verwenden Sie einen nullFlavor, wenn aus bestimmten Gründen keine Informationen vorliegen.

hl7:templateId

II

1 … 1

M

Template id für IHE PCC Patient Contacts.

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.2.4

hl7:code

CE

0 … 1

R

Die Beziehung zwischen dem Patienten und dem gesetzlicher Vertreter kann im Code-Element erfasst werden.

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.38 eHDSIPersonalRelationship (DYNAMIC)

hl7:addr

1 … 1

R

Die Adresse des gesetzlichen Vertreters oder der Organisation ist verpflichtend.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Adressteile vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens einer der nachstehend aufgeführten Adressteile vorhanden sein

Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

@nullFlavor

cs

0 … 1

F

NI

hl7:telecom

TEL.AT

1 … *

R

Beliebig viele Kontaktdaten des gesetzlichen Vertreters als Person oder Organisation.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Kontaktdaten vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens einer der nachstehend aufgeführten Kontaktdaten vorhanden sein

Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.

@nullFlavor

cs

0 … 1

F

NI

@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 gleichartige 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:guardianPerson welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
hl7:guardianPerson welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
hl7:guardianOrganization welches enthält Template 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)

hl7:guardianPerson

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)

hl7:guardianPerson

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)

hl7:guardianOrganization

0 … 1

R

Name des gesetzlichen Vertreters (Organisation)
Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)

hl7:birthplace

0 … 1

R

Geburtsort des Patienten.


	at-cda-bbr-dataelement-76	Geburtsort	Dataset A Allgemeiner Leitfaden

@classCode

cs

0 … 1

F

BIRTHPL

hl7:place

1 … 1

M

Ort

@classCode

cs

0 … 1

F

PLC

@determinerCode

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.2 Address Compilation Minimal v2 (DYNAMIC)
hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:addr

AD

0 … 1

Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional.

Beinhaltet 1.2.40.0.34.6.0.11.9.10.2 Address Compilation Minimal v2 (DYNAMIC)

hl7:addr

AD

0 … 1

Die Adresse des Geburtsorts, struktuiert.
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:languageCommunication

0 … *

R

Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten.


	at-cda-bbr-dataelement-100	Sprachfähigkeit	Dataset A Allgemeiner Leitfaden

hl7:languageCode

CS

1 … 1

M

Sprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen).

In der Klasse languageCommunication können Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform (z.B. gesprochen oder geschrieben) des Patienten angegeben werden.
Dieser Leitfaden schränkt die möglichen Werte für die Sprache auf Werte aus dem Value Set ELGA_HumanLanguage ein.

Die Gebärdensprache ist als eigene Sprache inkl. Ländercode anzugeben, mit der Ergänzung des Länder-/Regional-Codes (z.B. sgn-at), die Ausdrucksweise (MoodCode) wird in diesem Fall nicht angegeben (denn expressed / received signed wären redundant).


	at-cda-bbr-dataelement-101	Sprache	Dataset A Allgemeiner Leitfaden

@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

C

Ausdrucksform der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_LanguageAbilityMode“

@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

Constraint

Bei Strukturierung einer Gebärdensprache ist dieses Element NICHT ERLAUBT, NP [0..0] und MUSS daher komplett entfallen

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC)

hl7:proficiencyLevelCode

CE

0 … 1

R

Grad der Sprachkenntnis in der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“


	at-cda-bbr-dataelement-102	Grad der Sprachkenntnis	Dataset A Allgemeiner Leitfaden

@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:preferenceInd

BL

0 … 1

R

Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.


	at-cda-bbr-dataelement-103	Sprachpräferenz	Dataset A Allgemeiner Leitfaden

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.2 Author v2 (DYNAMIC)

hl7:author

1 … 1

M

Verfasser des Dokuments.

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

1 … 1

M

Internationaler Funktionscode des Verfassers des Dokuments, z.B: „Generalist medical practitioners“, „Specialist medical practitioners“,„Nursing professionals“.

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

F

2.16.840.1.113883.2.9.6.2.7

@codeSystemName

st

1 … 1

F

ISCO-08

@displayName

st

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.1 eHDSIHealthcareProfessionalRole (DYNAMIC)

Auswahl

1 … 1

Der Zeitpunkt, zu 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

wo [not(@nullFlavor)]

hl7:time

TS.AT.TZ

0 … 1

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:assignedAuthor

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software.

ODER Identifikation des/der datenerstellenden Gerätes/Software.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NA“ haben und es dürfen keine anderen Attribute vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens ein Attribut vorhanden sein

@nullFlavor

cs

0 … 1

F

NA

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.

@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:addr

AD

1 … *

R

Angabe der Adresse des Verfassers des Dokuments
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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:assignedPerson welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
hl7:assignedAuthoringDevice welches enthält Template 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC)

hl7:assignedPerson

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)

hl7:assignedAuthoringDevice

0 … 1

Datenerstellende/s Software/Gerät
Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC)

hl7:representedOrganization

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 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.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

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“

Ausnahme: Wenn als Author ein/e Software/Gerät fungiert und keine OID aus dem GDA-I angegeben werden kann, MÜSSEN die Angaben der Organisation des Geräte-/Software-Betreibers oder Herstellers entsprechen.

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.4.2 Custodian v2 (DYNAMIC)

hl7:custodian

1 … 1

M

Verwahrer des Dokuments.


	at-cda-bbr-dataelement-24	Verwahrer	Dataset A Allgemeiner Leitfaden

@typeCode

cs

0 … 1

F

CST

hl7:assignedCustodian

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:representedCustodianOrganization

1 … 1

M

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … *

M

Identifikation des Verwahrers des Dokuments. Wenn dieser im GDA-I angeführt ist, ist die entsprechende OID zu verwenden.
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

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.

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verwahrers des originalen Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.
Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Kontaktdaten vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es müssen Kontaktdaten vorhanden sein.

@value

st

1 … 1

R

@use

set_cs

0 … 1

Bedeutung des angegebenen Kontakts gemäß Value-Set „ELGA_TelecomAddressUse“

@nullFlavor

cs

0 … 1

F

NI

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.2 Address Compilation v2 (DYNAMIC)

Eingefügt

1 … *

M

von 1.2.40.0.34.6.0.11.1.5.2 Legal Authenticator v2 (DYNAMIC)

hl7:legalAuthenticator

1 … *

M

Hauptunterzeichner, Rechtlicher Unterzeichner


	at-cda-bbr-dataelement-1	Rechtlicher Unterzeichner	Dataset A Allgemeiner Leitfaden

@contextControlCode

cs

0 … 1

F

OP

@typeCode

cs

0 … 1

F

LA

hl7:time

TS.AT.TZ

1 … 1

M

Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.


	at-cda-bbr-dataelement-5	Zeitpunkt der Unterzeichnung	Dataset A Allgemeiner Leitfaden

hl7:signatureCode

CS

1 … 1

M

Signaturcode gibt an, dass das Originaldokument unterzeichnet wurde.


	at-cda-bbr-dataelement-6	Signatur	Dataset A Allgemeiner Leitfaden

@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.41.2 Assigned Entity with id, name, addr and telecom v2 (DYNAMIC)

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.1.14 Document Replacement - Related Document (DYNAMIC)

hl7:relatedDocument

0 … 1

R


	at-cda-bbr-dataelement-15	Bezug zu vorgehenden Dokumenten	Dataset A Allgemeiner Leitfaden

@typeCode

cs

1 … 1

R

Art des Bezugs zum Vordokument.

Constraint

Erlaubte @typeCodes:

RPLC - replaces: Das Dokument ersetzt ein existierendes Dokument. Der Status des zu ersetzenden Dokumentes wird auf "deprecated" gesetzt, das ursprüngliche Dokument bleibt aber noch im System als historische Referenz verfügbar.

APND - append: Zusammenhängen von Dokumenten. Dies ist in ELGA bereits über das Einbetten von Dokumenten realisiert.

XFRM - transformed: Das Dokument ist Ergebnis eines Transformationsprozesses, d.h. ist aus einem anderen Originaldokument hervorgegangen.

Hinweis: Die parallele Ablage von CDA-Dokumenten, welche vom Dokumentersteller bereits mit einem Stylesheet zu einem PDF Dokument gerendert wurden, kann mit der XFRM – Transaktion vorgenommen werden. Es ist nicht auszuschließen, dass die Transformation in lokalen Affinity Domains Anwendung findet. Für ELGA ist die Transformation jedoch kein Anwendungsfall.

hl7:parentDocument

1 … 1

M

Vorhergehendes Dokument.

@classCode

cs

0 … 1

F

DOCCLIN

@moodCode

cs

0 … 1

F

EVN

hl7:id

II

1 … 1

M

Dokumenten-Id des vorgehenden Dokuments.

Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

hl7:component

@typeCode

cs

0 … 1

F

COMP

@contextConductionInd

bl

0 … 1

F

true

hl7:structuredBody

@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.139 Pharmazeutische Empfehlung - kodiert (DYNAMIC)

@typeCode

cs

0 … 1

F

COMP

@contextConductionInd

bl

0 … 1

F

true

7.3.1.4 Medikationsliste

Id

1.2.40.0.34.6.0.11.0.23

Gültigkeit ab

2024‑06‑10 15:51:34

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atemed_document_medikationsliste

Bezeichnung

Medikationsliste

Beschreibung

In diesem Dokument werden Inhalte der Dokumente Rezept, Abgaben und Korrekturmeldung (Pharmazeutischen Empfehlung) gemeinsam aufgeführt. Diese Informationen stehen ebenfalls in maschinenlesbarer Form zur Verfügung.

Kontext

Pfadname /

Klassifikation

CDA Document Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 13 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.1.10	Inklusion	Document Realm (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.1.30	Inklusion	Document TypeId (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.1	Inklusion	Document Id (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.46	Inklusion	Document TerminologyDate (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.11	Inklusion	Document Effective Time (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.1.12	Inklusion	Document Confidentiality Code (1.0.2+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.1.13	Inklusion	Document Language (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.15	Inklusion	Document Set Id and Version Number (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.1.3.2	Inklusion	Record Target v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.2.2	Inklusion	Author v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.4.2	Inklusion	Custodian v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.14	Inklusion	Document Replacement - Related Document (1.0.1+20210628)	DYNAMIC
1.2.40.0.34.6.0.11.2.140	Containment	Medikationsliste - kodiert (3.0.0+20250228)	DYNAMIC

Beispiel

<cda:ClinicalDocument>
  
  
  
  <cda:realmCode code="AT"/>  
  <cda:typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>  
  
  <cda:templateId root="1.2.40.0.34.6.0.11.0.1"/>  
  <cda:templateId root="1.2.40.0.34.7.8.9.3"/>  
  <cda:templateId root="1.2.40.0.34.6.0.11.0.23"/>  
  <cda:id root="1.2.40.0.34.99.4613.3.1" extension="123456.1" assigningAuthorityName="Amadeus Spital"/>  <cda:code codeSystemName="LOINC" code="56445-0" codeSystem="2.16.840.1.113883.6.1" displayName="Medication summary Document">
    <cda:translation codeSystemName="LOINC" code="52471-0" codeSystem="2.16.840.1.113883.6.1" displayName="Medications"/>  </cda:code>  <cda:title>Medikationsliste</cda:title>  
  <cda:formatCode code="urn:hl7-at:emedat:3.0.0+20250615" codeSystem="1.2.40.0.34.5.37" displayName="HL7 Austria e-Medikation 3.0.0+20250615"/>  
  <cda:effectiveTime value="20250615063500+0200"/>  
  <cda:confidentialityCode code="N" displayName="normal" codeSystem="2.16.840.1.113883.5.25" codeSystemName="HL7:Confidentiality"/>  
  <cda:languageCode code="de-AT"/>  
  <cda:setId root="1.2.40.0.34.99.4613.3.1" extension="123456" assigningAuthorityName="Amadeus Spital"/>  <cda:versionNumber value="1"/>  
  <cda:recordTarget>
    <cda:patientRole>
      
      <cda:id root="1.2.40.0.34.99.4613.3.2" extension="121212" assigningAuthorityName="Amadeus Spital"/>      
      <cda:id root="1.2.40.0.10.1.4.3.1" extension="1111241261" assigningAuthorityName="Österreichische Sozialversicherung"/>      
      <cda:addr use="HP">
        <cda:streetAddressLine>Musterstraße 13a</cda:streetAddressLine>        <cda:postalCode>7000</cda:postalCode>        <cda:city>Eisenstadt</cda:city>        <cda:state>Burgenland</cda:state>        <cda:country>AT</cda:country>      </cda:addr>      
      <cda:telecom use="H" value="tel:+43.2682.40400"/>      <cda:telecom use="MC" value="tel:+43.664.1234567"/>      <cda:telecom value="mailto:musterfrau@provider.at"/>      <cda:patient>
        
        <cda:name>
          <cda:prefix qualifier="AC">Dr.</cda:prefix>          <cda:given>Maria</cda:given>          <cda:given>Johanna</cda:given>          <cda:family>Musterfrau</cda:family>          <cda:family qualifier="BR">VorDerHeirat</cda:family>          <cda:suffix qualifier="AC">BSc</cda:suffix>        </cda:name>        
        <cda:administrativeGenderCode code="F" displayName="Female" codeSystem="2.16.840.1.113883.5.1" codeSystemName="HL7:AdministrativeGender"/>        
        <cda:birthTime value="19611224"/>        
        <cda:maritalStatusCode code="M" displayName="Married" codeSystem="2.16.840.1.113883.5.2" codeSystemName="HL7:MaritalStatus"/>        
        <cda:religiousAffiliationCode code="101" codeSystem="2.16.840.1.113883.2.16.1.4.1" codeSystemName="HL7.AT:ReligionAustria" displayName="Römisch-Katholisch"/>        
        <cda:birthplace>
          <cda:place>
            <cda:addr>
              <cda:streetAddressLine>Musterstraße 23b</cda:streetAddressLine>              <cda:postalCode>8011</cda:postalCode>              <cda:city>Graz</cda:city>              <cda:state>Steiermark</cda:state>              <cda:country>AT</cda:country>            </cda:addr>          </cda:place>        </cda:birthplace>        
        <cda:languageCommunication>
          <cda:languageCode code="de-AT"/>          <cda:modeCode code="ESP" displayName="Expressed spoken" codeSystem="2.16.840.1.113883.5.60" codeSystemName="HL7:LanguageAbilityMode"/>          <cda:proficiencyLevelCode code="E" displayName="Excellent" codeSystem="2.16.840.1.113883.5.61" codeSystemName="HL7:LanguageAbilityProficiency"/>          <cda:preferenceInd value="false"/>        </cda:languageCommunication>        <cda:languageCommunication>
          <cda:languageCode code="en"/>          <cda:modeCode code="ESP" displayName="Expressed spoken" codeSystem="2.16.840.1.113883.5.60" codeSystemName="HL7:LanguageAbilityMode"/>          <cda:proficiencyLevelCode code="F" displayName="Fair" codeSystem="2.16.840.1.113883.5.61" codeSystemName="HL7:LanguageAbilityProficiency"/>          <cda:preferenceInd value="false"/>        </cda:languageCommunication>      </cda:patient>    </cda:patientRole>  </cda:recordTarget>  
  <cda:author>
    
    <cda:functionCode code="3259" codeSystem="2.16.840.1.113883.2.9.6.2.7" codeSystemName="ISCO-08" displayName="Health associate professionals not elsewhere classified"/>    
    <cda:time value="20250615130100+0200"/>    <cda:assignedAuthor>
      
      <cda:id root="1.2.40.0.34.3.9.107" assigningAuthorityName="e-MedAT"/>      
      <cda:addr nullflavor="NA"/>      
      <cda:telecom nullflavor="NA"/>      
      <cda:assignedAuthoringDevice>
        <cda:manufacturerModelName>Österreichisches e-Medikationsprojekt</cda:manufacturerModelName>        <cda:softwareName>Zentrale Komponente</cda:softwareName>      </cda:assignedAuthoringDevice>      
      <cda:representedOrganization>
        <cda:id root="1.2.40.0.34.3.9.107" assigningAuthorityName="e-MedAT"/>        
        <cda:name>Österreichisches e-Medikationsprojekt</cda:name>        
        <cda:telecom nullflavor="NA"/>        
        <cda:addr>
          <cda:streetName>Kundmanngasse</cda:streetName>          <cda:houseNumber>21</cda:houseNumber>          <cda:postalCode>1030</cda:postalCode>          <cda:city>Wien</cda:city>          <cda:state>Wien</cda:state>          <cda:country>AT</cda:country>        </cda:addr>      </cda:representedOrganization>    </cda:assignedAuthor>  </cda:author>  
  <cda:custodian>
    <cda:assignedCustodian>
      <cda:representedCustodianOrganization>
        
        <cda:id root="1.2.40.0.34.3.9.107" assigningAuthorityName="e-MedAT"/>        
        <cda:name>Österreichisches e-Medikationsprojekt</cda:name>        
        <cda:telecom nullflavor="NA"/>        
        <cda:addr>
          <cda:streetName>Kundmanngasse</cda:streetName>          <cda:houseNumber>21</cda:houseNumber>          <cda:postalCode>1030</cda:postalCode>          <cda:city>Wien</cda:city>          <cda:state>Wien</cda:state>          <cda:country>AT</cda:country>        </cda:addr>      </cda:representedCustodianOrganization>    </cda:assignedCustodian>  </cda:custodian>  
  <cda:documentationOf>
    <cda:serviceEvent>
      <cda:effectiveTime>
        
        <cda:low value="20250411035400+0200"/>        
        <cda:high value="20250615135400+0200"/>      </cda:effectiveTime>    </cda:serviceEvent>  </cda:documentationOf>  <cda:component>
    <cda:structuredBody>
      <cda:component>
        <cda:section>
          <cda:templateId root="1.2.40.0.34.6.0.11.3.189"/>          <cda:id root="1.2.3.999" extension="extension" assigningAuthorityName="assigningAuthorityName"/>          <cda:code code="10160-0" codeSystem="2.16.840.1.113883.6.1" displayName="History of medication use">
            <cda:title>title</cda:title>            <cda:text/>            <cda:entry typeCode="COMP">
              <cda:substanceAdministration classCode="SBADM" moodCode="INT">
                <cda:templateId root="1.2.40.0.34.6.0.11.3.185"/>                <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.3.2"/>                <cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>                <cda:templateId root="2.16.840.1.113883.10.20.1.24"/>                <cda:templateId root="1.3.6.1.4.1.19376.1.9.1.3.6"/>                
                <cda:id root="1.2.3.999" extension="extension"/>                <cda:id root="1.2.3.999" extension="extension"/>                <cda:text>
                  <cda:reference value="--TODO--"/>                </cda:text>                <cda:statusCode code="completed"/>                
                
                <cda:repeatNumber/>                <cda:routeCode/>                
                <cda:consumable typeCode="CSM">
                  <cda:manufacturedProduct classCode="MANU">
                    <cda:templateId root="1.2.40.0.34.6.0.11.3.186"/>                    <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.3.29"/>                    <cda:manufacturedMaterial classCode="MMAT" determinerCode="KIND">
                      <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.3.30"/>                      <cda:code nullFlavor="NA" code="--code--" codeSystem="1.2.40.0.34.4.16">
                        
                        <cda:translation code="--code--" codeSystem="1.2.40.0.34.4.17"/>                      </cda:code>                      <cda:name nullFlavor="NA">name</cda:name>                      <cda:formCode nullFlavor="NI"/>                      <cda:asContent classCode="CONT">
                        <cda:quantity unit="%" value="1">
                          <cda:translation>
                            
                          </cda:translation>                        </cda:quantity>                        <cda:containerPackagedProduct classCode="CONT" determinerCode="KIND">
                          <cda:formCode nullFlavor="NI"/>                        </cda:containerPackagedProduct>                      </cda:asContent>                      <cda:ingredient classCode="ACTI">
                        <cda:ingredientSubstance classCode="MMAT" determinerCode="KIND">
                          <cda:code>
                            
                            <cda:translation/>                          </cda:code>                          <cda:name>name</cda:name>                        </cda:ingredientSubstance>                      </cda:ingredient>                    </cda:manufacturedMaterial>                  </cda:manufacturedProduct>                </cda:consumable>                
                
                
                <cda:entryRelationship typeCode="COMP">
                  <cda:supply classCode="SPLY" moodCode="RQO">
                    <cda:independentInd value="false"/>                    <cda:quantity value="1" unit="1"/>                  </cda:supply>                </cda:entryRelationship>                <cda:entryRelationship typeCode="SUBJ" inversionInd="true">
                  
                </cda:entryRelationship>                <cda:entryRelationship typeCode="SUBJ" inversionInd="true">
                  
                </cda:entryRelationship>                
                <cda:entryRelationship typeCode="SUBJ" inversionInd="true">
                  
                </cda:entryRelationship>                
              </cda:substanceAdministration>            </cda:entry>            <cda:entry typeCode="COMP">
              <cda:supply classCode="SPLY" moodCode="EVN">
                <cda:templateId root="1.2.40.0.34.6.0.11.3.187"/>                <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.3.3"/>                <cda:templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.3"/>                <cda:templateId root="2.16.840.1.113883.10.20.1.34"/>                <cda:id root="1.2.3.999" extension="extension"/>                <cda:id root="1.2.3.999" extension="extension"/>                <cda:code code="FFC" codeSystem="2.16.840.1.113883.5.4" displayName="First Fill - Complete">
                  
                </cda:code>                <cda:text>
                  <cda:reference value="--TODO--"/>                </cda:text>                <cda:quantity value="1" unit="1"/>                <cda:product typeCode="PRD">
                  <cda:manufacturedProduct classCode="MANU">
                    <cda:templateId root="1.2.40.0.34.6.0.11.3.186"/>                    <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.3.29"/>                    <cda:manufacturedMaterial classCode="MMAT" determinerCode="KIND">
                      <cda:templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.3.30"/>                      <cda:code nullFlavor="NA" code="--code--" codeSystem="1.2.40.0.34.4.16">
                        
                        <cda:translation code="--code--" codeSystem="1.2.40.0.34.4.17"/>                      </cda:code>                      <cda:name nullFlavor="NA">name</cda:name>                      <cda:formCode nullFlavor="NI"/>                      <cda:asContent classCode="CONT">
                        <cda:quantity unit="%" value="1">
                          <cda:translation>
                            
                          </cda:translation>                        </cda:quantity>                        <cda:containerPackagedProduct classCode="CONT" determinerCode="KIND">
                          <cda:formCode nullFlavor="NI"/>                        </cda:containerPackagedProduct>                      </cda:asContent>                      <cda:ingredient classCode="ACTI">
                        <cda:ingredientSubstance classCode="MMAT" determinerCode="KIND">
                          <cda:code>
                            
                            <cda:translation/>                          </cda:code>                          <cda:name>name</cda:name>                        </cda:ingredientSubstance>                      </cda:ingredient>                    </cda:manufacturedMaterial>                  </cda:manufacturedProduct>                </cda:product>                <cda:performer nullFlavor="NI" typeCode="PRF">
                  <cda:time value="20250615"/>                  <cda:assignedEntity>
                    
                  </cda:assignedEntity>                </cda:performer>                
                <cda:entryRelationship typeCode="REFR">
                  <cda:substanceAdministration classCode="SBADM" moodCode="INT">
                    <cda:id root="1.2.40.0.10.1.4.3.4.2.2" extension="extension"/>                    <cda:consumable nullFlavor="NA"/>                  </cda:substanceAdministration>                </cda:entryRelationship>                
                
                <cda:entryRelationship typeCode="SUBJ" inversionInd="true">
                  
                </cda:entryRelationship>                <cda:entryRelationship typeCode="SUBJ" inversionInd="true">
                  
                </cda:entryRelationship>                
                <cda:entryRelationship typeCode="COMP">
                  
                </cda:entryRelationship>                <cda:entryRelationship typeCode="COMP">
                  <cda:act classCode="ACT" moodCode="EVN">
                    <cda:code code="SUBST" codeSystem="2.16.840.1.113883.5.6"/>                  </cda:act>                </cda:entryRelationship>                
              </cda:supply>            </cda:entry>            <cda:entry typeCode="COMP">
              <cda:observation classCode="OBS" moodCode="EVN">
                <cda:templateId root="1.2.40.0.34.6.0.11.3.188"/>                <cda:id root="1.2.40.0.10.1.4.3.4.2.4" extension="extension"/>                <cda:code code="CANCEL" codeSystem="1.3.6.1.4.1.19376.1.9.2.1" displayName="Absetzen">
                  
                  <cda:translation code="BRIEFT" codeSystem="1.2.40.0.34.5.40" displayName="Brieftext"/>                </cda:code>                <cda:text>
                  <cda:reference value="--TODO--"/>                </cda:text>                <cda:statusCode code="completed"/>                
              </cda:observation>            </cda:entry>          </cda:code>        </cda:section>      </cda:component>    </cda:structuredBody>  </cda:component></cda:ClinicalDocument>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:ClinicalDocument

@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)

hl7:realmCode

CS

1 … 1

M

Hoheitsbereich des Dokuments.

Fester Wert: @code = AT

(aus Value Set „ELGA_RealmCode“)

@code

1 … 1

F

AT

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.30 Document TypeId (DYNAMIC)

hl7:typeId

II

1 … 1

M

Dokumentformat CDA R2

@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

Fixe OID für alle Dokumente, die in der Governance-Gruppe "eHealth Austria" abgestimmt werden und von einem zentralen Art-Decor-Repository abgeleitet werden (AT-CDA-BBR)."

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.0.1

hl7:templateId

II

1 … 1

M

Root-OID des Implementierungsleitfadens (Dokument-OID). Dient als informative Referenz.

@root

uid

1 … 1

F

1.2.40.0.34.7.8.9.3

hl7:templateId

II

1 … 1

M

Template Spezieller Implementierungsleitfaden ELGA eMedikation v3 Medikationsliste

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.0.23

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.1 Document Id (DYNAMIC)

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.

@root

uid

1 … 1

R

hl7:code

CE

1 … 1

M

Für die e-Medikations Medikationsliste ist als Dokumententyp (/ClinicalDocument/code) "56445-0 - Medication summary Document" und als Dokumentenklasse (/ClinicalDocument/code/translation) "52471-0 - Medications" anzugeben.

↔ Hinweis zum XDS-Mapping:

Das code-Element wird in das XDS-Metadaten-Attribut XDSDocumentEntry.typeCode übernommen.
Das translation-Element wird in das XDS-Metadaten-Attribut XDSDocumentEntry.classCode übernommen.

@codeSystemName

st

0 … 1

F

LOINC

@code

CONF

1 … 1

F

56445-0

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

Medication summary Document

hl7:translation

CD

1 … 1

M

Fixe Dokumentenklasse "52471-0 - Medications"

@codeSystemName

st

0 … 1

F

LOINC

@code

CONF

1 … 1

F

52471-0

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

Medications

hl7:title

ST

1 … 1

M

Der Titel des Dokuments muss mit "Medikationsliste" oder "Medication list" beginnen und ist für den lesenden Dokumentempfänger das sichtbare Element. Dieser wird nicht dem Attribut displayName des Elements code entnommen, sondern dem (verpflichtenden) Element title.

sdtc:statusCode

CS

NP

e-Medikations Dokumente sind immer abgeschlossene bzw. "fertige" Dokumente - in diesem Fall erübrigt sich die Angabe eines Status.

Eingefügt

0 … 1

C

von 1.2.40.0.34.6.0.11.1.46 Document TerminologyDate (DYNAMIC)

Constraint

Wenn Medikations Entries in einer Medikationsliste verwendet werden und die Medikationsliste kein terminologyDate im Header definiert hat, ist eine Verwendung des codeSystemVersion Attributes bei jedem Code Element der Medikations Entries verpflichtend!

hl7at:terminologyDate

TS.DATE.FULL

0 … 1

C

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.

Constraint

Das Datum der letzten Terminologie-Aktualisierung MUSS entsprechend klassischer HL7 V3 Notation im Format "YYYYMMDD" angegeben werden.
Beispiel: 20200527

hl7at:formatCode

CD

1 … 1

M

↔ Hinweis zum XDS-Mapping: @code wird in das XDS-Attribut XDSDocumentEntry.formatCode übernommen.

@code

CONF

1 … 1

F

urn:hl7-at:emedat:3.0.0+20250615

@codeSystem

1 … 1

F

1.2.40.0.34.5.37

@displayName

1 … 1

F

HL7 Austria e-Medikation 3.0.0+20250615

hl7at:practiceSettingCode

CD

NP

e-Medikations Dokumente werden keinem Fach zugewiesen - in diesem Fall erübrigt sich die Angabe eines practiceSettingCodes.

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.


	at-cda-bbr-dataelement-11	Erstellungsdatum	Dataset A Allgemeiner Leitfaden

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 Value Set „ELGA_Confidentiality“.


	at-cda-bbr-dataelement-13	Vertraulichkeitscode	Dataset A Allgemeiner Leitfaden

@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:languageCode

CS.LANG

1 … 1

M

Sprachcode des Dokuments.


	at-cda-bbr-dataelement-14	Sprachcode	Dataset A Allgemeiner Leitfaden

@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 ELGA_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.

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.

@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.3.2 Record Target v2 (DYNAMIC)

hl7:recordTarget

1 … 1

M

Komponente für die Patientendaten.


	at-cda-bbr-dataelement-64	Patient	Dataset A Allgemeiner Leitfaden

@typeCode

cs

0 … 1

F

RCT

@contextControlCode

cs

0 … 1

F

OP

hl7:patientRole

1 … 1

M

Patientendaten

@classCode

cs

0 … 1

F

PAT

hl7:id

II

2 … *

R

Patientenidentifikatoren


at-cda-bbr-dataelement-193	EKVK	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-65	LokaleID	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-66	SVNr	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-67	bPK-GH	Dataset A Allgemeiner Leitfaden

Constraint

Hinweis: Die Reihenfolge der id-Elemente MUSS unbedingt eingehalten werden!

* id[1] Identifikation des Patienten im lokalen System (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[@root="1.2.40.0.10.2.1.1.149"] Bereichsspezifisches Personenkennzeichen (0..1 O):
- @root : OID der österreichischen bPK, fester Wert: 1.2.40.0.10.2.1.1.149 (1..1 M)
- @extension : bPK des Patienten: concat(Bereichskürzel, ":", bPK) (Base64,28 Zeichen). Typischerweise bPK-GH (Gesundheit). Kann im Zusammenhang mit E-ID auch andere Bereichskürzel tragen.
Anmerkung : Das bPK dient ausschließlich technisch der Zuordnung der elektronischen Identität und darf daher weder angezeigt werden noch am Ausdruck erscheinen noch in allfälligen Downloads enthalten sein (1..1 M)
- @assigningAuthorityName : Fester Wert: Österreichische Stammzahlenregisterbehörde (0..1 O)

* id[@root="1.2.40.0.34.4.21"] Europäische Krankenversicherungskarte kurz (0..1 O):

- @root: OID der EKVK, fester Wert: 1.2.40.0.34.4.21 (1..1 M)

- @extension: Datenfeld 6 der EKVK

- @assigningAuthorityName : Fester Wert: Nationaler Krankenversicherungsträger (0..1 O)

* id[@root="1.2.40.0.10.1.4.3.8"] Europäische Krankenversicherungskarte lang (0..1 O):
- @root: OID der EKVK, fester Wert: 1.2.40.0.10.1.4.3.8 (1..1 M)

- @extension: Datenfelder der EKVK nach folgender Bildungsvorschrift: concat(Feld 6,"^",Feld 7,"^",Feld 8,"^",Feld 9) wobei Feld 6 "Persönliche Kennnummer" angegeben sein MUSS (1..1 M). Die übrigen Datenfelder sind optional (0..1 O). In Feld 9 MUSS die Datumsangabe im Format YYYMMDD erfolgen.

- @assigningAuthorityName : Fester Wert: Nationaler Krankenversicherungsträger (0..1 O)

Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen.

Beispiel

Europäische Krankenversicherungskarte kurz

Beispiel

Europäische Krankenversicherungskarte lang

hl7:addr

1 … *

R

Adresse des Patienten.

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „NI“ und es dürfen keine Adressteile vorhanden sein.
Es MUSS eine mögliche Adresse unterstützt werden. Spezielle Leitfäden (z.B. Entlassungsbrief Pflege) können es erforderlich machen, dass mehr als eine Adresse unterstützt werden muss.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)


	at-cda-bbr-dataelement-68	Adresse	Dataset A Allgemeiner Leitfaden

@nullFlavor

cs

0 … 1

F

NI

Constraint

Werden mehrere gleichartige address-Elemente strukturiert (z.B. Home, Pflege), MUSS jeweils das Attribut @use angeführt sein.

hl7:telecom

TEL.AT

1 … *

R

Kontakt-Element. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „NI“ und die Attribute „value“ und „use“ wie auch alle inneren Elemente entfallen.


	at-cda-bbr-dataelement-72	Kontaktdaten	Dataset A Allgemeiner Leitfaden

@nullFlavor

cs

0 … 1

F

NI

@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 gleichartige 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.


	at-cda-bbr-dataelement-70	Name	Dataset A Allgemeiner Leitfaden

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Namen-Element (Person)

@use

cs

0 … 1

Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.

Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“.

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

hl7:prefix

ENXP

0 … *

Beliebig viele Präfixe zum Namen, z.B. Akademische Titel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!

@qualifier

cs

0 … 1

Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:family

ENXP

1 … *

M

Mindestens ein Hauptname (Nachname).

@qualifier

cs

0 … 1

Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:given

ENXP

1 … *

M

Mindestens ein Vorname

@qualifier

cs

0 … 1

Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:suffix

ENXP

0 … *

Beliebig viele Suffixe zum Namen

@qualifier

cs

0 … 1

Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

Auswahl

1 … 1

Das "administrative Geschlecht" ist das soziale oder gesellschaftliche Geschlecht ("Gender"). Das administrative Geschlecht ist daher grundsätzlich getrennt von den biologischen Merkmalen der Person zu sehen. Grundsätzlich soll das administrative Geschlecht dem im Zentralen Melderegister (ZMR) eingetragenen Geschlecht entsprechen.

Über ein Translation-Element können weitere Angaben zum Geschlecht gemacht werden, wenn diese abweichend vom administrativen Geschlecht sind, z.B.:

Biologisches Geschlecht
Geschlecht in der Sozialversicherung
Geschlecht für die Stations-/Bettenbelegung im Krankenhaus

Codierung des Geschlechts des Patienten aus ValueSet "ELGA_AdministrativeGender".

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „UNK“ und alle Attribute wie auch alle inneren Elemente entfallen.

Elemente in der Auswahl:

hl7:administrativeGenderCode[not(@nullFlavor)]
hl7:administrativeGenderCode[@nullFlavor='UNK']

hl7:administrativeGenderCode

CE

0 … 1

wo [not(@nullFlavor)]


	at-cda-bbr-dataelement-74	Geschlecht	Dataset A Allgemeiner Leitfaden

@displayName

st

1 … 1

R

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

R

@codeSystemName

st

0 … 1

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC)

hl7:translation

CD

0 … *

R

Über ein Translation-Element können weitere Angaben zum Geschlecht gemacht werden, wenn diese abweichend vom administrativen Geschlecht sind, z.B.: Biologisches Geschlecht, Geschlecht in der Sozialversicherung, Geschlecht für die Stations-/Bettenbelegung im Krankenhaus

@displayName

st

1 … 1

R

Beispiel

Beispiel für eine SNOMED CT Angabe

hl7:administrativeGenderCode

CE

0 … 1

Mittels nullFlavor="UNK" wird "Unbekannt" abgebildet. Dies schließt die Ausprägung "Keine Angabe" mit ein.

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:birthTime

TS.AT.VAR

1 … 1

M

Geburtsdatum des Patienten. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. Das Geburtsdatum des Patienten kann ein Teildatum sein, z. B. nur die Jahreszahl.


	at-cda-bbr-dataelement-75	Geburtsdatum	Dataset A Allgemeiner Leitfaden

sdtc:deceasedInd

BL

0 … 1

R

Kennzeichen, dass die Person verstorben ist. Kann alternativ zum Todesdatum angegeben werden, v.a. wenn der Todeszeitpunkt nicht bekannt ist.


	at-cda-bbr-dataelement-192	Verstorben-Kennzeichen	Dataset A Allgemeiner Leitfaden

sdtc:deceasedTime

TS.AT.TZ

0 … 1

R

Todesdatum der Person.


	at-cda-bbr-dataelement-191	Todesdatum	Dataset A Allgemeiner Leitfaden

hl7:maritalStatusCode

CE

0 … 1

R

Codierung des Familienstands des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“


	at-cda-bbr-dataelement-98	Familienstand	Dataset A Allgemeiner Leitfaden

@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:religiousAffiliationCode

CE

0 … 1

R

Codierung des Religionsbekenntnisses des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“


	at-cda-bbr-dataelement-99	Religionsbekenntnis	Dataset A Allgemeiner Leitfaden

@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!

hl7:ethnicGroupCode

NP

Ethnische Zugehörigkeit des Patienten.

Darf nicht verwendet werden!

hl7:guardian

0 … *

R

Gesetzlicher Vertreter:

Vorsorgebevollmächtigte/r (Bevollmächtigte/r durch Vorsorgevollmacht)
Gewählte/r ErwachsenenvertreterIn
Gesetzliche/r ErwachsenenvertreterIn
Gerichtliche/r ErwachsenenvertreterIn (Sachwalter)

Der gesetzliche Vetreter kann entweder eine Person (guardianPerson) oder eine Organisation (guardianOrganization) sein.

Beim Patienten können optional ein oder mehrere gesetzliche Vetreter angegeben werden. Wenn ein gesetzliche Vetreter bekannt ist, SOLL diese Information auch angegeben werden.


	at-cda-bbr-dataelement-88	Gesetzlicher Vertreter	Dataset A Allgemeiner Leitfaden

@classCode

cs

1 … 1

F

GUARD

@nullFlavor

cs

0 … 1

Verwenden Sie einen nullFlavor, wenn aus bestimmten Gründen keine Informationen vorliegen.

hl7:templateId

II

1 … 1

M

Template id für IHE PCC Patient Contacts.

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.2.4

hl7:code

CE

0 … 1

R

Die Beziehung zwischen dem Patienten und dem gesetzlicher Vertreter kann im Code-Element erfasst werden.

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.38 eHDSIPersonalRelationship (DYNAMIC)

hl7:addr

1 … 1

R

Die Adresse des gesetzlichen Vertreters oder der Organisation ist verpflichtend.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Adressteile vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens einer der nachstehend aufgeführten Adressteile vorhanden sein

Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

@nullFlavor

cs

0 … 1

F

NI

hl7:telecom

TEL.AT

1 … *

R

Beliebig viele Kontaktdaten des gesetzlichen Vertreters als Person oder Organisation.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Kontaktdaten vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens einer der nachstehend aufgeführten Kontaktdaten vorhanden sein

Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.

@nullFlavor

cs

0 … 1

F

NI

@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 gleichartige 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:guardianPerson welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
hl7:guardianPerson welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
hl7:guardianOrganization welches enthält Template 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)

hl7:guardianPerson

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)

hl7:guardianPerson

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)

hl7:guardianOrganization

0 … 1

R

Name des gesetzlichen Vertreters (Organisation)
Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)

hl7:birthplace

0 … 1

R

Geburtsort des Patienten.


	at-cda-bbr-dataelement-76	Geburtsort	Dataset A Allgemeiner Leitfaden

@classCode

cs

0 … 1

F

BIRTHPL

hl7:place

1 … 1

M

Ort

@classCode

cs

0 … 1

F

PLC

@determinerCode

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.2 Address Compilation Minimal v2 (DYNAMIC)
hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:addr

AD

0 … 1

Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional.

Beinhaltet 1.2.40.0.34.6.0.11.9.10.2 Address Compilation Minimal v2 (DYNAMIC)

hl7:addr

AD

0 … 1

Die Adresse des Geburtsorts, struktuiert.
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:languageCommunication

0 … *

R

Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten.


	at-cda-bbr-dataelement-100	Sprachfähigkeit	Dataset A Allgemeiner Leitfaden

hl7:languageCode

CS

1 … 1

M

Sprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen).

In der Klasse languageCommunication können Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform (z.B. gesprochen oder geschrieben) des Patienten angegeben werden.
Dieser Leitfaden schränkt die möglichen Werte für die Sprache auf Werte aus dem Value Set ELGA_HumanLanguage ein.

Die Gebärdensprache ist als eigene Sprache inkl. Ländercode anzugeben, mit der Ergänzung des Länder-/Regional-Codes (z.B. sgn-at), die Ausdrucksweise (MoodCode) wird in diesem Fall nicht angegeben (denn expressed / received signed wären redundant).


	at-cda-bbr-dataelement-101	Sprache	Dataset A Allgemeiner Leitfaden

@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

C

Ausdrucksform der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_LanguageAbilityMode“

@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

Constraint

Bei Strukturierung einer Gebärdensprache ist dieses Element NICHT ERLAUBT, NP [0..0] und MUSS daher komplett entfallen

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC)

hl7:proficiencyLevelCode

CE

0 … 1

R

Grad der Sprachkenntnis in der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“


	at-cda-bbr-dataelement-102	Grad der Sprachkenntnis	Dataset A Allgemeiner Leitfaden

@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:preferenceInd

BL

0 … 1

R

Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.


	at-cda-bbr-dataelement-103	Sprachpräferenz	Dataset A Allgemeiner Leitfaden

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.2 Author v2 (DYNAMIC)

hl7:author

1 … 1

M

Verfasser des Dokuments.

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

1 … 1

M

Internationaler Funktionscode des Verfassers des Dokuments, z.B: „Generalist medical practitioners“, „Specialist medical practitioners“,„Nursing professionals“.

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

F

2.16.840.1.113883.2.9.6.2.7

@codeSystemName

st

1 … 1

F

ISCO-08

@displayName

st

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.1 eHDSIHealthcareProfessionalRole (DYNAMIC)

Auswahl

1 … 1

Der Zeitpunkt, zu 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

wo [not(@nullFlavor)]

hl7:time

TS.AT.TZ

0 … 1

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:assignedAuthor

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software.

ODER Identifikation des/der datenerstellenden Gerätes/Software.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NA“ haben und es dürfen keine anderen Attribute vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens ein Attribut vorhanden sein

@nullFlavor

cs

0 … 1

F

NA

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.

@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:addr

AD

1 … *

R

Angabe der Adresse des Verfassers des Dokuments
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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:assignedPerson welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
hl7:assignedAuthoringDevice welches enthält Template 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC)

hl7:assignedPerson

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)

hl7:assignedAuthoringDevice

0 … 1

Datenerstellende/s Software/Gerät
Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC)

hl7:representedOrganization

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 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.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

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“

Ausnahme: Wenn als Author ein/e Software/Gerät fungiert und keine OID aus dem GDA-I angegeben werden kann, MÜSSEN die Angaben der Organisation des Geräte-/Software-Betreibers oder Herstellers entsprechen.

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.1.4.2 Custodian v2 (DYNAMIC)

hl7:custodian

1 … 1

M

Verwahrer des Dokuments.


	at-cda-bbr-dataelement-24	Verwahrer	Dataset A Allgemeiner Leitfaden

@typeCode

cs

0 … 1

F

CST

hl7:assignedCustodian

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:representedCustodianOrganization

1 … 1

M

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … *

M

Identifikation des Verwahrers des Dokuments. Wenn dieser im GDA-I angeführt ist, ist die entsprechende OID zu verwenden.
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

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.

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verwahrers des originalen Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.
Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Kontaktdaten vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es müssen Kontaktdaten vorhanden sein.

@value

st

1 … 1

R

@use

set_cs

0 … 1

Bedeutung des angegebenen Kontakts gemäß Value-Set „ELGA_TelecomAddressUse“

@nullFlavor

cs

0 … 1

F

NI

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.2 Address Compilation v2 (DYNAMIC)

hl7:legalAuthenticator

NP

Im Gegensatz zu den anderen Dokumententypen der e-Medikation kann die Medikationsliste als Zusammenstellung der anderen Dokumente keinen Unterzeichner haben!

hl7:documentationOf

1 … 1

M

Zeitspanne vom ersten bis letztem Eintrag

Beispiel

hl7:serviceEvent

1 … 1

M

hl7:effectiveTime

IVL_TS

1 … 1

M

hl7:low

TS.AT.TZ

1 … 1

M

Beginn mit Datum des ersten Eintrags der Medikationsliste

@nullFlavor

cs

0 … 1

CONF

@nullFlavor MUSS "NA" sein

hl7:high

TS.AT.TZ

1 … 1

M

Ende mit Datum des letzten Eintrags der Medikationsliste

@nullFlavor

cs

0 … 1

CONF

@nullFlavor MUSS "NA" sein

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.1.14 Document Replacement - Related Document (DYNAMIC)

hl7:relatedDocument

0 … 1

R


	at-cda-bbr-dataelement-15	Bezug zu vorgehenden Dokumenten	Dataset A Allgemeiner Leitfaden

@typeCode

cs

1 … 1

R

Art des Bezugs zum Vordokument.

Constraint

Erlaubte @typeCodes:

RPLC - replaces: Das Dokument ersetzt ein existierendes Dokument. Der Status des zu ersetzenden Dokumentes wird auf "deprecated" gesetzt, das ursprüngliche Dokument bleibt aber noch im System als historische Referenz verfügbar.

APND - append: Zusammenhängen von Dokumenten. Dies ist in ELGA bereits über das Einbetten von Dokumenten realisiert.

XFRM - transformed: Das Dokument ist Ergebnis eines Transformationsprozesses, d.h. ist aus einem anderen Originaldokument hervorgegangen.

Hinweis: Die parallele Ablage von CDA-Dokumenten, welche vom Dokumentersteller bereits mit einem Stylesheet zu einem PDF Dokument gerendert wurden, kann mit der XFRM – Transaktion vorgenommen werden. Es ist nicht auszuschließen, dass die Transformation in lokalen Affinity Domains Anwendung findet. Für ELGA ist die Transformation jedoch kein Anwendungsfall.

hl7:parentDocument

1 … 1

M

Vorhergehendes Dokument.

@classCode

cs

0 … 1

F

DOCCLIN

@moodCode

cs

0 … 1

F

EVN

hl7:id

II

1 … 1

M

Dokumenten-Id des vorgehenden Dokuments.

Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

hl7:component

@typeCode

cs

0 … 1

F

COMP

@contextConductionInd

bl

0 … 1

F

true

hl7:structuredBody

@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.140 Medikationsliste - kodiert (DYNAMIC)

@typeCode

cs

0 … 1

F

COMP

@contextConductionInd

bl

0 … 1

F

true

7.3.2 Header Level Templates

Die Header Level Templates wurden großteils aus dem bestehenden "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente" übernommen. Diese sind unter Allgemeiner Leitfaden - Kapitel Administrative Daten (CDA Header) - Dokumentenstruktur zu finden.

Die Header-Element welche spezifisch für die e-Medikation v3 angepasst wurden sind folgende:

7.3.2.1 Record Target v2

Id

1.2.40.0.34.6.0.11.1.3.2

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑22 10:42:20

Status

Entwurf

Versions-Label

2.0.0+20250228

Name

atcdabbr_header_RecordTarget_v2

Bezeichnung

Record Target v2

Beschreibung

Diese Version ist zu dem eHDSI RecordTarget (https://art-decor.ehdsi.eu/art-decor/decor-templates--epsos-?id=2.16.840.1.113883.3.1937.777.11.10.100&effectiveDate=dynamic) kompatibel.

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.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 20 Konzepte

Id	Name	Datensatz
at-cda-bbr-dataelement-100	Sprachfähigkeit	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-101	Sprache	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-102	Grad der Sprachkenntnis	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-103	Sprachpräferenz	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-191	Todesdatum	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-192	Verstorben-Kennzeichen	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-193	EKVK	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-64	Patient	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-65	LokaleID	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-66	SVNr	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-67	bPK-GH	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-68	Adresse	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-70	Name	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-72	Kontaktdaten	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-74	Geschlecht	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-75	Geburtsdatum	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-76	Geburtsort	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-88	Gesetzlicher Vertreter	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-98	Familienstand	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-99	Religionsbekenntnis	Dataset A Allgemeiner Leitfaden

Benutzt

Benutzt 5 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.25.2	Containment	Address Compilation v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.11	Inklusion	Person Name Compilation G2 M (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.9.12	Containment	Person Name Compilation G1 M (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.9.27	Containment	Organization Name Compilation (1.0.1+20210628)	DYNAMIC
1.2.40.0.34.6.0.11.9.10.2	Containment	Address Compilation Minimal v2 (2.0.0+20250228)	DYNAMIC

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:recordTarget

Komponente für die Patientendaten.


	at-cda-bbr-dataelement-64	Patient	Dataset A Allgemeiner Leitfaden

@typeCode

cs

0 … 1

F

RCT

@contextControlCode

cs

0 … 1

F

OP

hl7:patientRole

1 … 1

M

Patientendaten

@classCode

cs

0 … 1

F

PAT

hl7:id

II

2 … *

R

Patientenidentifikatoren


at-cda-bbr-dataelement-193	EKVK	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-65	LokaleID	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-66	SVNr	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-67	bPK-GH	Dataset A Allgemeiner Leitfaden

Constraint

Hinweis: Die Reihenfolge der id-Elemente MUSS unbedingt eingehalten werden!

* id[1] Identifikation des Patienten im lokalen System (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[@root="1.2.40.0.10.2.1.1.149"] Bereichsspezifisches Personenkennzeichen (0..1 O):
- @root : OID der österreichischen bPK, fester Wert: 1.2.40.0.10.2.1.1.149 (1..1 M)
- @extension : bPK des Patienten: concat(Bereichskürzel, ":", bPK) (Base64,28 Zeichen). Typischerweise bPK-GH (Gesundheit). Kann im Zusammenhang mit E-ID auch andere Bereichskürzel tragen.
Anmerkung : Das bPK dient ausschließlich technisch der Zuordnung der elektronischen Identität und darf daher weder angezeigt werden noch am Ausdruck erscheinen noch in allfälligen Downloads enthalten sein (1..1 M)
- @assigningAuthorityName : Fester Wert: Österreichische Stammzahlenregisterbehörde (0..1 O)

* id[@root="1.2.40.0.34.4.21"] Europäische Krankenversicherungskarte kurz (0..1 O):

- @root: OID der EKVK, fester Wert: 1.2.40.0.34.4.21 (1..1 M)

- @extension: Datenfeld 6 der EKVK

- @assigningAuthorityName : Fester Wert: Nationaler Krankenversicherungsträger (0..1 O)

* id[@root="1.2.40.0.10.1.4.3.8"] Europäische Krankenversicherungskarte lang (0..1 O):
- @root: OID der EKVK, fester Wert: 1.2.40.0.10.1.4.3.8 (1..1 M)

- @extension: Datenfelder der EKVK nach folgender Bildungsvorschrift: concat(Feld 6,"^",Feld 7,"^",Feld 8,"^",Feld 9) wobei Feld 6 "Persönliche Kennnummer" angegeben sein MUSS (1..1 M). Die übrigen Datenfelder sind optional (0..1 O). In Feld 9 MUSS die Datumsangabe im Format YYYMMDD erfolgen.

- @assigningAuthorityName : Fester Wert: Nationaler Krankenversicherungsträger (0..1 O)

Grundsätzlich sind die Vorgaben gemäß „Identifikations-Elemente“ zu befolgen.

Beispiel

Europäische Krankenversicherungskarte kurz

Beispiel

Europäische Krankenversicherungskarte lang

hl7:addr

1 … *

R

Adresse des Patienten.

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „NI“ und es dürfen keine Adressteile vorhanden sein.
Es MUSS eine mögliche Adresse unterstützt werden. Spezielle Leitfäden (z.B. Entlassungsbrief Pflege) können es erforderlich machen, dass mehr als eine Adresse unterstützt werden muss.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)


	at-cda-bbr-dataelement-68	Adresse	Dataset A Allgemeiner Leitfaden

@nullFlavor

cs

0 … 1

F

NI

Constraint

Werden mehrere gleichartige address-Elemente strukturiert (z.B. Home, Pflege), MUSS jeweils das Attribut @use angeführt sein.

hl7:telecom

TEL.AT

1 … *

R

Kontakt-Element. Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „NI“ und die Attribute „value“ und „use“ wie auch alle inneren Elemente entfallen.


	at-cda-bbr-dataelement-72	Kontaktdaten	Dataset A Allgemeiner Leitfaden

@nullFlavor

cs

0 … 1

F

NI

@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 gleichartige 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.


	at-cda-bbr-dataelement-70	Name	Dataset A Allgemeiner Leitfaden

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Namen-Element (Person)

@use

cs

0 … 1

Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.

Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“.

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

hl7:prefix

ENXP

0 … *

Beliebig viele Präfixe zum Namen, z.B. Akademische Titel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!

@qualifier

cs

0 … 1

Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:family

ENXP

1 … *

M

Mindestens ein Hauptname (Nachname).

@qualifier

cs

0 … 1

Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:given

ENXP

1 … *

M

Mindestens ein Vorname

@qualifier

cs

0 … 1

Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:suffix

ENXP

0 … *

Beliebig viele Suffixe zum Namen

@qualifier

cs

0 … 1

Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

Auswahl

1 … 1

Das "administrative Geschlecht" ist das soziale oder gesellschaftliche Geschlecht ("Gender"). Das administrative Geschlecht ist daher grundsätzlich getrennt von den biologischen Merkmalen der Person zu sehen. Grundsätzlich soll das administrative Geschlecht dem im Zentralen Melderegister (ZMR) eingetragenen Geschlecht entsprechen.

Über ein Translation-Element können weitere Angaben zum Geschlecht gemacht werden, wenn diese abweichend vom administrativen Geschlecht sind, z.B.:

Biologisches Geschlecht
Geschlecht in der Sozialversicherung
Geschlecht für die Stations-/Bettenbelegung im Krankenhaus

Codierung des Geschlechts des Patienten aus ValueSet "ELGA_AdministrativeGender".

Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „UNK“ und alle Attribute wie auch alle inneren Elemente entfallen.

Elemente in der Auswahl:

hl7:administrativeGenderCode[not(@nullFlavor)]
hl7:administrativeGenderCode[@nullFlavor='UNK']

hl7:administrativeGenderCode

CE

0 … 1

wo [not(@nullFlavor)]


	at-cda-bbr-dataelement-74	Geschlecht	Dataset A Allgemeiner Leitfaden

@displayName

st

1 … 1

R

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

R

@codeSystemName

st

0 … 1

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.4 ELGA_AdministrativeGender (DYNAMIC)

hl7:translation

CD

0 … *

R

Über ein Translation-Element können weitere Angaben zum Geschlecht gemacht werden, wenn diese abweichend vom administrativen Geschlecht sind, z.B.: Biologisches Geschlecht, Geschlecht in der Sozialversicherung, Geschlecht für die Stations-/Bettenbelegung im Krankenhaus

@displayName

st

1 … 1

R

Beispiel

Beispiel für eine SNOMED CT Angabe

hl7:administrativeGenderCode

CE

0 … 1

Mittels nullFlavor="UNK" wird "Unbekannt" abgebildet. Dies schließt die Ausprägung "Keine Angabe" mit ein.

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:birthTime

TS.AT.VAR

1 … 1

M

Geburtsdatum des Patienten. Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen. Das Geburtsdatum des Patienten kann ein Teildatum sein, z. B. nur die Jahreszahl.


	at-cda-bbr-dataelement-75	Geburtsdatum	Dataset A Allgemeiner Leitfaden

sdtc:deceasedInd

BL

0 … 1

R

Kennzeichen, dass die Person verstorben ist. Kann alternativ zum Todesdatum angegeben werden, v.a. wenn der Todeszeitpunkt nicht bekannt ist.


	at-cda-bbr-dataelement-192	Verstorben-Kennzeichen	Dataset A Allgemeiner Leitfaden

sdtc:deceasedTime

TS.AT.TZ

0 … 1

R

Todesdatum der Person.


	at-cda-bbr-dataelement-191	Todesdatum	Dataset A Allgemeiner Leitfaden

hl7:maritalStatusCode

CE

0 … 1

R

Codierung des Familienstands des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“


	at-cda-bbr-dataelement-98	Familienstand	Dataset A Allgemeiner Leitfaden

@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:religiousAffiliationCode

CE

0 … 1

R

Codierung des Religionsbekenntnisses des Patienten.
Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“


	at-cda-bbr-dataelement-99	Religionsbekenntnis	Dataset A Allgemeiner Leitfaden

@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!

hl7:ethnicGroupCode

NP

Ethnische Zugehörigkeit des Patienten.

Darf nicht verwendet werden!

hl7:guardian

0 … *

R

Gesetzlicher Vertreter:

Vorsorgebevollmächtigte/r (Bevollmächtigte/r durch Vorsorgevollmacht)
Gewählte/r ErwachsenenvertreterIn
Gesetzliche/r ErwachsenenvertreterIn
Gerichtliche/r ErwachsenenvertreterIn (Sachwalter)

Der gesetzliche Vetreter kann entweder eine Person (guardianPerson) oder eine Organisation (guardianOrganization) sein.

Beim Patienten können optional ein oder mehrere gesetzliche Vetreter angegeben werden. Wenn ein gesetzliche Vetreter bekannt ist, SOLL diese Information auch angegeben werden.


	at-cda-bbr-dataelement-88	Gesetzlicher Vertreter	Dataset A Allgemeiner Leitfaden

@classCode

cs

1 … 1

F

GUARD

@nullFlavor

cs

0 … 1

Verwenden Sie einen nullFlavor, wenn aus bestimmten Gründen keine Informationen vorliegen.

hl7:templateId

II

1 … 1

M

Template id für IHE PCC Patient Contacts.

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.2.4

hl7:code

CE

0 … 1

R

Die Beziehung zwischen dem Patienten und dem gesetzlicher Vertreter kann im Code-Element erfasst werden.

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.38 eHDSIPersonalRelationship (DYNAMIC)

hl7:addr

1 … 1

R

Die Adresse des gesetzlichen Vertreters oder der Organisation ist verpflichtend.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Adressteile vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens einer der nachstehend aufgeführten Adressteile vorhanden sein

Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

@nullFlavor

cs

0 … 1

F

NI

hl7:telecom

TEL.AT

1 … *

R

Beliebig viele Kontaktdaten des gesetzlichen Vertreters als Person oder Organisation.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Kontaktdaten vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens einer der nachstehend aufgeführten Kontaktdaten vorhanden sein

Grundsätzlich sind die Vorgaben gemäß „Kontaktdaten-Element“ zu befolgen.

@nullFlavor

cs

0 … 1

F

NI

@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 gleichartige 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:guardianPerson welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC)
hl7:guardianPerson welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
hl7:guardianOrganization welches enthält Template 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)

hl7:guardianPerson

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)

hl7:guardianPerson

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)

hl7:guardianOrganization

0 … 1

R

Name des gesetzlichen Vertreters (Organisation)
Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC)

hl7:birthplace

0 … 1

R

Geburtsort des Patienten.


	at-cda-bbr-dataelement-76	Geburtsort	Dataset A Allgemeiner Leitfaden

@classCode

cs

0 … 1

F

BIRTHPL

hl7:place

1 … 1

M

Ort

@classCode

cs

0 … 1

F

PLC

@determinerCode

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.2 Address Compilation Minimal v2 (DYNAMIC)
hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:addr

AD

0 … 1

Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional.

Beinhaltet 1.2.40.0.34.6.0.11.9.10.2 Address Compilation Minimal v2 (DYNAMIC)

hl7:addr

AD

0 … 1

Die Adresse des Geburtsorts, struktuiert.
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:languageCommunication

0 … *

R

Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten.


	at-cda-bbr-dataelement-100	Sprachfähigkeit	Dataset A Allgemeiner Leitfaden

hl7:languageCode

CS

1 … 1

M

Sprache, die vom Patienten zu einem bestimmten Grad beherrscht wird (geschrieben oder gesprochen).

In der Klasse languageCommunication können Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform (z.B. gesprochen oder geschrieben) des Patienten angegeben werden.
Dieser Leitfaden schränkt die möglichen Werte für die Sprache auf Werte aus dem Value Set ELGA_HumanLanguage ein.

Die Gebärdensprache ist als eigene Sprache inkl. Ländercode anzugeben, mit der Ergänzung des Länder-/Regional-Codes (z.B. sgn-at), die Ausdrucksweise (MoodCode) wird in diesem Fall nicht angegeben (denn expressed / received signed wären redundant).


	at-cda-bbr-dataelement-101	Sprache	Dataset A Allgemeiner Leitfaden

@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

C

Ausdrucksform der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_LanguageAbilityMode“

@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

Constraint

Bei Strukturierung einer Gebärdensprache ist dieses Element NICHT ERLAUBT, NP [0..0] und MUSS daher komplett entfallen

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.175 ELGA_LanguageAbilityMode (DYNAMIC)

hl7:proficiencyLevelCode

CE

0 … 1

R

Grad der Sprachkenntnis in der Sprache.
Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“


	at-cda-bbr-dataelement-102	Grad der Sprachkenntnis	Dataset A Allgemeiner Leitfaden

@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:preferenceInd

BL

0 … 1

R

Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.


	at-cda-bbr-dataelement-103	Sprachpräferenz	Dataset A Allgemeiner Leitfaden

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"

7.3.2.2 Author v2

Id

1.2.40.0.34.6.0.11.1.2.2

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑23 09:50:28

Status

Entwurf

Versions-Label

2.0.0+20250228

Name

atcdabbr_header_Author_v2

Bezeichnung

Author v2

Beschreibung

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.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 4 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.25.2	Containment	Address Compilation v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.11	Containment	Person Name Compilation G2 M (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.9.18	Containment	Device Compilation (1.0.2+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.9.5.2	Containment	Organization Compilation with id, name, addr and telecom v2 (2.0.0+20250228)	DYNAMIC

Beziehung

Adaptation: Template 1.2.40.0.34.6.0.11.1.2 Author (2023‑04‑06 15:23:19)

ref

at-cda-bbr-

Spezialisierung: Template 1.2.40.0.34.6.0.11.1.2 Author (2021‑08‑24 08:35:56)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.1.2 Author (2021‑02‑18 12:40:27)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.1.2 Author (2019‑02‑13 09:50:17)

ref

at-cda-bbr-

Beispiel

Person als Author

Beispiel

Gerät als Author

Item

DT

Kard

Konf

Beschreibung

Label

hl7:author

Verfasser des Dokuments.

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

1 … 1

M

Internationaler Funktionscode des Verfassers des Dokuments, z.B: „Generalist medical practitioners“, „Specialist medical practitioners“,„Nursing professionals“.

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

F

2.16.840.1.113883.2.9.6.2.7

@codeSystemName

st

1 … 1

F

ISCO-08

@displayName

st

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.1 eHDSIHealthcareProfessionalRole (DYNAMIC)

Auswahl

1 … 1

Der Zeitpunkt, zu 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

wo [not(@nullFlavor)]

hl7:time

TS.AT.TZ

0 … 1

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:assignedAuthor

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software.

ODER Identifikation des/der datenerstellenden Gerätes/Software.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NA“ haben und es dürfen keine anderen Attribute vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens ein Attribut vorhanden sein

@nullFlavor

cs

0 … 1

F

NA

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.

@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:addr

AD

1 … *

R

Angabe der Adresse des Verfassers des Dokuments
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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:assignedPerson welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)
hl7:assignedAuthoringDevice welches enthält Template 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC)

hl7:assignedPerson

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)

hl7:assignedAuthoringDevice

0 … 1

Datenerstellende/s Software/Gerät
Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC)

hl7:representedOrganization

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 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.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

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“

Ausnahme: Wenn als Author ein/e Software/Gerät fungiert und keine OID aus dem GDA-I angegeben werden kann, MÜSSEN die Angaben der Organisation des Geräte-/Software-Betreibers oder Herstellers entsprechen.

7.3.2.3 Author v2 Prescriber

Id

1.2.40.0.34.6.0.11.1.2.2.1

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑23 14:54:10

Status

Entwurf

Versions-Label

2.0.0+20250228

Name

atcdabbr_header_Author_v2_Prescriber

Bezeichnung

Author v2 Prescriber

Beschreibung

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 bei einem Rezept mit seinen Verordnungen aufgrund der EHDSI Kompatibilität kein "Dokument-erstellendes Gerät" sein!

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.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 3 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.25.2	Containment	Address Compilation v2 (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.11	Containment	Person Name Compilation G2 M (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.9.5.2	Containment	Organization Compilation with id, name, addr and telecom v2 (2.0.0+20250228)	DYNAMIC

Beziehung

Adaptation: Template 1.2.40.0.34.6.0.11.1.2 Author (2023‑04‑06 15:23:19)

ref

at-cda-bbr-

Spezialisierung: Template 1.2.40.0.34.6.0.11.1.2 Author (2021‑08‑24 08:35:56)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.1.2 Author (2021‑02‑18 12:40:27)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.1.2 Author (2019‑02‑13 09:50:17)

ref

at-cda-bbr-

Beispiel

Person als Author

Item

DT

Kard

Konf

Beschreibung

Label

hl7:author

Verfasser des Dokuments.

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

1 … 1

M

Internationaler Funktionscode des Verfassers des Dokuments, z.B: „Generalist medical practitioners“, „Specialist medical practitioners“,„Nursing professionals“.

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

F

2.16.840.1.113883.2.9.6.2.7

@codeSystemName

st

1 … 1

F

ISCO-08

@displayName

st

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.1 eHDSIHealthcareProfessionalRole (DYNAMIC)

Auswahl

1 … 1

Der Zeitpunkt, zu 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

wo [not(@nullFlavor)]

hl7:time

TS.AT.TZ

0 … 1

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:assignedAuthor

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software.

ODER Identifikation des/der datenerstellenden Gerätes/Software.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NA“ haben und es dürfen keine anderen Attribute vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens ein Attribut vorhanden sein

@nullFlavor

cs

0 … 1

F

NA

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.

@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:addr

AD

1 … *

R

Angabe der Adresse des Verfassers des Dokuments
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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.

hl7:assignedPerson

1 … 1

M

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)

hl7:representedOrganization

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 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.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

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“

7.3.2.4 Custodian v2

Id

1.2.40.0.34.6.0.11.1.4.2

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑23 15:24:16

Status

Entwurf

Versions-Label

2.0.0+20250228

Name

atcdabbr_header_Custodian_v2

Bezeichnung

Custodian v2

Beschreibung

Der "Verwahrer" des Dokuments stellt die Organisation dar, von der das Dokument stammt und die für die Aufbewahrung und Verwaltung des ORIGINALEN Dokuments verantwortlich ist. Jedes CDA-Dokument hat genau einen Custodian. Der Custodian entspricht der Definition von Verwaltertätigkeit ("Stewardship") von CDA.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
at-cda-bbr-dataelement-24	Verwahrer	Dataset A Allgemeiner Leitfaden

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.25.2	Containment	Address Compilation v2 (2.0.0+20250228)	DYNAMIC

Beziehung

Adaptation: Template 1.2.40.0.34.6.0.11.1.4 Custodian (2021‑10‑13 14:05:15)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.1.4 Custodian (2021‑02‑19 10:33:30)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.1.4 Custodian (2019‑02‑26 11:28:24)

ref

at-cda-bbr-

Beispiel

<custodian typeCode="CST">
  <assignedCustodian classCode="ASSIGNED">
    <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">
      
      <id root="1.2.3.999" extension="7601234567890"/>      <name>Amadeus Spital</name>      <telecom use="WP" value="tel:+43.(0)50.55460-0"/>      <telecom use="MC" value="tel:+43.(0)676.55461"/>      <addr>
        
      </addr>    </representedCustodianOrganization>  </assignedCustodian></custodian>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:custodian

Verwahrer des Dokuments.


	at-cda-bbr-dataelement-24	Verwahrer	Dataset A Allgemeiner Leitfaden

@typeCode

cs

0 … 1

F

CST

hl7:assignedCustodian

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:representedCustodianOrganization

1 … 1

M

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … *

M

Identifikation des Verwahrers des Dokuments. Wenn dieser im GDA-I angeführt ist, ist die entsprechende OID zu verwenden.
Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

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.

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verwahrers des originalen Dokuments (Organisation). Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.
Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine Kontaktdaten vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es müssen Kontaktdaten vorhanden sein.

@value

st

1 … 1

R

@use

set_cs

0 … 1

Bedeutung des angegebenen Kontakts gemäß Value-Set „ELGA_TelecomAddressUse“

@nullFlavor

cs

0 … 1

F

NI

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.2 Address Compilation v2 (DYNAMIC)

7.3.2.5 Legal Authenticator v2

Id

1.2.40.0.34.6.0.11.1.5.2

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑23 15:45:33

Status

Entwurf

Versions-Label

2.0.0+20250228

Name

atcdabbr_header_LegalAuthenticator_v2

Bezeichnung

Legal Authenticator v2

Beschreibung

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

↔ Hinweis zum XDS-Mapping:

legalAuthenticator

ACHTUNG

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 3 Konzepte

Id	Name	Datensatz
at-cda-bbr-dataelement-1	Rechtlicher Unterzeichner	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-5	Zeitpunkt der Unterzeichnung	Dataset A Allgemeiner Leitfaden
at-cda-bbr-dataelement-6	Signatur	Dataset A Allgemeiner Leitfaden

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.41.2	Containment	Assigned Entity with id, name, addr and telecom v2 (2.0.0+20250228)	DYNAMIC

Beziehung

Adaptation: Template 1.2.40.0.34.6.0.11.1.5 Legal Authenticator (2021‑02‑19 11:10:59)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.1.5 Legal Authenticator (2019‑03‑04 11:41:57)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.11.20006 HeaderLegalAuthenticator (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:legalAuthenticator

Hauptunterzeichner, Rechtlicher Unterzeichner


	at-cda-bbr-dataelement-1	Rechtlicher Unterzeichner	Dataset A Allgemeiner Leitfaden

@contextControlCode

cs

0 … 1

F

OP

@typeCode

cs

0 … 1

F

LA

hl7:time

TS.AT.TZ

1 … 1

M

Der Zeitpunkt, an dem das Dokument unterzeichnet wurde.


	at-cda-bbr-dataelement-5	Zeitpunkt der Unterzeichnung	Dataset A Allgemeiner Leitfaden

hl7:signatureCode

CS

1 … 1

M

Signaturcode gibt an, dass das Originaldokument unterzeichnet wurde.


	at-cda-bbr-dataelement-6	Signatur	Dataset A Allgemeiner Leitfaden

@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.41.2 Assigned Entity with id, name, addr and telecom v2 (DYNAMIC)

Die Header-Element welche in der e-Medikation direkt aus dem Allgemeinen Leitfaden verwendet worden sind, sind folgende:

7.3.2.6 Document Confidentiality Code

Id

1.2.40.0.34.6.0.11.1.12

ref

at-cda-bbr-

Gültigkeit ab

2023‑03‑24 09:30:46

Andere Versionen mit dieser Id:

atcdabbr_header_DocumentConfidentialityCode vom 2021‑06‑28 13:39:30
atcdabbr_header_DocumentConfidentialityCode vom 2021‑02‑19 10:35:04
atcdabbr_header_DocumentConfidentialityCode vom 2019‑03‑04 12:35:46

Status

Aktiv

Versions-Label

1.0.2+20230717

Name

atcdabbr_header_DocumentConfidentialityCode

Bezeichnung

Document Confidentiality Code

Beschreibung

Grundsätzlich stellt CDA Informationen zum Vertraulichkeitsstatus eines Dokuments zur Verfügung, um Anwendungssysteme bei der Verwaltung des Zugriffs auf sensible Daten zu unterstützen. Der Vertraulichkeitsstatus kann für das gesamte Dokument oder für bestimmte Teile des Dokuments gelten. Der im Header angegebene Wert gilt für das gesamte Dokument, es sei denn, er wird durch einen verschachtelten Wert überschrieben. Der tatsächliche Zugriff auf das Dokument muss von der übergeordneten Infrastrukturschicht geregelt werden.

↔ Hinweis zum XDS-Mapping: Dieses Element spiegelt sich im XDS-Attribut confidentialityCode wider. Für ELGA wird dieses fix auf "N" gesetzt.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
at-cda-bbr-dataelement-13	Vertraulichkeitscode	Dataset A Allgemeiner Leitfaden

Beziehung

Version: Template 1.2.40.0.34.6.0.11.1.12 Document Confidentiality Code (2021‑06‑28 13:39:30)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.1.12 Document Confidentiality Code (2021‑02‑19 10:35:04)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.1.12 Document Confidentiality Code (2019‑03‑04 12:35:46)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.11.90009 CD confidentialityCode (2013‑11‑07)

ref

elgabbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:confidentialityCode

CE

Vertraulichkeitscode des Dokuments aus Value Set „ELGA_Confidentiality“.


	at-cda-bbr-dataelement-13	Vertraulichkeitscode	Dataset A Allgemeiner Leitfaden

@codeSystemName

st

1 … 1

F

HL7:Confidentiality

Constraint

Für ELGA-Dokumente ist ausschließlich "N" erlaubt!

7.3.2.7 Document Effective Time

Id

1.2.40.0.34.6.0.11.1.11

ref

at-cda-bbr-

Gültigkeit ab

2023‑04‑11 10:22:55

Andere Versionen mit dieser Id:

atcdabbr_header_DocumentEffectiveTime vom 2021‑02‑19 10:35:26
atcdabbr_header_DocumentEffectiveTime vom 2019‑02‑12 16:30:12

Status

Aktiv

Versions-Label

1.0.1+20230717

Name

atcdabbr_header_DocumentEffectiveTime

Bezeichnung

Document Effective Time

Beschreibung

Dokumentiert das Erstellungsdatum bzw. den Zeitpunkt, an dem das Dokument inhaltlich fertiggestellt wurde. Damit ist jenes Datum gemeint, welches normalerweise im Briefkopf eines Schriftstückes angegeben wird (z.B. Wien, am …). Das Erstellungsdatum des Dokuments MUSS NICHT 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).

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
at-cda-bbr-dataelement-11	Erstellungsdatum	Dataset A Allgemeiner Leitfaden

Beziehung

Version: Template 1.2.40.0.34.6.0.11.1.11 Document Effective Time (2021‑02‑19 10:35:26)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.1.11 Document Effective Time (2019‑02‑12 16:30:12)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.11.90008 CD effectiveTime (2016‑07‑21)

ref

elgabbr-

Beispiel

Nur Datum: Zeitpunkt als Datum (ohne Zeit) im Format YYYYMMDD

Beispiel

Datum, Zeit und Zeitzone: Zeitpunkt als Datum mit Zeit und Zeitzone im Format YYYYMMDDhhmmss[+/-]HHMM

Item

DT

Kard

Konf

Beschreibung

Label

hl7:effectiveTime

TS.AT.TZ

R

Relevantes Datum des Dokuments.
Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.


	at-cda-bbr-dataelement-11	Erstellungsdatum	Dataset A Allgemeiner Leitfaden

7.3.2.8 Document Id

Id

1.2.40.0.34.6.0.11.1.1

ref

at-cda-bbr-

Gültigkeit ab

2021‑02‑19 10:36:12

Andere Versionen mit dieser Id:

atcdabbr_header_DocumentId vom 2019‑02‑18 11:06:14

Status

Aktiv

Versions-Label

1.0.0+20210219

Name

atcdabbr_header_DocumentId

Bezeichnung

Document Id

Beschreibung

Die Dokumenten-Id eines CDA-Dokuments ist ein eindeutiger Instanzidentifikator, der das Dokument weltweit und für alle Zeit eindeutig identifiziert. Ein CDA-Dokument hat genau eine Id.

↔ Hinweis zum XDS-Mapping: Dieses Element wird ins XDS-Attribut uniqueId gemappt.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.6.0.11.1.1 Document Id (2019‑02‑18 11:06:14)

ref

at-cda-bbr-

Beispiel

Strukturbeispiel (mit Extension)

Beispiel

Strukturbeispiel (ohne Extension)

Item

DT

Kard

Konf

Beschreibung

Label

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.

@root

uid

1 … 1

R

7.3.2.9 Document Language

Id

1.2.40.0.34.6.0.11.1.13

ref

at-cda-bbr-

Gültigkeit ab

2021‑02‑19 10:36:53

Andere Versionen mit dieser Id:

atcdabbr_header_DocumentLanguage vom 2019‑02‑12 14:08:58

Status

Aktiv

Versions-Label

1.0.0+20210219

Name

atcdabbr_header_DocumentLanguage

Bezeichnung

Document Language

Beschreibung

Gibt die Sprache des Dokuments an, sowohl in Inhalts- oder Attributwerten. Die Angabe erfolgt im Sprachcode-Attribut gemäß IETF RFC 3066 (Internet Engineering Task Force RFC 3066 for the Identification of Languages, ed. H. Alvestrand 1995).

Es enthält mindestens 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.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
at-cda-bbr-dataelement-14	Sprachcode	Dataset A Allgemeiner Leitfaden

Beziehung

Version: Template 1.2.40.0.34.6.0.11.1.13 Document Language (2019‑02‑12 14:08:58)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.11.90010 CD languageCode (2013‑11‑07)

ref

elgabbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:languageCode

CS.LANG

Sprachcode des Dokuments.


	at-cda-bbr-dataelement-14	Sprachcode	Dataset A Allgemeiner Leitfaden

@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 ELGA_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.

7.3.2.10 Document Realm

Id

1.2.40.0.34.6.0.11.1.10

ref

at-cda-bbr-

Gültigkeit ab

2023‑03‑24 09:21:27

Andere Versionen mit dieser Id:

atcdabbr_header_DocumentRealm vom 2021‑02‑19 10:44:57
atcdabbr_header_DocumentRealm vom 2019‑02‑12 13:35:45

Status

Aktiv

Versions-Label

1.0.1+20230717

Name

atcdabbr_header_DocumentRealm

Bezeichnung

Document Realm

Beschreibung

Hoheitsbereich des Dokuments.

Dieses Element kennzeichnet, dass das Dokument aus dem Hoheitsbereich Österreich (bzw. Bereich der HL7 Affiliate Austria, Code „AT“) stammt.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.6.0.11.1.10 Document Realm (2021‑02‑19 10:44:57)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.1.10 Document Realm (2019‑02‑12 13:35:45)

ref

at-cda-bbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:realmCode

CS

R

Hoheitsbereich des Dokuments.

Fester Wert: @code = AT

(aus Value Set „ELGA_RealmCode“)

@code

1 … 1

F

AT

7.3.2.11 Document Replacement - Related Document

Id

1.2.40.0.34.6.0.11.1.14

ref

at-cda-bbr-

Gültigkeit ab

2021‑06‑28 13:42:15

Andere Versionen mit dieser Id:

atcdabbr_header_DocumentReplacementRelatedDocument vom 2021‑02‑19 10:45:45
atcdabbr_header_DocumentReplacementRelatedDocument vom 2019‑02‑28 14:06:32

Status

Aktiv

Versions-Label

1.0.1+20210628

Name

atcdabbr_header_DocumentReplacementRelatedDocument

Bezeichnung

Document Replacement - Related Document

Beschreibung

Der Bezug zu vorgehenden Dokumenten wird durch die relatedDocument-Beziehung und die ParentDocument-Klasse, zusammen mit setId und versionNumber aus der ClinicalDocument-Klasse, spezifiziert.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
at-cda-bbr-dataelement-15	Bezug zu vorgehenden Dokumenten	Dataset A Allgemeiner Leitfaden

Beziehung

Version: Template 1.2.40.0.34.6.0.11.1.14 Document Replacement - Related Document (2021‑02‑19 10:45:45)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.1.14 Document Replacement - Related Document (2019‑02‑28 14:06:32)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.11.20011 HeaderRelatedDocument (2014‑12‑06)

ref

elgabbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:relatedDocument


	at-cda-bbr-dataelement-15	Bezug zu vorgehenden Dokumenten	Dataset A Allgemeiner Leitfaden

@typeCode

cs

1 … 1

R

Art des Bezugs zum Vordokument.

Constraint

Erlaubte @typeCodes:

RPLC - replaces: Das Dokument ersetzt ein existierendes Dokument. Der Status des zu ersetzenden Dokumentes wird auf "deprecated" gesetzt, das ursprüngliche Dokument bleibt aber noch im System als historische Referenz verfügbar.

APND - append: Zusammenhängen von Dokumenten. Dies ist in ELGA bereits über das Einbetten von Dokumenten realisiert.

XFRM - transformed: Das Dokument ist Ergebnis eines Transformationsprozesses, d.h. ist aus einem anderen Originaldokument hervorgegangen.

Hinweis: Die parallele Ablage von CDA-Dokumenten, welche vom Dokumentersteller bereits mit einem Stylesheet zu einem PDF Dokument gerendert wurden, kann mit der XFRM – Transaktion vorgenommen werden. Es ist nicht auszuschließen, dass die Transformation in lokalen Affinity Domains Anwendung findet. Für ELGA ist die Transformation jedoch kein Anwendungsfall.

hl7:parentDocument

1 … 1

M

Vorhergehendes Dokument.

@classCode

cs

0 … 1

F

DOCCLIN

@moodCode

cs

0 … 1

F

EVN

hl7:id

II

1 … 1

M

Dokumenten-Id des vorgehenden Dokuments.

Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

7.3.2.12 Document Set Id and Version Number

Id

1.2.40.0.34.6.0.11.1.15

ref

at-cda-bbr-

Gültigkeit ab

2021‑02‑19 10:57:14

Andere Versionen mit dieser Id:

atcdabbr_header_DocumentSetIdAndVersionNumber vom 2019‑02‑12 14:48:59

Status

Aktiv

Versions-Label

1.0.0+20210219

Name

atcdabbr_header_DocumentSetIdAndVersionNumber

Bezeichnung

Document Set Id and Version Number

Beschreibung

Versionierung des Dokuments.
Der CDA-Header repräsentiert Beziehungen zu anderen Dokumenten mit Referenz auf die Dokumenten-Identifikation. Mittels der Attribute setId und versionNumber kann eine Versionskennung des Dokuments erreicht werden.

Für ELGA-CDA-Dokumente MÜSSEN immer beide Elemente angegeben werden.

Anhänge oder Ersetzungen von Vordokumenten MÜSSEN ebenfalls diese zusätzlichen Angaben enthalten. Der genaue Zusammenhang zwischen diesen Attributen finden Sie im Kapitel „Bezug zu vorgehenden Dokumenten“.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.6.0.11.1.15 Document Set Id and Version Number (2019‑02‑12 14:48:59)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.11.90007 SetId VersionNumber (2015‑09‑18)

ref

elgabbr-

Beispiel

Beispiel für die 1.Version eines Dokuments

<placeholder>
<id root="1.2.40.0.34.99.111.1.1" extension="AAAAAAAAAAAAAAA" assigningAuthorityName="KH Eisenstadt"/> <setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZ" assigningAuthorityName="KH Eisenstadt"/> <versionNumber value="1"/></placeholder>

Beispiel

Beispiel für die 2.Version eines Dokuments

<placeholder>
<id root="1.2.40.0.34.99.111.1.1" extension="BBBBBBBBBBBBBBB" assigningAuthorityName="KH Eisenstadt"/> <setId root="1.2.40.0.34.99.111.1.1" extension="ZZZZZZZZZZZZZZZ" assigningAuthorityName="KH Eisenstadt"/> <versionNumber value="2"/></placeholder>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:setId

II

R

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.

hl7:versionNumber

INT.NONNEG

R

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.

@value

int

1 … 1

R

Versionsnummer als positive ganze Zahl.

7.3.2.13 Document TerminologyDate

Id

1.2.40.0.34.6.0.11.1.46

ref

at-cda-bbr-

Gültigkeit ab

2021‑02‑19 11:04:44

Andere Versionen mit dieser Id:

atcdabbr_header_DocumentTerminologyDate vom 2020‑07‑08 11:49:46

Status

Aktiv

Versions-Label

1.0.0+20210219

Name

atcdabbr_header_DocumentTerminologyDate

Bezeichnung

Document TerminologyDate

Beschreibung

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.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.6.0.11.1.46 Document TerminologyDate (2020‑07‑08 11:49:46)

ref

at-cda-bbr-

Beispiel

Strukturbeispiel Entlassungsbrief

<hl7at:terminologyDate value="20190606"/>

Item

DT

Kard

Konf

Beschreibung

Label

hl7at:terminologyDate

TS.DATE.FULL

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.

Constraint

Das Datum der letzten Terminologie-Aktualisierung MUSS entsprechend klassischer HL7 V3 Notation im Format "YYYYMMDD" angegeben werden.
Beispiel: 20200527

7.3.2.14 Document TypeId

Id

1.2.40.0.34.6.0.11.1.30

ref

at-cda-bbr-

Gültigkeit ab

2021‑02‑19 11:05:29

Andere Versionen mit dieser Id:

atcdabbr_header_DocumentTypeId vom 2019‑05‑13 10:27:22

Status

Aktiv

Versions-Label

1.0.0+20210219

Name

atcdabbr_header_DocumentTypeId

Bezeichnung

Document TypeId

Beschreibung

Dieses Element kennzeichnet, dass das Dokument im Format CDA R2 vorliegt.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.6.0.11.1.30 Document TypeId (2019‑05‑13 10:27:22)

ref

at-cda-bbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:typeId

II

R

Dokumentformat CDA R2

@root

uid

1 … 1

F

2.16.840.1.113883.1.3

@extension

st

1 … 1

F

POCD_HD000040

7.3.3 Section Level Templates

7.3.3.1 Rezept - kodiert

Id

1.2.40.0.34.6.0.11.2.137

ref

at-cda-bbr-

Gültigkeit ab

2024‑06‑25 15:09:20

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atcdabbr_section_RezeptKodiert

Bezeichnung

Rezept - kodiert

Beschreibung

In dieser Sektion sind die ärztlichen Rezepte mit ihren einzelnen Verordnungen aufgeführt. Diese Informationen stehen ebenfalls in maschinenlesbarer Form zur Verfügung. Ein Rezept ist eine schriftliche Anweisung einer Ärztin oder eines Arztes an die Apotheke, bestimmte Arzneimittel oder andere apothekenpflichtige Produkte für einen Patienten bereitzustellen. Jede Verordnung auf dem Rezept enthält Angaben zum verordneten Medikament, zur Dosierung, zur Darreichungsform, zur Anwendungsdauer, Packungsgröße wie auch weiteren Details.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.2.137

Klassifikation

CDA Section level template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.3.185	Containment	Medikation Verordnung Entry eMedikation v3 (3.0.0+20250228)	DYNAMIC

Beziehung

Spezialisierung: Template 2.16.840.1.113883.10.20.1.8 (2005‑09‑07)

ref

at-cda-bbr-

Spezialisierung: Template 1.3.6.1.4.1.12559.11.10.1.3.1.2.1 Section Prescription (2013‑12‑20)

ref

epsos-

Beispiel

<section classCode="DOCSECT" moodCode="EVN">
  <templateId root="1.2.40.0.34.6.0.11.2.137"/>  <templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.2.1"/>  <id root="1.2.3.999" extension="extension" assigningAuthorityName="assigningAuthorityName"/>  <code code="57828-6" codeSystem="2.16.840.1.113883.6.1" displayName="Prescription list"/>  <title>title</title>  <cda:text/>  <hl7:entry typeCode="COMP">
    
  </hl7:entry></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

1 … 1

R

@classCode

cs

0 … 1

F

DOCSECT

@moodCode

cs

0 … 1

F

EVN

hl7:templateId

II

1 … 1

M

e-Medikation v3 Rezept Sektion

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.2.137

hl7:templateId

II

1 … 1

M

eHDSI/EPSOS Prescription Section

@root

uid

1 … 1

F

1.3.6.1.4.1.12559.11.10.1.3.1.2.1

hl7:id

II

1 … 1

M

@root

uid

1 … 1

R

@extension

st

0 … 1

@assigningAuthorityName

st

0 … 1

Beispiel

Methode 1: Angabe einer OID als direkten Identifikator

Beispiel

Methode 2: Angabe der OID der ID-Liste in @root sowie der eigentlichen ID in @extension

Beispiel

Methode 3: Angabe einer UUID als extension zur OID '2.25'

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

57828-6

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

Prescription list

hl7:title

ST

1 … 1

M

Constraint

Für die e-Medikation soll die Sektion immer "Rezept" heißen, im eHDSI Kontext hingegen immer "Prescription". Bei allen anderen Fällen ist der jeweilige Leitfaden zu beachten!

hl7:text

SD.TEXT

1 … 1

M

hl7:entry

1 … *

M

Beinhaltet 1.2.40.0.34.6.0.11.3.185 Medikation Verordnung Entry eMedikation v3 (DYNAMIC)

@typeCode

cs

1 … 1

F

COMP

Narrativer Text soll immer vollständig von den maschinenlesbaren Elementen abgeleitet und sollte keine darüber hinausgehende Information enthalten, somit kann es in den meisten Fällen als typecode="DRIV" interpretiert werden. Für die CDA-Validität der Fälle wo dies nicht der Fall ist, wird jedoch immer typecode="COMP" verwendet.

7.3.3.2 Abgabe - kodiert

Id

1.2.40.0.34.6.0.11.2.138

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑26 16:52:45

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atcdabbr_section_AbgabeKodiert

Bezeichnung

Abgabe - kodiert

Beschreibung

In dieser Sektion sind die an den Patienten abgegebenen Arzneimittel aufgeführt. Die entsprechenden Informationen liegen zudem in maschinenlesbarer Form vor. Unter einer Abgabe versteht man die Ausgabe von Arzneimitteln oder anderen apothekenpflichtigen Produkten an den Patienten.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.2.138

Klassifikation

CDA Section level template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.3.187	Containment	Medikation Abgabe Entry eMedikation v3 (3.0.0+20250228)	DYNAMIC

Beispiel

Strukturbeispiel

<section classCode="DOCSECT" moodCode="EVN">
  <templateId root="1.2.40.0.34.6.0.11.2.138"/>  <templateId root="1.3.6.1.4.1.12559.11.10.1.3.1.2.2"/>  <templateId root="2.16.840.1.113883.10.20.1.8"/>  <id root="1.2.3.999" extension="extension" assigningAuthorityName="assigningAuthorityName"/>  <code code="60590-7" codeSystem="2.16.840.1.113883.6.1" displayName="Medication dispensed"/>  <title>title</title>  <cda:text/>  <hl7:entry typeCode="COMP">
    
  </hl7:entry></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

1 … 1

R

@classCode

cs

0 … 1

F

DOCSECT

@moodCode

cs

0 … 1

F

EVN

hl7:templateId

II

1 … 1

M

e-Medikation v3 Abgabe Sektion

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.2.138

hl7:templateId

II

1 … 1

M

eHDSI/EPSOS Dispensation Section

@root

uid

1 … 1

F

1.3.6.1.4.1.12559.11.10.1.3.1.2.2

hl7:templateId

II

1 … 1

M

Medication section (CCD)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.8

hl7:id

II

1 … 1

M

@root

uid

1 … 1

R

@extension

st

0 … 1

@assigningAuthorityName

st

0 … 1

Beispiel

Methode 1: Angabe einer OID als direkten Identifikator

Beispiel

Methode 2: Angabe der OID der ID-Liste in @root sowie der eigentlichen ID in @extension

Beispiel

Methode 3: Angabe einer UUID als extension zur OID '2.25'

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

60590-7

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

Medication dispensed

hl7:title

ST

1 … 1

M

Constraint

Im Kontext der e-Medikation soll die Sektion immer "Abgabe" heißen, im eHDSI-Kontext hingegen immer "Dispensation". In allen anderen Fällen ist der jeweilige Leitfaden zu beachten!

hl7:text

SD.TEXT

1 … 1

M

hl7:entry

1 … *

M

Beinhaltet 1.2.40.0.34.6.0.11.3.187 Medikation Abgabe Entry eMedikation v3 (DYNAMIC)

@typeCode

cs

1 … 1

F

COMP

Narrativer Text soll immer vollständig von den maschinenlesbaren Elementen abgeleitet und sollte keine darüber hinausgehende Information enthalten, somit kann es in den meisten Fällen als typecode="DRIV" interpretiert werden. Für die CDA-Validität der Fälle wo dies nicht der Fall ist, wird jedoch immer typecode="COMP" verwendet.

7.3.3.3 Pharmazeutische Empfehlung - kodiert

Id

1.2.40.0.34.6.0.11.2.139

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 06:12:38

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atcdabbr_section_PharmazeutischeEmpfehlungKodiert

Bezeichnung

Pharmazeutische Empfehlung - kodiert

Beschreibung

In dieser Sektion sind die Korrekturmeldungen (Pharmazeutischen Empfehlungen) aufgeführt. Diese Informationen stehen ebenfalls in maschinenlesbarer Form zur Verfügung. Einzelne Verordnungen können mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) verändert wie auch storniert werden. Abgaben können mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) abgesetzt werden.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.2.139

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.3.188	Containment	Medikation Pharmazeutische Empfehlung Entry eMedikation v3 (3.0.0+20250228)	DYNAMIC

Beispiel

Strukturbeispiel

<section classCode="DOCSECT">
  <templateId root="1.2.40.0.34.6.0.11.2.139"/>  <templateId root="1.3.6.1.4.1.19376.1.9.1.2.2"/>  <id root="1.2.3.999" extension="extension" assigningAuthorityName="assigningAuthorityName"/>  <code code="61357-0" codeSystem="2.16.840.1.113883.6.1" displayName="Medication Pharmaceutical Advice.Brief"/>  <title>title</title>  <cda:text/>  <hl7:entry typeCode="COMP">
    
  </hl7:entry></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

@classCode

cs

0 … 1

F

DOCSECT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.2.139

hl7:templateId

II

1 … 1

M

IHE PHARM Pharmaceutical Advice Section

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.9.1.2.2

hl7:id

II

1 … 1

M

@root

uid

1 … 1

R

@extension

st

0 … 1

@assigningAuthorityName

st

0 … 1

Beispiel

Methode 1: Angabe einer OID als direkten Identifikator

Beispiel

Methode 2: Angabe der OID der ID-Liste in @root sowie der eigentlichen ID in @extension

Beispiel

Methode 3: Angabe einer UUID als extension zur OID '2.25'

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

61357-0

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

Medication Pharmaceutical Advice.Brief

hl7:title

ST

1 … 1

M

Constraint

Für die e-Medikation soll die Sektion immer "Pharmazeutische Empfehlung" heißen. Bei allen anderen Fällen ist der jeweilige Leitfaden zu beachten!

hl7:text

ED

1 … 1

M

Information für den menschlichen Leser. Siehe auch „Empfehlung zur Gestaltung im Falle von CDA Level 3“.

hl7:entry

1 … *

M

Beinhaltet 1.2.40.0.34.6.0.11.3.188 Medikation Pharmazeutische Empfehlung Entry eMedikation v3 (DYNAMIC)

@typeCode

cs

1 … 1

F

COMP

Narrativer Text soll immer vollständig von den maschinenlesbaren Elementen abgeleitet und sollte keine darüber hinausgehende Information enthalten, somit kann es in den meisten Fällen als typecode="DRIV" interpretiert werden. Für die CDA-Validität der Fälle wo dies nicht der Fall ist, wird jedoch immer typecode="COMP" verwendet.

7.3.3.4 Medikationsliste - kodiert

Id

1.2.40.0.34.6.0.11.2.140

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 14:23:03

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atcdabbr_section_MedikationslisteKodiert

Bezeichnung

Medikationsliste - kodiert

Beschreibung

In dieser Sektion werden Inhalte der Sektionen Rezept, Abgaben und Korrekturmeldung (Pharmazeutischen Empfehlung) gemeinsam aufgeführt. Diese Informationen stehen ebenfalls in maschinenlesbarer Form zur Verfügung.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.2.140

Klassifikation

CDA Section level template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 3 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.3.185	Containment	Medikation Verordnung Entry eMedikation v3 (3.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.3.187	Containment	Medikation Abgabe Entry eMedikation v3 (3.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.3.188	Containment	Medikation Pharmazeutische Empfehlung Entry eMedikation v3 (3.0.0+20250228)	DYNAMIC

Beispiel

<section classCode="DOCSECT" moodCode="EVN">
  <templateId root="1.2.40.0.34.6.0.11.3.189"/>  <id root="1.2.3.999" extension="extension" assigningAuthorityName="assigningAuthorityName"/>  <code code="10160-0" codeSystem="2.16.840.1.113883.6.1" displayName="History of medication use"/>  <title>title</title>  <cda:text/>  <hl7:entry typeCode="COMP">
    
  </hl7:entry>  <hl7:entry typeCode="COMP">
    
  </hl7:entry>  <hl7:entry typeCode="COMP">
    
  </hl7:entry></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

1 … 1

R

Wenn Medikations Entries in einer Medikationsliste verwendet werden und die Medikationsliste kein terminologyDate im Header definiert hat, ist eine Verwendung des codeSystemVersion Attributes bei jedem Code Element der Medikations Entries verpflichtend!

@classCode

cs

0 … 1

F

DOCSECT

@moodCode

cs

0 … 1

F

EVN

hl7:templateId

II

1 … 1

M

e-Medikation v3 Sektion - Medikationsliste - kodiert

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.3.189

hl7:id

II

1 … 1

M

@root

uid

1 … 1

R

@extension

st

0 … 1

@assigningAuthorityName

st

0 … 1

Beispiel

Methode 1: Angabe einer OID als direkten Identifikator

Beispiel

Methode 2: Angabe der OID der ID-Liste in @root sowie der eigentlichen ID in @extension

Beispiel

Methode 3: Angabe einer UUID als extension zur OID '2.25'

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

10160-0

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@displayName

1 … 1

F

History of medication use

hl7:title

ST

1 … 1

M

Constraint

Für die e-Medikation soll die Sektion immer "Medikationsliste" heißen. Bei allen anderen Fällen ist der jeweilige Leitfaden zu beachten!

hl7:text

SD.TEXT

1 … 1

M

hl7:entry

0 … *

R

Beinhaltet 1.2.40.0.34.6.0.11.3.185 Medikation Verordnung Entry eMedikation v3 (DYNAMIC)

@typeCode

cs

1 … 1

F

COMP

Narrativer Text soll immer vollständig von den maschinenlesbaren Elementen abgeleitet und sollte keine darüber hinausgehende Information enthalten, somit kann es in den meisten Fällen als typecode="DRIV" interpretiert werden. Für die CDA-Validität der Fälle wo dies nicht der Fall ist, wird jedoch immer typecode="COMP" verwendet.

hl7:entry

0 … *

R

Beinhaltet 1.2.40.0.34.6.0.11.3.187 Medikation Abgabe Entry eMedikation v3 (DYNAMIC)

@typeCode

cs

1 … 1

F

COMP

Narrativer Text soll immer vollständig von den maschinenlesbaren Elementen abgeleitet und sollte keine darüber hinausgehende Information enthalten, somit kann es in den meisten Fällen als typecode="DRIV" interpretiert werden. Für die CDA-Validität der Fälle wo dies nicht der Fall ist, wird jedoch immer typecode="COMP" verwendet.

hl7:entry

0 … *

R

Beinhaltet 1.2.40.0.34.6.0.11.3.188 Medikation Pharmazeutische Empfehlung Entry eMedikation v3 (DYNAMIC)

@typeCode

cs

1 … 1

F

COMP

Narrativer Text soll immer vollständig von den maschinenlesbaren Elementen abgeleitet und sollte keine darüber hinausgehende Information enthalten, somit kann es in den meisten Fällen als typecode="DRIV" interpretiert werden. Für die CDA-Validität der Fälle wo dies nicht der Fall ist, wird jedoch immer typecode="COMP" verwendet.

7.3.4 Entry Level Template

7.3.4.1 Arznei Entry v3

Id

1.2.40.0.34.6.0.11.3.186

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑25 14:50:59

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atcdabbr_entry_ArzneiEntryv3

Bezeichnung

Arznei Entry v3

Beschreibung

In diesem Entry ist ein Medikament maschinenlesbarer aufgeführt. Das Arznei Entry wird vom Verordnung Entry, Abgabe Entry und Korrekturmeldung (Pharmazeutischen Empfehlung) Entry verwendet.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.3.186

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.2	Inklusion	Original Text Reference (1.0.0+20210219)	DYNAMIC

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:manufacturedProduct

@classCode

cs

1 … 1

F

MANU

hl7:templateId

II

1 … 1

R

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.3.186

hl7:templateId

II

1 … 1

R

@root

uid

1 … 1

F

1.3.6.1.4.1.12559.11.10.1.3.1.3.29

hl7:manufacturedMaterial

1 … 1

M

@classCode

cs

1 … 1

F

MMAT

@determinerCode

cs

1 … 1

F

KIND

hl7:templateId

II

1 … 1

R

@root

uid

1 … 1

F

1.3.6.1.4.1.12559.11.10.1.3.1.3.30

hl7:code

CE

1 … 1

R

Arznei kann identifiziert werden mit der

Pharmazentralnummer (OID 1.2.40.0.34.4.16)
Zulassungsnummer (OID 1.2.40.0.34.4.17)
Package Reference Number der AGES (OID 1.2.40.0.34.4.26)
(in Vorbereitung, bitte noch nicht verwenden) PCID der EMA (OID 1.2.40.0.34.4.27)

Zugelassene nullFlavor:

'NA' Arznei ist eine magistrale Zubereitung oder Infusion.

Die Pharmazentralnummer (PZN) oder sonstiger erlaubter Identifikator der Arznei. Bei magistralen Anwendungen oder Infusionen, bei denen keine Pharmazentralnummer existiert, wird der nullFlavor 'NA' angewandt.

Das Codesystem „Pharmazentralnummer“ {1.2.40.0.34.4.16} wird am Terminologieserver in der „ASP-Liste“ (Liste der humanen Arzneispezialitäten gelistet nach PZN) publiziert, die ASP-Liste enthält neben der Pharmazentralnummer {1.2.40.0.34.4.17} auch die korrespondierende "Zulassungsnummer" und "Package Reference Number" der AGES {1.2.40.0.34.4.26}. Für die Kompatibilität zum EU Kontext wird zukünftig auch die "PCID" der EMA {1.2.40.0.34.4.27} ermöglicht.

Die Codeliste kann über den Terminologieserver ( https://termgit.elga.gv.at/ ) abgerufen werden.

@nullFlavor

cs

0 … 1

CONF

@nullFlavor MUSS "NA" sein

oder

@nullFlavor MUSS "NI" sein

oder

@nullFlavor MUSS "UNK" sein

CONF

@codeSystem MUSS "1.2.40.0.34.4.16" sein

oder

@codeSystem MUSS "1.2.40.0.34.4.17" sein

Beispiel

Code der Arznei (PZN)

Beispiel

Code der Arznei (PRN)

Beispiel

Code der Arznei (Zulassungsnummer)

Beispiel

Code der Arznei (PZN) mit Zulassungsnummer

Beispiel

Magistrale Zubereitung oder Infusionen ohne PZN oder sonstigem erlaubten Code

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:translation

CE

0 … *

C

Zulassungsnummer der Arznei.

Dieses Element wird nur verwendet, wenn der Arznei-Entry im Rahmen der Medikationsliste verwendet wird.

Constraint

Konditionale Konformität:

Card	Conf	Prädikat
0..*	O	Dokumenttyp Medikationsliste
	NP	sonst

@codeSystem

CONF

0 … 1

F

1.2.40.0.34.4.17 (Zulassungsnummer)

Schematron assert

role

error

test

not(hl7:translation) or //hl7:templateId[@root='1.2.40.0.34.6.0.11.0.23']

Meldung

Optionale Übersetzung des Codes nur bei Medikationsliste zugelassen

hl7:name

EN

1 … 1

R

Bezeichnung der Arznei. Zugelassenes nullFlavor:

NA Arznei ist eine magistrale Zubereitung oder Infusion

Die vollständige Bezeichnung der Arznei gemäß ihrer PZN („Handelsname“). Für magistrale Zubereitungen oder Infusion, bei denen keine Pharmazentralnummer und damit auch kein Handelsname existiert, MUSS eine Bezeichnung der magistralen Zubereitung oder Infusion angegeben werden. Diese sollte kürzer als die Langbeschreibung sein, aber mindestens den Hauptwirkstoff und dessen Stärke enthalten.

@nullFlavor

cs

0 … 1

CONF

@nullFlavor MUSS "NA" sein

Beispiel

Name der Arznei

<name>Parkemed 500mg</name>

Beispiel

Magistrale Zubereitungen oder Infusionen ohne Handelsnamen

pharm:formCode

CE

1 … 1

R

Darreichungsform. Kann bei codierten Arzneien aus der ASP-Liste entnommen werden.

@nullFlavor

cs

0 … 1

F

NI

Constraint

Für die e-Medikation ist das CodeSystem 1.2.40.0.10.1.4.3.4.3.5 zu verwenden.

Für den eHDSI Kontext ist das CodeSystem 0.4.0.127.0.16.1.1.2.1 zu verwenden.

Beispiel

Darreichungsform bei magistraler Zubereitung oder Infusionen

Beispiel

Darreichungsform bei eHDSI ePrescription/eDispensation

Beispiel

Darreichungsform unbekannt bei codierter Arznei

Schematron assert

role

error

test

hl7:code/@code or pharm:asContent

Meldung

pharm:asContent Komponente zur Aufnahme der Packungsangaben verflichtend, wenn es sich um eine magistrale Zubereitung oder Infusion handelt.

pharm:asContent

1 … 1

M

Angaben zur Packung. Kann bei codierten Arzneien aus der ASP-Liste entnommen werden.

Angaben zur Packung werden immer angegeben. Falls keine Details zu der Packung bekannt sind, soll unter asContent/quantity/value einfach „1“ angegeben werden.

@classCode

cs

1 … 1

F

CONT

pharm:quantity

PQ

1 … 1

M

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

@value

real

1 … 1

R

hl7:translation

PQR

0 … 1

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

hl7:originalText

ED

1 … 1

M

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

pharm:containerPackagedMedicine

NP

Dieses Element wurde früher in der Hauptversion 2 der e-Medikation für die Angaben zur Packung verwendet. Dies ist mit der Hauptversion 3 nicht mehr erlaubt, da diese Information im darüberliegenden asContent direkt dokumentiert wird.

pharm:containerPackagedProduct

1 … 1

R

Dieses Element wird im eHDSI zur verpflichtenden Angabe der Größe zur überliegenden Packung verwendet. Da diese Informationen in Österreich nicht bereitgestellt werden, wird dieses Element für den österreichischen Kontext mit einem fixen nullFlavor im darunterliegenden formCode versehen.

@classCode

cs

1 … 1

F

CONT

@determinerCode

cs

1 … 1

F

KIND

pharm:formCode

1 … 1

R

@nullFlavor

cs

1 … 1

F

NI

pharm:ingredient

1 … *

M

Komponente zur Aufnahme des Wirkstoffs. Kann bei codierten Arzneien aus der ASP-Liste entnommen werden.

Wirkstoff-Codes stammen aus der ATC-Klassifikation (Anatomical Therapeutic Chemical Classification), die von der WHO herausgegeben wird. Weitere Codes, wie auch die deutsche Bezeichnung der Codes, entsprechen dem GKV-Arzneimittelindex im Wissenschaftlichen Institut der AOK (WidO), AOK Bundesverband GbR, Deutschland, welcher auf den WHO ATC basiert.

Zusätzlich kommen ergänzende Codes aus dem Arzneimittelverzeichnis der AGES zum Einsatz.

@classCode

cs

1 … 1

F

ACTI

Beispiel

Wirkstoff 1 (codiert, Value-Set ELGA_whoATC_VS) Beispiel Arznei

<ingredient classCode="ACTI">
<ingredient classCode="MMAT" determinerCode="KIND">
<code code="M01AG01" displayName="Mefenamic acid" codeSystem="2.16.840.1.113883.6.73" codeSystemName="whoATC"/> <name>Mefenaminsäure</name> </ingredient></ingredient>

Beispiel

Wirkstoff 2 (nur Name), Beispiel magistrale Zubereitung

<ingredient classCode="ACTI">
<ingredient classCode="MMAT" determinerCode="KIND">
<name>Mefenaminsäure</name> </ingredient></ingredient>

Beispiel

Wirkstoff 1 (codiert, Value-Set ELGA_Wirkstoffe_AGES_VS), 2795 Beispiel Arznei, wird nur in der Medikationsliste verwendet

<ingredient classCode="ACTI">
<ingredient classCode="MMAT" determinerCode="KIND">
<code code="100000090680" displayName="SENNAE FOLIUM" codeSystem="1.2.40.0.34.5.156" codeSystemName="Medikation_AGES_Wirkstoffe"/> <name>Mefenaminsäure</name> </ingredient></ingredient>

pharm:ingredientSubstance

1 … 1

M

Code und Name des Wirkstoffs.

@classCode

cs

1 … 1

F

MMAT

@determinerCode

cs

1 … 1

F

KIND

pharm:code

CE

1 … 1

M

Code und Klartext des Wirkstoffs.

Constraint

Für die e-Medikation sind die CodeSysteme "ATC WHO" 2.16.840.1.113883.6.73 , "ATC WIdO" 1.2.276.0.76.5.547 oder "Medikation AGES Wirkstoffe" 1.2.40.0.34.5.156 zu verwenden.

Für den eHDSI Kontext sind die CodeSysteme "ATC WHO" 2.16.840.1.113883.6.73 oder "eHDSI Substance" 2.16.840.1.113883.3.6905.2 zu verwenden.

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:translation

CE

C

Wird das Element in der Medikationsliste verwendet, ist hier die Wirkstoffklasse zum Wirkstoff angegeben.

Dieses Element wird nur verwendet, wenn der Arznei-Entry im Rahmen der Medikationsliste verwendet wird.

Constraint

Konditionale Konformität:

Card	Conf	Prädikat
1..1	M	Element wird in Medikationsliste verwendet
	NP	Sonst

pharm:name

EN

0 … 1

Name des Wirkstoffs.

z.B.: Mefenaminsäure

7.3.4.2 Medikation Verordnung Entry eMedikation v3

Id

1.2.40.0.34.6.0.11.3.185

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑24 12:06:20

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atcdabbr_entry_MedikationVerordnungEntryemedv3

Bezeichnung

Medikation Verordnung Entry eMedikation v3

Beschreibung

In diesem Entry ist eine einzelne Verordnung eines ärztlichen Rezepts maschinenlesbarer aufgeführt. Ein Rezept ist eine schriftliche Anweisung einer Ärztin oder eines Arztes an die Apotheke, bestimmte Arzneimittel oder andere apothekenpflichtige Produkte für einen Patienten bereitzustellen. Jede Verordnung auf dem Rezept enthält Angaben zum verordneten Medikament, zur Dosierung, zur Darreichungsform, zur Anwendungsdauer, Packungsgröße wie auch weiteren Details.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.3.185

Klassifikation

CDA Entry 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.9.48	Inklusion	Medikation Sbadm TemplateId Options (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.49	Inklusion	Medikation Einnahmedauer (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.50	Inklusion	Medikation Dosierungsvariante 1: Tagesdosierung effectiveTime (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.51	Inklusion	Medikation Dosierungsvariante 2: Einzeldosierung (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.52	Inklusion	Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.53	Inklusion	Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.54	Inklusion	Medikation Dosierungsvariante 1: Tagesdosierung doseQuantity (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.55	Inklusion	Medikation Dosierungsvariante 2: Einzeldosierung doseQuantity (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.56	Inklusion	Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.57	Inklusion	Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.3.186	Containment	Arznei Entry v3 (3.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.1.2.2.1	Inklusion	Author v2 Prescriber (2.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.58	Inklusion	Medikation Dosierungsvariante 2: Einzeldosierung entryRelationship (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.60	Inklusion	Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.62	Inklusion	Medikation Patient Instructions (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.63	Inklusion	Medikation Pharmacist Instructions (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.64	Inklusion	Medikation Therapieart (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.3.6	Inklusion	Problem Entry (1.1.2)	DYNAMIC
1.2.40.0.34.6.0.11.9.65	Inklusion	Medikation ID des Containers (1.0.0+20250228)	DYNAMIC

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:substanceAdministration

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

Constraint

Bei Dosierungsart 1 "Normal dosing" oder 3 "Tagesdosierung an bestimmten Tagen" (templateId = 1.3.6.1.4.1.19376.1.5.3.1.4.7.1) wird kein entryRelationship typeCode COMP als Dosiskomponente verwendet

Wiederholung der Komponente zur Aufnahme eines Einnahmezeitpunkts und -dosis bei Dosierungsvariante 2 und 4 höchstens einmal je Zeitcode!

hl7:templateId

II

1 … 1

M

Medikation Verordnung Entry eMedikation v3

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.3.185

hl7:templateId

II

1 … 1

M

eHDSI Substance Administration

@root

uid

1 … 1

F

1.3.6.1.4.1.12559.11.10.1.3.1.3.2

hl7:templateId

II

1 … 1

M

IHE PCC Medications Entry

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.7

hl7:templateId

II

1 … 1

M

HL7 CCD 3.9

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.24

hl7:templateId

II

1 … 1

M

IHE PHARM Dosage Instructions

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.9.1.3.6

Eingefügt

von 1.2.40.0.34.6.0.11.9.48 Medikation Sbadm TemplateId Options (DYNAMIC)

„Delay Start Dosing“ Markierung bei Verwendung eines „width“ Elements in Einnahmedauer.

Siehe Kapitel 6.4.1.2.6, „Einnahmedauer“

hl7:templateId

II

C

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.21

Constraint

Konditionale Konformität

Einnahmedauer beinhaltet low/high Elemente Conf: NP
Einnahmedauer beinhaltet ein width Element: Card 1..1 Conf M

Auswahl

0 … 1

Dosierungsart, mögliche Werte:

a) Normal: @root = 1.3.6.1.4.1.19376.1.5.3.1.4.7.1

b) Split: @root = 1.3.6.1.4.1.19376.1.5.3.1.4.9

c) keine Dosierung: templateID Element entfällt vollständig.

Dosierungsart: Normal (1.3.6.1.4.1.19376.1.5.3.1.4.7.1), Split (1.3.6.1.4.1.19376.1.5.3.1.4.9) oder keine Dosierung (keine der beiden TemplateIDs)

Elemente in der Auswahl:

hl7:templateId
hl7:templateId

hl7:templateId

II

0 … 1

R

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.7.1

hl7:templateId

II

0 … 1

R

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.9

hl7:id

II

0 … 1

C

ID des MedikationVerordnungs-Entry.

wo [1]

@root

uid

1 … 1

R

Wurzel OID der ID eines MedikationVerordnungs-Entry gemäß Projekt e-Medikation.

@extension

st

1 … 1

R

VerordnungsID.

Constraint

Für e-Medikation: ID eines MedikationVerordnungs-Entry gemäß der Anwendung e-Medikation: Das erste ID-Element enthält eine von der Zentralkomponente der e-Medikation vergebene neue ID des Verordnungs-Entry, welche durch eine eigene OID im @root-Attribut gekennzeichnet ist. Diese neue ID ist notwendig, da das Verordnungs-Entry bei Rückgabe in der Medikationsliste durch die Zentralkomponenten mit verschiedenen zusätzlichen Informationen ergänzt wird.

Nur für andere e-Befunde (also Dokumentenklassen außerhalb dieses Leitfadens, wie z.B. Entlassungsbrief ärztlich) ist eine lokale OID zulässig, sofern keine VerordnungsID vorliegt.

Bedingung:
Bei Medikationsliste @root="1.2.40.0.10.1.4.3.4.2.2.1" @extension=VerordnungsID

Sonst @root="1.2.40.0.10.1.4.3.4.2.2" @extension=VerordnungsID

Beispiel

Schematron assert

role

error

test

not(ancestor::hl7:ClinicalDocument/hl7:templateId[@root='1.2.40.0.34.6.0.11.0.23']) or hl7:id[1][@root='1.2.40.0.10.1.4.3.4.2.2.1']

Meldung

Bei Medikationslisten muss die erste ID die @root OID 1.2.40.0.10.1.4.3.4.2.2.1 tragen.

Schematron assert

role

error

test

not(ancestor::hl7:ClinicalDocument/hl7:templateId[@root='1.2.40.0.34.6.0.11.0.20']) or hl7:id[1][@root='1.2.40.0.10.1.4.3.4.2.2']

Meldung

Bei Verordnungen muss die erste ID die @root OID 1.2.40.0.10.1.4.3.4.2.2 tragen.

Schematron assert

role

error

test

not(ancestor::hl7:ClinicalDocument/hl7:templateId[starts-with(@root, '1.2.40.0.34.7.8.9.3')]) or hl7:id[1]

Meldung

Für e-Medikation Dokumente muss die erste ID angegeben sein.

hl7:id

II

0 … 1

C

ID des ursprünglichen MedikationVerordnungs-Entry (nur für nicht Rezept Dokumente)

wo [2]

@root

uid

1 … 1

R

Wurzel OID der ID eines MedikationVerordnungs-Entry gemäß Projekt e-Medikation.

@extension

st

1 … 1

R

VerordnungsID.

Constraint

Für e-Medikation gilt das im Verordnungs-Entry der Medikationsliste oder der pharmazeutischen Empfehlung das zweite id-Element verpflichtend anzugeben ist (1..1 M). Es muss die ID des ursprünglich im Rezept-Dokument angegebenen Verordnungs-Entry enthalten, welche den Ausgangspunkt des vorliegenden Verordnungs-Entry darstellt.

Im Verordnungs-Entry eines Rezepts darf das zweite id-Element nicht verwendet werden (0..0 NP).

In anderen e-Befunden kann dieses Element entfallen (0..1 O).

hl7:text

ED

1 … 1

M

Verweist auf die Stelle im narrativen Text-Bereich, an der die gegebene Medikation narrativ beschrieben ist (

mit

zusätzlichen Informationen, wie Datum, Beschreibung, etc).

Beispiel

Strukturbeispiel

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#vpos-{generierteID},

z.B.: #vpos-1

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

Eingefügt

von 1.2.40.0.34.6.0.11.9.49 Medikation Einnahmedauer (DYNAMIC)

Beispiel

Strukturbeispiel

<cda:ClinicalDocument>
  
  <cda:effectiveTime xsi:type="IVL_TS">
    <cda:low value="20110527000000+0200"/>    <cda:high nullFlavor="UNK"/>  </cda:effectiveTime></cda:ClinicalDocument>

Beispiel

Strukturbeispiel

<cda:ClinicalDocument>
  
  <cda:effectiveTime xsi:type="IVL_TS">
    <cda:width value="2" unit="wk"/>  </cda:effectiveTime></cda:ClinicalDocument>

Beispiel

Strukturbeispiel

<cda:ClinicalDocument>
  
  <cda:effectiveTime xsi:type="IVL_TS">
    <cda:low nullFlavor="UNK"/>    <cda:high nullFlavor="UNK"/>  </cda:effectiveTime></cda:ClinicalDocument>

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:effectiveTime[1][hl7:low]
hl7:effectiveTime[1][hl7:width]
hl7:effectiveTime[1][@nullFlavor]

hl7:effectiveTime

IVL_TS

0 … 1

R

Zeitelement zur Dokumentation der Einnahmedauer.

wo [1] [hl7:low]

hl7:low

TS

1 … 1

R

Zeitpunkt des Einnahmestarts.
Zugelassene nullFlavor: UNK

hl7:high

TS

1 … 1

R

Zeitpunkt des Einnahmeendes.
Zugelassene nullFlavor: UNK

hl7:effectiveTime

IVL_TS

0 … 1

R

Dauer der Einnahme, wenn Einnahmestart unbekannt

wo [1] [hl7:width]

hl7:width

PQ

1 … 1

M

Dauer der Einnahme, wenn Einnahmestart unbekannt

Bemerkung: Wenn ein width Element angegeben wird, MUSS auch die templateId für „Delay Start Dosing“ angegeben werden.

Siehe Kapitel „Template IDs"

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.69 ELGA_MedikationFrequenz (DYNAMIC)

hl7:effectiveTime

IVL_TS

0 … 1

R

wo [1] [@nullFlavor]

@nullFlavor

cs

1 … 1

F

NA

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Wenn die Dosierungsvariante einer Verordnung "Split" ist, ist in der Verordnung die templateId 1.3.6.1.4.1.19376.1.5.3.1.4.9 anzugeben.
	NP	Sonst

Auswahl

… 1

Elemente in der Auswahl:

hl7:effectiveTime[hl7:period and not(hl7:phase)] eingefügt vom Template 1.2.40.0.34.6.0.11.9.50 Medikation Dosierungsvariante 1: Tagesdosierung effectiveTime (DYNAMIC)
hl7:effectiveTime[2] eingefügt vom Template 1.2.40.0.34.6.0.11.9.51 Medikation Dosierungsvariante 2: Einzeldosierung (DYNAMIC)
ein Element eingefügt vom Template 1.2.40.0.34.6.0.11.9.52 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause (DYNAMIC)
hl7:effectiveTime[2] eingefügt vom Template 1.2.40.0.34.6.0.11.9.53 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.50 Medikation Dosierungsvariante 1: Tagesdosierung effectiveTime (DYNAMIC)

hl7:effectiveTime

PIVL_TS

C

Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [hl7:period and not(hl7:phase)]

@operator

cs

1 … 1

F

A

@institutionSpecified

bl

1 … 1

F

true

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..1 M
Dosierung nicht angegeben -> NP

hl7:period

PQ

1 … 1

R

Zeitraum für den die Dosis in doseQuantity vorgesehen ist.

@value

1 … 1

F

1

@unit

cs

1 … 1

R

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.69 ELGA_MedikationFrequenz (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.51 Medikation Dosierungsvariante 2: Einzeldosierung (DYNAMIC)

hl7:effectiveTime

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [2]

Eingefügt

von 1.2.40.0.34.6.0.11.9.52 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause (DYNAMIC)

Auswahl

… 1

Elemente in der Auswahl:

hl7:effectiveTime[hl7:period and hl7:phase]
hl7:effectiveTime[hl7:comp]

hl7:effectiveTime

PIVL_TS

C

Für EIN Wochentag.
Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [hl7:period and hl7:phase]

@operator

cs

1 … 1

F

A

hl7:phase

IVL_TS

1 … 1

R

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag)

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:effectiveTime

SXPR_TS

C

Für mehrere Wochentage, z. B. wöchtentlich montags und mittwochs

wo [hl7:comp]

@operator

cs

1 … 1

F

A

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..1 M
Dosierung nicht angegeben -> NP

1. Komponentencontainer ohne @operator, ggf. folgende Komponentencontainer mit @operator=I

hl7:comp

PIVL_TS

1 … 1

R

Komponentencontainer.

wo [not(@operator)]

hl7:phase

IVL_TS

1 … 1

R

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag)

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:comp

PIVL_TS

0 … *

wo [@operator='I']

@operator

cs

1 … 1

F

I

hl7:phase

IVL_TS

1 … 1

R

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

Eingefügt

von 1.2.40.0.34.6.0.11.9.53 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause (DYNAMIC)

hl7:effectiveTime

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [2]

Schematron report

role

warning

test

not(not(hl7:templateId[@root='1.3.6.1.4.1.19376.1.5.3.1.4.7.1']) or hl7:effectiveTime[2])

Meldung

effectiveTime[2] muss in den Dosierungsvarianten 1 und 3 anwesend sein

Schematron report

role

warning

test

hl7:templateId[@root='1.3.6.1.4.1.19376.1.5.3.1.4.9'] and hl7:effectiveTime[2]

Meldung

effectiveTime[2] darf in den Dosierungsvariante 'Split dosing' nicht anwesend sein

hl7:repeatNumber

IVL_INT

1 … 1

R

Anzahl der Einlösungen. Muss größer gleich 0 sein.

Dieses Element MUSS angegeben werden. Dieses Element beschreibt die mögliche maximale Anzahl von zusätzlichen Einlösungen dieser Verordnung. Bei Verwendung in der Medikationsliste wird immer der ursprüngliche Wert angegeben (ändert sich nicht nach einer Einlösung).

Beispiele :

Ein Wert von „0“ bedeutet, dass die Verordnung kein weiteres Mal eingelöst werden kann (Standardfall)
Ein Wert von „3“ bedeutet, dass die Verordnung insgesamt vier Mal eingelöst werden kann.

Alle Verordnungen eines Rezepts MÜSSEN denselben Wert aufweisen.
Zugelassene nullFlavor: MSK

Wird die Anzahl der zusätzlichen Einlösungen nicht angegeben (nullFlavor = MSK, Maskiert), kann die Anzahl vom empfangenden System nur mit 0 angenommen werden (keine zusätzlichen Einlösungen).

Maximale Anzahl der zusätzlichen Einlösungen

Bei Kassenrezepten:

Fixer Wert: 0

Bei Privatrezepten:

Maximaler Wert: 5

Beispiel

Strukturbeispiel

hl7:routeCode

CE

1 … 1

M

Art der Anwendung der Arznei. Kann bei codierten Arzneien aus der ASP-Liste entnommen werden.

Constraint

Für die e-Medikation ist das CodeSystem 1.2.40.0.10.1.4.3.4.3.4 zu verwenden.

Für den eHDSI Kontext ist das CodeSystem 0.4.0.127.0.16.1.1.2.1 zu verwenden.

Beispiel

e-Medikation

Beispiel

eHDSI ePrescription/eDispensation

Auswahl

… 1

Elemente in der Auswahl:

ein Element eingefügt vom Template 1.2.40.0.34.6.0.11.9.54 Medikation Dosierungsvariante 1: Tagesdosierung doseQuantity (DYNAMIC)
hl7:doseQuantity eingefügt vom Template 1.2.40.0.34.6.0.11.9.55 Medikation Dosierungsvariante 2: Einzeldosierung doseQuantity (DYNAMIC)
ein Element eingefügt vom Template 1.2.40.0.34.6.0.11.9.56 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity (DYNAMIC)
hl7:doseQuantity eingefügt vom Template 1.2.40.0.34.6.0.11.9.57 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.54 Medikation Dosierungsvariante 1: Tagesdosierung doseQuantity (DYNAMIC)

Auswahl

… 1

Elemente in der Auswahl:

hl7:doseQuantity[not(hl7:low|hl7:high)]
hl7:doseQuantity[hl7:low|hl7:high]

Constraint

Konditionale Konformität:
Menge in nicht-zählbaren Einheiten -> @unit 1..1 (required) aus Value-Set ELGA_MedikationMengenart
Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.) -> @unit 0..1 (otional) mit @unit aus Value-Set ELGA_MedikationMengenartAlternativ

hl7:doseQuantity

IVL_PQ

R

Dosis.
mit doseQuantity als IVL_PQ, aber als PQ instantiiert

wo [not(hl7:lowoder
hl7:high)]

@value

1 … 1

R

Tagesdosierung.

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:doseQuantity

IVL_PQ

R

mit doseQuantity als IVL_PQ

wo [hl7:lowoder
hl7:high]

hl7:low

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:high

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.55 Medikation Dosierungsvariante 2: Einzeldosierung doseQuantity (DYNAMIC)

hl7:doseQuantity

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Dosis bei Dosierungsvariante 1 und 3.

Eingefügt

von 1.2.40.0.34.6.0.11.9.56 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity (DYNAMIC)

Auswahl

… 1

Elemente in der Auswahl:

hl7:doseQuantity[not(hl7:low|hl7:high)]
hl7:doseQuantity[hl7:low|hl7:high]

Constraint

Konditionale Konformität:
Menge in nicht-zählbaren Einheiten -> @unit 1..1 (required) aus Value-Set ELGA_MedikationMengenart
Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.) -> @unit 0..1 (optional) aus Value-Set ELGA_MedikationMengenartAlternativ

hl7:doseQuantity

IVL_PQ

R

Dosis.
mit doseQuantity als IVL_PQ, aber als PQ instantiiert

wo [not(hl7:lowoder
hl7:high)]

@value

1 … 1

R

Tagesdosierung.

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:doseQuantity

IVL_PQ

R

mit doseQuantity als IVL_PQ

wo [hl7:lowoder
hl7:high]

hl7:low

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:high

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.57 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity (DYNAMIC)

hl7:doseQuantity

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Dosis bei Dosierungsvariante 1 und 3.

Schematron report

role

warning

test

not(not(hl7:templateId[@root='1.3.6.1.4.1.19376.1.5.3.1.4.7.1']) or hl7:doseQuantity)

Meldung

doseQuantity muss in den Dosierungsvarianten 1 und 3 anwesend sein

Schematron report

role

warning

test

hl7:templateId[@root='1.3.6.1.4.1.19376.1.5.3.1.4.9'] and hl7:doseQuantity

Meldung

doseQuantity darf in den Dosierungsvariante 'Split dosing' nicht anwesend sein

hl7:consumable

1 … 1

M

Komponente zur Aufnahme der Arznei auf die sich der MedikationVerordnungs-Entry bezieht.
Beinhaltet 1.2.40.0.34.6.0.11.3.186 Arznei Entry v3 (DYNAMIC)

@typeCode

cs

1 … 1

F

CSM

Beispiel

Strukturbeispiel

Eingefügt

C

von 1.2.40.0.34.6.0.11.1.2.2.1 Author v2 Prescriber (DYNAMIC)

Dieses Element wird nur bei ELGA MedikationVerordnungs-Entrys verwendet, welche im Rahmen der Medikationsliste vorliegen.

Es beinhaltet den Verfasser des Rezepts auf dem diese Verordnung ausgestellt wurde. Das author/time Element hat dabei die Bedeutung „Datum der Verordnung“.

Siehe Kapitel „Teilnehmende Parteien“, Abschnitt „Verfasser des Dokuments (author)“ (bezogen auf das Rezept-Dokument).

Constraint

Konditionale Konformität :

Element wird in Medikationsliste verwendet und eine Referenz zu einer Verdnung ist vorhanden: Card 1..1 Conf M

Sonst NP

hl7:author

C

Verfasser des Dokuments.

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

1 … 1

M

Internationaler Funktionscode des Verfassers des Dokuments, z.B: „Generalist medical practitioners“, „Specialist medical practitioners“,„Nursing professionals“.

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

F

2.16.840.1.113883.2.9.6.2.7

@codeSystemName

st

1 … 1

F

ISCO-08

@displayName

st

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.1 eHDSIHealthcareProfessionalRole (DYNAMIC)

Auswahl

1 … 1

Der Zeitpunkt, zu 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

wo [not(@nullFlavor)]

hl7:time

TS.AT.TZ

0 … 1

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:assignedAuthor

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software.

ODER Identifikation des/der datenerstellenden Gerätes/Software.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NA“ haben und es dürfen keine anderen Attribute vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens ein Attribut vorhanden sein

@nullFlavor

cs

0 … 1

F

NA

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.

@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:addr

AD

1 … *

R

Angabe der Adresse des Verfassers des Dokuments
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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.

hl7:assignedPerson

1 … 1

M

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)

hl7:representedOrganization

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 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.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

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

von 1.2.40.0.34.6.0.11.9.58 Medikation Dosierungsvariante 2: Einzeldosierung entryRelationship (DYNAMIC)

hl7:entryRelationship

C

Komponente zur Aufnahme eines Einnahmezeitpunkts und –dosis bei Dosierungsvariante 2 und 4.

Wiederholung höchstens einmal je Zeitcode!

wo [hl7:substanceAdministration/hl7:effectiveTime [@xsi:type='EIVL_TS']]

@typeCode

cs

1 … 1

F

COMP

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..* M
Dosierung nicht angegeben -> NP

hl7:sequenceNumber

INT

1 … 1

M

Aufsteigende Nummerierung der Unterelemente.

Eingefügt

von 1.2.40.0.34.6.0.11.9.59 Medikation Splitdose-Einnahmezeitpunkte 1 (DYNAMIC)

hl7:substanceAdministration

1 … 1

M

Abbildung eines Einnahmezeitpunkts und –dosis als untergeordnetes substanceAdministration-Element.

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Menge in nicht-zählbaren Einheiten, zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS"
0..1	O	Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.), zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS" oder Freitext

hl7:effectiveTime

EIVL_TS

1 … 1

M

Zeitelement zur Aufnahme des Einnahmezeitpunkts.

wo [@xsi:type='EIVL_TS']

hl7:event

1 … 1

M

Einnahmezeitpunkt.

@code

cs

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.59 ELGA_Einnahmezeitpunkte (DYNAMIC)

hl7:offset

IVL_PQ

1 … 1

M

Zeitversatz (immer mit 0 Sekunden angegeben).

@value

1 … 1

F

0

@unit

cs

1 … 1

F

s

hl7:doseQuantity

IVL_PQ

1 … 1

M

Dosis.

hl7:consumable

1 … 1

M

hl7:manufacturedProduct

1 … 1

M

hl7:manufacturedMaterial

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

Eingefügt

von 1.2.40.0.34.6.0.11.9.60 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship (DYNAMIC)

hl7:entryRelationship

C

Komponente zur Aufnahme eines Einnahmezeitpunkts und –dosis bei Dosierungsvariante 2 und 4.

Wiederholung höchstens einmal je Zeitcode!

wo [hl7:substanceAdministration/hl7:effectiveTime [@xsi:type='SXPR_TS']]

@typeCode

cs

1 … 1

F

COMP

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..* M
Dosierung nicht angegeben -> NP

hl7:sequenceNumber

INT

1 … 1

M

Aufsteigende Nummerierung der Unterelemente.

Eingefügt

von 1.2.40.0.34.6.0.11.9.61 Medikation Splitdose-Einnahmezeitpunkte 2 (DYNAMIC)

hl7:substanceAdministration

1 … 1

M

Abbildung eines Einnahmezeitpunkts und –dosis als untergeordnetes substanceAdministration-Element.

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Menge in nicht-zählbaren Einheiten, zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS"
0..1	O	Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.), zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS" oder Freitext

hl7:effectiveTime

SXPR_TS

1 … 1

M

Zeitelement zur Aufnahme des Einnahmezeitpunkts.

wo [@xsi:type='SXPR_TS']

Constraint

Die comp-Komponenten mit PIVL_TS müssen bei allen Einnahmezeitpunkten gleich angegeben werden!

1. Komponentencontainer mit @operator=A, ggf. folgende Komponentencontainer mit @operator=I

hl7:comp

EIVL_TS

1 … 1

M

Komponentencontainer

wo [@xsi:type='EIVL_TS']

hl7:event

1 … 1

M

Einnahmezeitpunkt.

@code

cs

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.59 ELGA_Einnahmezeitpunkte (DYNAMIC)

hl7:offset

IVL_PQ

1 … 1

M

Zeitversatz (immer mit 0 Sekunden angegeben).

@value

1 … 1

F

0

@unit

cs

1 … 1

F

s

hl7:comp

PIVL_TS

1 … 1

M

Komponentencontainer zur Aufnahme der Einnahmetage.
Diese Komponenten MÜSSEN bei allen Einnahmezeitpunkten (SequenceNumber) gleich angegeben werden!

wo [@xsi:type='PIVL_TS'] [@operator='A']

@operator

cs

1 … 1

F

A

hl7:phase

IVL_TS

1 … 1

R

Phase der Einnahme.

hl7:value

TS

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag).

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:comp

PIVL_TS

0 … *

2.+ Komponentencontainer zur Aufnahme der Einnahmetage

wo [@xsi:type='PIVL_TS'] [@operator='I']

hl7:phase

IVL_TS

1 … 1

R

hl7:value

TS

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:doseQuantity

IVL_PQ

1 … 1

M

Dosis.

hl7:consumable

1 … 1

M

hl7:manufacturedProduct

1 … 1

M

hl7:manufacturedMaterial

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

Schematron assert

role

error

test

not(hl7:templateId[@root='1.3.6.1.4.1.19376.1.5.3.1.4.7.1']) or not(hl7:entryRelationship[@typeCode='COMP'][hl7:substanceAdministration])

Meldung

Bei Dosierungsart 1 "Normal dosing" oder 3 "Tagesdosierung an bestimmten Tagen" (templateId = 1.3.6.1.4.1.19376.1.5.3.1.4.7.1) wird kein entryRelationship typeCode COMP als Dosiskomponente verwendet

Variable let

Name

seq

Value

hl7:entryRelationship/hl7:substanceAdministration/hl7:effectiveTime[@value='0']//hl7:event/@code

Schematron assert

role

error

test

empty($seq[position() = index-of($seq,.)[2]])

Meldung

Wiederholung der Komponente zur Aufnahme eines Einnahmezeitpunkts und -dosis bei Dosierungsvariante 2 und 4 höchstens einmal je Zeitcode!

hl7:entryRelationship

1 … 1

M

Komponente zur Aufnahme der Packungsanzahl.

Da sich die Angaben zur Arznei (siehe Vorkapitel) jeweils auf eine Packung der Arznei beziehen, MUSS die Anzahl der auszugebenden Packungen der Arznei in einer eigenen Komponente zusätzlich angegeben werden (mindestens 1). Bei magistralen Zubereitungen wird die Anzahl der auszugebenden Einheiten der Arznei in derselben Art und Weise gehandhabt wie bei Arzneispezialitäten. Die Menge einer Einheit der Arznei (z.B. 200g einer magistral zubereiteten Salbe in einer gewissen Zusammensetzung) ist in den ergänzenden Informationen zu der magistralen Zubereitung anzugeben.

wo [@typeCode='COMP'] [hl7:supply]

@typeCode

cs

1 … 1

F

COMP

Beispiel

Strukturbeispiel

hl7:supply

1 … 1

M

Abbildung der Packungsanzahl als untergeordnetes supply-Element.

@classCode

cs

1 … 1

F

SPLY

@moodCode

cs

1 … 1

F

RQO

Beispiel

hl7:independentInd

BL

1 … 1

M

Indikator, ob die Komponente unabhängig verwendet werden darf.

@value

1 … 1

F

false

hl7:quantity

PQ

1 … 1

M

Gibt die Packungsanzahl an, die verschrieben werden. Muss größer gleich 1 sein.

Das Attribut value muss vorhanden sein und die Packungsanzahl angeben. Bei Verschreibungen für eine Gesamtmenge (z. B. 400 Tabletten) muss das Attribut value gleich 1 sein, und die Gesamtmenge ist in das Element hl7:consumable/hl7:manufacturedProduct/hl7:manufacturedMaterial/pharm:asContent/pharm:containerPackagedProduct/pharm:quantity einzutragen. Weitere Informationen finden Sie in der Beschreibung dieses Elements.

Das Attribut unit muss vorhanden sein und der UCUM-Einheit 1 entsprechen.

@value

real

1 … 1

R

@unit

cs

1 … 1

F

1

hl7:entryRelationship

0 … 1

Komponente zur Aufnahme der Zusatzinformationen, Informationen zur alternativen Einnahme und Informationen zur Arznei

wo [@typeCode='SUBJ'] [hl7:act/hl7:templateId [@root='2.16.840.1.113883.10.20.1.49']]

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.62 Medikation Patient Instructions (DYNAMIC)

hl7:act

1 … 1

M

Abbildung der Zusatzbemerkungen als untergeordnetes act-Element.

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.49

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

PINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die Zusatzinformationen für den Patienten, Informationen zur alternativen Einnahme und Informationen zur Arznei angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#patinfo-{generierteID}, z.B.: #patinfo-1

Schematron assert

role

error

test

starts-with(@value, '#patinfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 3

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.1

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.161 ELGA_ActCode_PatInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#zinfo|altein|arzneiinfo|veri-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #altein-1

Schematron assert

role

error

test

starts-with(@value, '#zinfo-') or starts-with(@value, '#altein-') or starts-with(@value, '#arzneiinfo-') or starts-with(@value, '#veri-')

Meldung

Die Referenz muss mit "#zinfo-", "#altein-", "#arzneiinfo-" oder "#veri-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:effectiveTime

IVL_TS

0 … 1

C

Constraint

Wenn eine Verifizierung, d.h. eine Überprüfung, ob das Arzneimittel wie für diese Behandlung vorgesehen wirkt, mit "veri" im code-Element oder mit "#veri-{generierteID}" im reference-Element festgelegt wird, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime-Element festgelegt werden.

hl7:entryRelationship

C

Komponente zur Aufnahme der ergänzenden Informationen zur Abgabe oder zu der magistralen Zubereitung.

wo [@typeCode='SUBJ'] [hl7:act/hl7:templateId [@root='2.16.840.1.113883.10.20.1.43']]

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

Constraint

Konditionale Konformität:

Arznei ist eine magistrale Zubereitung: Card 1..1 Conf M

Arznei ist keine magistrale Zubereitung: Card 0..1 Conf O

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.63 Medikation Pharmacist Instructions (DYNAMIC)

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.43

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3.1

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

FINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die ergänzenden Informationen zur Abgabe oder zu der magistralen Zubereitungen angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#abginfo-{generierteID}, z.B.: #abginfo-1

Schematron assert

role

error

test

starts-with(@value, '#abginfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 2

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.2

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.160 ELGA_ActCode_AbgInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#erginfo|magzub-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #magzub-1

Schematron assert

role

error

test

starts-with(@value, '#erginfo-') or starts-with(@value, '#magzub-')

Meldung

Die Referenz muss mit "#erginfo-" oder "#magzub-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

Eingefügt

0 … 1

von 1.2.40.0.34.6.0.11.9.64 Medikation Therapieart (DYNAMIC)

hl7:entryRelationship

0 … 1

Therapieart dieses MedikationVerordnung-Entry

wo [@typeCode='COMP'] [hl7:act/hl7:templateId [@root='1.2.40.0.34.11.8.1.3.4']]

@typeCode

cs

1 … 1

F

COMP

Beispiel

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.1.3.4

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.30 ELGA_MedikationTherapieArt (DYNAMIC)

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:entryRelationship

0 … *

Komponente zur Aufnahme der Indikation, dem Grund warum die Behandlung mit diesem Präperat unternommen wird.

wo [@typeCode='SUBJ'] [hl7:observation/hl7:templateId [@root='1.2.40.0.34.6.0.11.3.6']]

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.3.6 Problem Entry (DYNAMIC)

hl7:observation

1 … 1

M

Container zur Angabe eines Problems (Diagnose etc).

@classCode

cs

1 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

@negationInd

bl

1 … 1

R

SOLL standardmäßig auf false gesetzt werden.

Kann auf true gesetzt werden, um anzuzeigen, dass das dokumentierte Problem nicht beobachtet wurde.

hl7:templateId

II

1 … 1

M

ELGA

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.3.6

hl7:templateId

II

1 … 1

M

HL7 CCD Problem observation

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.28

hl7:templateId

II

1 … 1

M

IHE Problem Entry

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.5

hl7:id

II

1 … *

M

ID des Problem-Entry.

Auch wenn nur ein Problem-Entry angegeben ist, soll sich die ID von der ID des Problem/Bedenken-Entry unterscheiden.

Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

hl7:code

CD

1 … 1

M

Code des Problems.
Die Art des angegebenen Problems (Diagnose, Symptom, etc.) wird codiert in diesem Element angegeben.

Verweis auf speziellen Implementierungsleitfaden:

Welche der Problemarten angegeben werden müssen bzw. sollen, kann im jeweiligen speziellen Implementierungsleitfaden eingeschränkt werden.

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.35 atcdabbr_Problemarten_VS (DYNAMIC)

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.1 Narrative Text Reference (DYNAMIC)

hl7:text

ED

1 … 1

M

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im menschenlesbaren Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts mit Zusatzinformationen umschließen.

Alternativ kann @value auch mit dem url-scheme "http" oder "https" beginnen.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#') or starts-with(@value,'http')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element, or begin with the 'http' or 'https' url-scheme.

hl7:statusCode

CS

1 … 1

M

Muss unabhängig von effectiveTime auf „completed“ gesetzt werden. Der medizinische Status des Problems wird im entryRelationship.Problem Status Observation angegeben.

@code

CONF

1 … 1

F

completed

hl7:effectiveTime

IVL_TS

1 … 1

M

Zeitintervall, in dem das Problem existent war/ist.

Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.

hl7:low

TS.AT.VAR

1 … 1

R

„Beginn des Problems“: Entspricht dem Zeitpunkt, zu dem das Problem erstmals aufgetreten ist. Kann auch unbekannt sein (nullFlavor "UNK")

hl7:high

TS.AT.VAR

0 … 1

C

„Ende des Problems“: muss angegeben werden, wenn das Problem nicht mehr besteht.

Wenn nicht angegeben, gilt das Problem als weiterhin bestehend.

Ist kein Datum der Lösung bekannt, wird der nullFlavor "UNK" angegeben.

Auswahl

1 … 1

Gesundheitsprobleme dürfen nur wie folgt angegeben werden:

Codierte Angabe des Gesundheitsproblems:
@value enthält den Code des Gesundheitsproblems einem Value Set (ICD, ICPC2 ...).
Codierte Angabe ohne passenden Code:
xsi:type='CD', nullFlavor: OTH
In diesem Fall ist das Element <translation> verpflichtend.
originalText.reference enthält den Verweis auf die narrative Beschreibung des Problems!
Uncodierte Angabe:
xsi:type='CD', nullFlavor: NA
In diesem Fall ist die Textreferenz <originalText> verpflichtend.
originalText.reference enthält den Verweis auf die narrative Beschreibung des Problems!

Hinweis: Die Wahl des Codesystems ist abhängig von der Problemart! Für Diagnosen kann ein gültiger Code aus der vom für Gesundheit zuständigen Bundesministeriums veröffentlichen aktuellen ICD Liste herangezogen werden.

Elemente in der Auswahl:

hl7:value[not(@nullFlavor)]
hl7:value[@nullFlavor='OTH']
hl7:value[@nullFlavor='NA']

hl7:value

CD

0 … 1

Codierte Angabe des Gesundheitsproblems

Codesysteme bitte in der aktuellen Version verwenden. Z.B.:

1.2.40.0.34.5.184/192/209/222/228 - ICD (Internationalen Klassifikation der Krankheiten) in der jeweils aktuellen Fassung des für Gesundheit zuständigen Bundesministeriums
1.2.40.0.34.5.175 - ICPC2 (International Classification of Primary Care)
2.16.840.1.113883.6.254 - ICF (WHO International Classification of Function)
2.16.840.1.113883.6.96 - SNOMED CT (Systematized Nomenclature of Medicine - Clinical Terms)
etc.

wo [not(@nullFlavor)]

@xsi:type

1 … 1

F

CD

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

R

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

Eingegebener Freitext, der die Grundlage der im Entry angegebenen Information ist.
Das Element verweist auf die Stelle im Textbereich (section.text), in dem das Problem beschrieben ist (ohne zusätzliche Informationen, wie Datum, Beschreibung, etc).

Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen.

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:qualifier

CR

0 … *

R

Qualifier zur genaueren Beschreibung des Problems.

z.B. zur Angabe der Art der Diagnose.

wo [hl7:name [@code='106229004']]

hl7:name

CD

1 … 1

M

@code

CONF

1 … 1

F

106229004

@codeSystem

1 … 1

F

2.16.840.1.113883.6.96 (SNOMED Clinical Terms)

hl7:value

CD

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.23 ELGA_ArtderDiagnose (DYNAMIC)

hl7:translation

CD

0 … *

Dieses Feld wird verwendet, wenn Codes aus einem abweichenden Value Set angegeben werden.

z.B. für Übersetzungen in alternative Codesysteme oder wenn kein geeigneter Code im vorgegebene VS vorhanden ist.

hl7:value

CD

0 … 1

Codierte Angabe des Gesundheitsproblems ohne passenden Code

wo [@nullFlavor='OTH']

@xsi:type

1 … 1

F

CD

@nullFlavor

cs

1 … 1

F

OTH

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

Eingegebener Freitext, der die Grundlage der im Entry angegebenen Information ist.
Das Element verweist auf die Stelle im Textbereich (section.text), in dem das Problem beschrieben ist (ohne zusätzliche Informationen, wie Datum, Beschreibung, etc).

Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen.

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:translation

CD

1 … *

M

Dieses Feld wird verwendet, wenn Codes aus einem abweichenden Value Set angegeben werden.

z.B. für Übersetzungen in alternative Codesysteme oder wenn kein geeigneter Code im vorgegebene VS vorhanden ist.

hl7:value

CD

0 … 1

Uncodierte Angabe des Gesundheitsproblems

wo [@nullFlavor='NA']

@xsi:type

1 … 1

F

CD

@nullFlavor

cs

1 … 1

F

NA

Beispiel

Nicht-codierte Diagnosen

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

Eingegebener Freitext, der die Grundlage der im Entry angegebenen Information ist.
Das Element verweist auf die Stelle im Textbereich (section.text), in dem das Problem beschrieben ist (ohne zusätzliche Informationen, wie Datum, Beschreibung, etc).

Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen.

hl7:originalText

ED

1 … 1

M

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:targetSiteCode

CD

0 … *

R

Anatomische Lage des Problems

Beinhaltet 1.2.40.0.34.6.0.11.9.42 Laterality Qualifier (DYNAMIC)

hl7:performer

0 … *

R

Beinhaltet 1.2.40.0.34.6.0.11.9.17 Performer Body (DYNAMIC)

hl7:author

0 … *

R

Dieses Author-Element KANN verwendet werden, um anzugeben, wer das Problem dokumentiert hat. Wenn nicht angegeben, gilt das jeweils "darüberlegende" Author-Element (Section, Document)
Beinhaltet 1.2.40.0.34.6.0.11.9.36 Author Body (DYNAMIC)

hl7:informant

0 … *

R

Beinhaltet 1.2.40.0.34.6.0.11.9.3 Informant Body (DYNAMIC)

hl7:participant

0 … *

R

Beinhaltet 1.2.40.0.34.6.0.11.9.13 Participant Body (DYNAMIC)

hl7:entryRelationship

0 … *

R

Beinhaltet 1.2.40.0.34.6.0.11.3.11 Comment Entry (DYNAMIC)

@typeCode

cs

1 … 1

F

COMP

@contextConductionInd

cs

0 … 1

F

true

hl7:entryRelationship

0 … 1

R

Dieses EntryRelationship dient zur Darstellung des Schweregrads des Gesundheitsproblems

Beinhaltet 1.2.40.0.34.6.0.11.3.38 Severity Observation (DYNAMIC)

@typeCode

cs

1 … 1

F

SUBJ

@contextConductionInd

cs

0 … 1

F

true

hl7:entryRelationship

0 … 1

R

Dieses EntryRelationship dient zur Darstellung der Kritikalität des Gesundheitsproblems.
Beinhaltet 1.2.40.0.34.6.0.11.3.35 Criticality Observation (DYNAMIC)

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

@contextConductionInd

cs

0 … 1

F

true

hl7:entryRelationship

0 … 1

R

Dieses EntryRelationship dient zur Darstellung der Gewissheit, mit der das Gesundheitsproblem

Beinhaltet 1.2.40.0.34.6.0.11.3.36 Certainty Observation (DYNAMIC)

@typeCode

cs

1 … 1

F

SUBJ

@contextConductionInd

cs

0 … 1

F

true

hl7:entryRelationship

0 … 1

R

Klinischer Status des Gesundheitsproblems

Beinhaltet 1.2.40.0.34.6.0.11.3.49 Problem Status Observation (DYNAMIC)

@typeCode

cs

1 … 1

F

REFR

@contextConductionInd

cs

0 … 1

F

true

Eingefügt

0 … 1

C

von 1.2.40.0.34.6.0.11.9.65 Medikation ID des Containers (DYNAMIC)
ID des Verordnungs-Entry Containers (Rezept-Dokument)

Constraint

Konditionale Konformität für ID des Verordnungs-Entry Containers (Rezept-Dokument)

Element wird in Medikationsliste oder Pharmazeutischen Empfehlung verwendet: Card 1..1 Conf M
Element wird im Rezept verwendet: Card 0..0 Conf NP

hl7:reference

0 … 1

C

ID des Verordnungs-Entry Containers (Rezept-Dokument).

@typeCode

cs

1 … 1

F

XCRPT

hl7:externalDocument

1 … 1

M

hl7:id

II

1 … 1

M

ID des MedikationVerordnung-Entry.

@root

uid

1 … 1

F

1.2.40.0.10.1.4.3.4.2.1

@extension

st

1 … 1

R

Verpflichtende eMED-ID

7.3.4.3 Medikation Abgabe Entry eMedikation v3

Id

1.2.40.0.34.6.0.11.3.187

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑27 10:30:29

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atcdabbr_entry_MedikationAbgabeEntryemedv3

Bezeichnung

Medikation Abgabe Entry eMedikation v3

Beschreibung

In diesem Entry ist ein an den Patienten abgegebenes Arzneimittel maschinenlesbarer aufgeführt. Unter einer Abgabe versteht man die Ausgabe von Arzneimitteln oder anderen apothekenpflichtigen Produkten an den Patienten.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.3.187

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 9 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.2	Inklusion	Original Text Reference (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.3.186	Containment	Arznei Entry v3 (3.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.68	Inklusion	Medikation AssignedEntityElementsV3 (3.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.66	Inklusion	Medikation AuthorElements (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.62	Inklusion	Medikation Patient Instructions (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.63	Inklusion	Medikation Pharmacist Instructions (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.64	Inklusion	Medikation Therapieart (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.67	Containment	Medikation Altered Dosage Instructions (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.65	Inklusion	Medikation ID des Containers (1.0.0+20250228)	DYNAMIC

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:supply

@classCode

cs

1 … 1

F

SPLY

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

R

Medikation Abgabe Entry eMedikation v3

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.3.187

hl7:templateId

II

1 … 1

R

eHDSI Supply

@root

uid

1 … 1

F

1.3.6.1.4.1.12559.11.10.1.3.1.3.3

hl7:templateId

II

1 … 1

R

IHE Supply entry (IHE PCC)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.7.3

hl7:templateId

II

1 … 1

R

Supply activity (CCD)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.34

hl7:id

II

C

ID des MedikationAbgabe-Entry.

wo [1]

@root

uid

1 … 1

R

Wurzel OID der ID eines MedikationAbgabe-Entry gemäß Anwendung e-Medikation

@extension

st

1 … 1

R

AbgabeID = {eMedID}_{lokal vergebene ID}

Constraint

Für e-Medikation: ID eines MedikationAbgabe-Entries gemäß Anwendung e-Medikation: Das erste ID-Element enthält eine von Zentralkomponenten der e-Medikation vergebene neue ID des Abgabe-Entry, welche durch eine eigene OID im @root-Attribut gekennzeichnet ist. Diese neue ID ist notwendig, da das Abgabe-Entry bei Rückgabe in der Medikationsliste durch die Zentralkomponenten mit verschiedenen zusätzlichen Informationen ergänzt wird.

Nur für andere e-Befunde (also Dokumentenklassen außerhalb dieses Leitfadens, wie z.B. Entlassungsbrief ärztlich) ist eine lokale OID zulässig, sofern keine AbgabeID vorliegt.

Bedingung:
Bei Medikationsliste @root="1.2.40.0.10.1.4.3.4.2.3.1" @extension=AbgabeID

Sonst @root="1.2.40.0.10.1.4.3.4.2.3" @extension=AbgabeID

Beispiel

hl7:id

II

C

ID des ursprünglichen MedikationAbgabe-Entry (aus dem Abgabe-Dokument)

wo [2]

@root

uid

1 … 1

R

Wurzel OID der ID eines MedikationAbgabe-Entry gemäß Anwendung e-Medikation

@extension

st

1 … 1

R

AbgabeID = {eMedID}_{lokal vergebene ID}

Constraint

Für e-Medikation:
Im Abgabe-Entry der Medikationsliste oder der pharmazeutischen Empfehlung ist das zweite ID-Element verpflichtend anzugeben (1..1 M). Es muss die ID des ursprünglich im Abgabe-Dokument angegebenen Abgabe-Entry enthalten, welche den Ausgangspunkt des vorliegenden Abgabe-Entry darstellt.

Im Abgabe-Entry einer Abgabe darf das zweite id-Element nicht verwendet werden (NP).

In anderen e-Befunden kann dieses Element entfallen (0..1).

Konditionale Konformität

Abgabe-Entry liegt in Medikationsliste oder Pharmazeutischen Empfehlung vor: Card 1..1 Conf M
Abgabe-Entry in einer Abgabe: NP

Beispiel

hl7:code

CE

0 … 1

Code des MedikationAbgabe-Entry (Abgabeart). Dieses Element dient zur Kennzeichnung, ob die Abgabe eine zugrundeliegende Verordnung vollständig oder partiell (z.B. im Falle einer Bestellung) erfüllt.

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.159 ELGA_MedikationAbgabeArt (DYNAMIC)

Beispiel

Strukturbeispiel

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)
Textinhalt, der codiert wurde. Beispielsweise wo im Text die Information steht, das hier ein "First Fill - Complete" oder "Refill - Part Fill" durchgeführt wurde. Gemäß Vorgaben im „Allgemeinen Implementierungsleitfaden“, Kapitel „Codierungs-Elemente“.

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:text

ED

1 … 1

M

Verweist auf die Stelle im narrativen Text-Bereich, an der die gegebene Medikation narrativ beschrieben ist (mit zusätzlichen Informationen, wie Datum, Beschreibung, etc).

Beispiel

Strukturbeispiel

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#apos-{generierteID}, z.B.: #apos-1

hl7:quantity

PQ

1 … 1

M

Gibt die Packungsanzahl an, die zu einem Rezept abgegeben werden.

Das Attribut value muss vorhanden sein und die Packungsanzahl angeben. Bei Verschreibungen für eine Gesamtmenge (z. B. 400 Tabletten) muss das Attribut value gleich 1 sein, und die Gesamtmenge ist in das Element hl7:product/hl7:manufacturedProduct/hl7:manufacturedMaterial/pharm:asContent/pharm:quantity einzutragen. Weitere Informationen finden Sie in der Beschreibung dieses Elements.

Das Attribut unit muss vorhanden sein und der UCUM-Einheit 1 entsprechen.

@value

real

1 … 1

R

@unit

cs

1 … 1

F

1

hl7:product

1 … 1

M

Komponente zur Aufnahme der Arznei auf die sich der MedikationAbgabe-Entry bezieht.
Beinhaltet 1.2.40.0.34.6.0.11.3.186 Arznei Entry v3 (DYNAMIC)

@typeCode

cs

0 … 1

F

PRD

hl7:performer

1 … 1

R

@nullFlavor

cs

0 … 1

F

NI

@typeCode

cs

1 … 1

F

PRF

Constraint

Konditionale Konformität für die Attribute und Elemente im performer-Element:

<TBODY>

</TBODY>

C&C nullFlavor	C&C andere Attribute C&C Elemente	Prädikat
0..0 NP	wie beschrieben	Dieses Element wird in e-Medikations Medikationsliste oder eHDSI Kontext verwendet.
1..1 M	0..0 NP	Sonst

hl7:time

TS.DATE.MIN

1 … 1

R

hl7:assignedEntity

1 … 1

M

Eingefügt

von 1.2.40.0.34.6.0.11.9.68 Medikation AssignedEntityElementsV3 (DYNAMIC)

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

R

Mindestens eine Id der validierenden Person.

Zugelassene nullFlavor: UNK

hl7:addr

AD

1 … 1

R

Ein Adress-Element der validierenden Person.

Zugelassene nullFlavor: UNK

hl7:telecom

TEL.AT

1 … *

R

Mindestens ein Telecom-Element der validierenden Person.

Zugelassene nullFlavor: UNK

hl7:assignedPerson

1 … 1

M

Persondendaten der validierenden Person.

Eingefügt

von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Namen-Element (Person)

@use

cs

0 … 1

Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.

Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“.

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

hl7:prefix

ENXP

0 … *

Beliebig viele Präfixe zum Namen, z.B. Akademische Titel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!

@qualifier

cs

0 … 1

Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:family

ENXP

1 … *

M

Mindestens ein Hauptname (Nachname).

@qualifier

cs

0 … 1

Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:given

ENXP

1 … *

M

Mindestens ein Vorname

@qualifier

cs

0 … 1

Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:suffix

ENXP

0 … *

Beliebig viele Suffixe zum Namen

@qualifier

cs

0 … 1

Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:representedOrganization

0 … 1

R

Organistationsdaten der validierenden Person.

Eingefügt

von 1.2.40.0.34.6.0.11.9.5.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … *

R

Beliebig viele, mindestens eine ID der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.

@root

uid

1 … 1

R

@extension

st

0 … 1

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.

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten der Organisation.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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

1 … 1

R

Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

Schematron assert

role

error

test

count(ancestor::hl7:templateId[@root='1.2.40.0.34.6.0.11.0.23'])=0 or count(hl7:author)=2

Meldung

In einer Medikationsliste muss der Verfasser der Verordnung / der Abgabe (author-Element) angegeben werden.

Eingefügt

0 … 2

C

von 1.2.40.0.34.6.0.11.9.66 Medikation AuthorElements (DYNAMIC)

1. <author> Element: Verfasser der Verordnung zu dieser Abgabe.
Das erste <author> Element beinhaltet den Verfasser des Rezepts auf dem die Verordnung ausgestellt wurde, auf die eine Referenz existiert. Das author/time Element hat dabei die Bedeutung „Datum der Verordnung“.

Zugelassene nullFlavor: NA

Da das <author> Element im CDA Schema gewisse Unterelemente zwingend benötigt, ist ein einfaches <author nullFlavor=‘NA‘/> nicht ausreichend und würde zu einer CDA Schema Verletzung führen. Im Falle der Anwendung von nullFlavor=‘NA‘ sind demnach die erforderlichen Unterelemente mit diesem Attribut zu versehen.

Diese Elemente werden nur bei ELGA MedikationAbgabe-Entries verwendet, welche im Rahmen der Medikationsliste vorliegen.

2. <author> Element: Verfasser der Abgabe
Das zweite <author> Element beinhaltet den Verfasser der Abgabe. Das author/time Element hat dabei die Bedeutung „Datum der Abgabe“.

Diese Elemente werden nur bei ELGA MedikationAbgabe-Entries verwendet, welche im Rahmen der Medikationsliste vorliegen.

Constraint

Konditionale Konformität für die author-Elemente:

Card	Conf	Prädikat
	NP	Dieses Element wird nicht in der Medikationsliste verwendet. Die author-Elemente werden nur bei ELGA MedikationAbgabe-Entries verwendet, welche im Rahmen der Medikationsliste vorliegen.
1..	R	Dieses Element wird in der Medikationsliste verwendet, dann: wenn eine Referenz zu einer Verordnung vorhanden ist ,wird im 1. Author-Element der Verfasser der Verordnung genannt; wenn keine Referenz zu einer Verordnung vorhanden ist, muss das Author-Element null sein (siehe Beispiel)
..2	M	Dieses Element wird in der Medikationsliste verwendet, dann wird im 2. Author-Element der Verfasser der Abgabe genannt.

Beispiel

1. <author> Element: Verfasser der Verordnung, falls Referenz zu Verordnung vorhanden

<author> : Author Element, übernommen aus dem zugrundeliegenden Rezept-Dokument zu der Abgabe : </author>

Beispiel

1. <author> Element: Keine Referenz zu einer Vordnung vorhanden, Verfasser der Verordnung (1. Author-Element) ist null

Beispiel

Verfasser einer Abgabe (2. Author-Element)

Auswahl

0 … 2

Elemente in der Auswahl:

hl7:author[not(@nullFlavor)]
hl7:author[@nullFlavor]

hl7:author

Verfasser des Dokuments.

wo [not(@nullFlavor)]

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

0 … 1

Funktionscode des Verfassers des Dokuments

z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“, …

Eigene Codes und Bezeichnungen können verwendet werden.

Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.

hl7:time

TS.DATE.MIN

1 … 1

R

Der Zeitpunkt an dem das Dokument verfasst wurde. Grundsätzlich sind die Vorgaben für „ Zeit-Elemente “ zu befolgen.

Zugelassene nullFlavor: UNK

hl7:assignedAuthor

1 … 1

M

Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.

@classCode

cs

0 … 1

F

ASSIGNED

Beispiel

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System/ des/der datenerstellenden Gerätes/Software.

Grundsätzlich sind die Vorgaben für „ Identifikations-Elemente “ zu befolgen.

hl7:code

CE

0 … 1

Angabe der Fachrichtung des Verfassers des Dokuments („Sonderfach“ gem. Ausbildungsordnung) z.B: „Facharzt/Fachärzting für Gynäkologie“,

Wenn ein Autor mehreren ärztlichen Sonderfächern zugeordnet ist, kann das anzugebende Sonderfach gewählt werden. Additivfächer werden nicht angegeben.
Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.

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.

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:assignedPerson
hl7:assignedAuthoringDevice

hl7:assignedPerson

… 1

Personendaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.

Eingefügt

von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Namen-Element (Person)

@use

cs

0 … 1

Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.

Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“.

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

hl7:prefix

ENXP

0 … *

Beliebig viele Präfixe zum Namen, z.B. Akademische Titel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!

@qualifier

cs

0 … 1

Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:family

ENXP

1 … *

M

Mindestens ein Hauptname (Nachname).

@qualifier

cs

0 … 1

Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:given

ENXP

1 … *

M

Mindestens ein Vorname

@qualifier

cs

0 … 1

Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:suffix

ENXP

0 … *

Beliebig viele Suffixe zum Namen

@qualifier

cs

0 … 1

Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:assignedAuthoringDevice

… 1

@classCode

cs

0 … 1

F

DEV

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:manufacturerModelName

SC

0 … 1

Hersteller und Modellbezeichnung des datenerstellenden Gerätes.

hl7:softwareName

SC

0 … 1

Bezeichnung (und ggf Version) der datenerstellenden Software.

hl7:representedOrganization

1 … 1

M

Eingefügt

von 1.2.40.0.34.6.0.11.9.5.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … *

R

Beliebig viele, mindestens eine ID der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.

@root

uid

1 … 1

R

@extension

st

0 … 1

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.

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten der Organisation.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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

1 … 1

R

Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:author

Verfasser nicht bekannt/nicht anwendbar

wo [@nullFlavor]

@nullFlavor

cs

1 … 1

F

NA

Beispiel

hl7:time

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

hl7:assignedAuthor

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

hl7:id

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

hl7:entryRelationship

1 … 1

M

Referenz zur Verordnung per VerordnungsID. Wird für die Kompatibilität mit der eHDSI ePrescription/eDispensation immer angeführt.
Falls tatsächliche keine Verordnung vorhanden ist, ist die VerordnungsID "0" anzugeben.

ACHTUNG: Es ist immer die VerordnungsID des Verordnungs-Entry anzugeben, welches ursprünglich im Rezept-Dokument angegeben wurde, unabhängig von etwaigen darauffolgenden Korrekturen mittels Pharmazeutischer Empfehlungen.

wo [@typeCode='REFR']

@typeCode

cs

1 … 1

F

REFR

Beispiel

Strukturbeispiel

<entryRelationship typeCode="REFR">
  
  <substanceAdministration classCode="SBADM" moodCode="INT">
    <id root="1.2.40.0.10.1.4.3.4.2.2" extension="...VerordnungsID..."/>    <consumable>
      <manufacturedProduct>
        <manufacturedMaterial nullFlavor="NA"/>      </manufacturedProduct>    </consumable>  </substanceAdministration></entryRelationship>

hl7:substanceAdministration

1 … 1

M

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

hl7:id

II

1 … 1

M

VerordnungsID.

@root

uid

1 … 1

F

1.2.40.0.10.1.4.3.4.2.2

Wurzel OID der ID eines MedikationVerordnungs-Entry gemäß Anwendung e-Medikation.

@extension

st

1 … 1

R

VerordnungsID. Strukturvorschrift: VerordnungsID = {eMedID}_{lokal vergebene ID}

hl7:consumable

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.62 Medikation Patient Instructions (DYNAMIC)

hl7:act

0 … 1

R

Abbildung der Zusatzbemerkungen als untergeordnetes act-Element.

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.49

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

PINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die Zusatzinformationen für den Patienten, Informationen zur alternativen Einnahme und Informationen zur Arznei angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#patinfo-{generierteID}, z.B.: #patinfo-1

Schematron assert

role

error

test

starts-with(@value, '#patinfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 3

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.1

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.161 ELGA_ActCode_PatInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#zinfo|altein|arzneiinfo|veri-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #altein-1

Schematron assert

role

error

test

starts-with(@value, '#zinfo-') or starts-with(@value, '#altein-') or starts-with(@value, '#arzneiinfo-') or starts-with(@value, '#veri-')

Meldung

Die Referenz muss mit "#zinfo-", "#altein-", "#arzneiinfo-" oder "#veri-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:effectiveTime

IVL_TS

0 … 1

C

Constraint

Wenn eine Verifizierung, d.h. eine Überprüfung, ob das Arzneimittel wie für diese Behandlung vorgesehen wirkt, mit "veri" im code-Element oder mit "#veri-{generierteID}" im reference-Element festgelegt wird, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime-Element festgelegt werden.

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.63 Medikation Pharmacist Instructions (DYNAMIC)

hl7:act

0 … 1

R

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.43

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3.1

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

FINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die ergänzenden Informationen zur Abgabe oder zu der magistralen Zubereitungen angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#abginfo-{generierteID}, z.B.: #abginfo-1

Schematron assert

role

error

test

starts-with(@value, '#abginfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 2

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.2

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.160 ELGA_ActCode_AbgInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#erginfo|magzub-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #magzub-1

Schematron assert

role

error

test

starts-with(@value, '#erginfo-') or starts-with(@value, '#magzub-')

Meldung

Die Referenz muss mit "#erginfo-" oder "#magzub-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

0 … 1

Komponente zur Aufnahme der Zusatzinformationen für den Patienten, Informationen zur alternativen Einnahme und Informationen zur Arznei.

wo [@typeCode='SUBJ'] [hl7:act/hl7:templateId [@root='2.16.840.1.113883.10.20.1.49']]

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.62 Medikation Patient Instructions (DYNAMIC)

hl7:act

1 … 1

M

Abbildung der Zusatzbemerkungen als untergeordnetes act-Element.

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.49

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

PINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die Zusatzinformationen für den Patienten, Informationen zur alternativen Einnahme und Informationen zur Arznei angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#patinfo-{generierteID}, z.B.: #patinfo-1

Schematron assert

role

error

test

starts-with(@value, '#patinfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 3

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.1

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.161 ELGA_ActCode_PatInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#zinfo|altein|arzneiinfo|veri-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #altein-1

Schematron assert

role

error

test

starts-with(@value, '#zinfo-') or starts-with(@value, '#altein-') or starts-with(@value, '#arzneiinfo-') or starts-with(@value, '#veri-')

Meldung

Die Referenz muss mit "#zinfo-", "#altein-", "#arzneiinfo-" oder "#veri-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:effectiveTime

IVL_TS

0 … 1

C

Constraint

Wenn eine Verifizierung, d.h. eine Überprüfung, ob das Arzneimittel wie für diese Behandlung vorgesehen wirkt, mit "veri" im code-Element oder mit "#veri-{generierteID}" im reference-Element festgelegt wird, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime-Element festgelegt werden.

hl7:entryRelationship

0 … 1

Ergänzende Informationen zur Abgabe und magistralen Zubereitung.

wo [@typeCode='SUBJ'] [hl7:act/hl7:templateId [@root='2.16.840.1.113883.10.20.1.43']]

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Arznei ist eine magistrale Zubereitung
0..1	O	Arznei ist keine magistrale Zubereitung

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.63 Medikation Pharmacist Instructions (DYNAMIC)

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.43

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3.1

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

FINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die ergänzenden Informationen zur Abgabe oder zu der magistralen Zubereitungen angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#abginfo-{generierteID}, z.B.: #abginfo-1

Schematron assert

role

error

test

starts-with(@value, '#abginfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 2

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.2

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.160 ELGA_ActCode_AbgInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#erginfo|magzub-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #magzub-1

Schematron assert

role

error

test

starts-with(@value, '#erginfo-') or starts-with(@value, '#magzub-')

Meldung

Die Referenz muss mit "#erginfo-" oder "#magzub-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

Eingefügt

0 … 1

von 1.2.40.0.34.6.0.11.9.64 Medikation Therapieart (DYNAMIC)
Therapieart.
Im Falle von Abgaben zu einer Verordnung nur anzugeben, falls dieses sich von der Therapieart der Verordnung unterscheidet.

hl7:entryRelationship

0 … 1

Therapieart dieses MedikationVerordnung-Entry

wo [@typeCode='COMP'] [hl7:act/hl7:templateId [@root='1.2.40.0.34.11.8.1.3.4']]

@typeCode

cs

1 … 1

F

COMP

Beispiel

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.1.3.4

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.30 ELGA_MedikationTherapieArt (DYNAMIC)

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:entryRelationship

0 … 1

Komponente zur Aufnahme der optionalen Dosierungsinformationen.
Beinhaltet 1.2.40.0.34.6.0.11.9.67 Medikation Altered Dosage Instructions (DYNAMIC)

wo [@typeCode='COMP'] [hl7:substanceAdministration/hl7:templateId [@root='1.3.6.1.4.1.19376.1.9.1.3.6']]

@typeCode

cs

1 … 1

F

COMP

Beispiel

Strukturbeispiel

<entryRelationship typeCode="COMP">
  <substanceAdministration classCode="SBADM" moodCode="INT">
    <templateId root="1.3.6.1.4.1.19376.1.9.1.3.6"/>     : ... Einnahmedauer ... : ... Dosierungsvarianten 1 + 3 ... : ... Art der Anwendung ... :     <consumable>
      <manufacturedProduct>
        <manufacturedMaterial nullFlavor="NA"/>      </manufacturedProduct>    </consumable>     : ... Dosierungsvarianten 2 + 4 ... :   </substanceAdministration></entryRelationship>

hl7:entryRelationship

0 … 1

C

Falls das Arznei Entry in dieser Abgabe sich nicht mit dem Arznei Entry der Verordnung gleicht, wie z.B. bei Abgabe eines Generikum, MUSS dieses entryRelationship vorhanden sein.

Wenn im Gegenteil, das Arznei Entry in dieser Abgabe sich nicht mit dem Arznei Entry der Verordnung gleicht, MUSS dieses entryRelationsship entfallen.

wo [@typeCode='COMP'] [hl7:act]

@typeCode

cs

1 … 1

F

COMP

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

EVN

hl7:code

1 … 1

M

@code

CONF

1 … 1

F

SUBST

@codeSystem

1 … 1

F

2.16.840.1.113883.5.6 (HL7ActClass)

Eingefügt

0 … 1

C

von 1.2.40.0.34.6.0.11.9.65 Medikation ID des Containers (DYNAMIC)
ID des Verordnungs-Entry Containers (Abgabe-Dokument).

Wird das ELGA MedikationAbgabe-Entry im Rahmen der Medikationsliste verwendet, MUSS die ID des Abgabe-Dokuments, welches das Abgabe-Entry ursprünglich beinhaltete, angegeben sein.

Constraint

Konditionale Konformität für ID des Verordnungs-Entry Containers (Abgabe-Dokument)

Card	Conf	Prädikat
1..1	M	Element wird in Medikationsliste verwendet
	NP	Sonst

Beispiel

Strukturbeispiel

hl7:reference

0 … 1

C

ID des Verordnungs-Entry Containers (Rezept-Dokument).

@typeCode

cs

1 … 1

F

XCRPT

hl7:externalDocument

1 … 1

M

hl7:id

II

1 … 1

M

ID des MedikationVerordnung-Entry.

@root

uid

1 … 1

F

1.2.40.0.10.1.4.3.4.2.1

@extension

st

1 … 1

R

Verpflichtende eMED-ID

7.3.4.4 Medikation Pharmazeutische Empfehlung Entry eMedikation v3

Id

1.2.40.0.34.6.0.11.3.188

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 06:28:26

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atcdabbr_entry_MedikationPharmazeutischeEmpfehlungEntryV3

Bezeichnung

Medikation Pharmazeutische Empfehlung Entry eMedikation v3

Beschreibung

In diesem Entry ist die Korrekturmeldungen (Pharmazeutischen Empfehlungen) maschinenlesbarer aufgeführt. Einzelne Verordnungen können mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) verändert wie auch storniert werden. Abgaben können mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) abgesetzt werden.

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.3.188

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 3 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.2	Inklusion	Original Text Reference (1.0.0+20210219)	DYNAMIC
1.2.40.0.34.6.0.11.3.185	Inklusion	Medikation Verordnung Entry eMedikation v3 (3.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.3.187	Inklusion	Medikation Abgabe Entry eMedikation v3 (3.0.0+20250228)	DYNAMIC

Beispiel

<cda:observation classCode="OBS" moodCode="EVN">
  <templateId root="1.2.40.0.34.6.0.11.3.188"/>  <id root="1.2.40.0.10.1.4.3.4.2.4" extension="extension"/>  <code code="CANCEL" codeSystem="1.3.6.1.4.1.19376.1.9.2.1" displayName="Absetzen">
    
    <cda:translation code="BRIEFT" codeSystem="1.2.40.0.34.5.40" displayName="Brieftext"/>  </code>  <cda:text>
    <reference value="--TODO--"/>  </cda:text>  <statusCode code="completed"/>  
</cda:observation>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:observation

1 … 1

M

@classCode

cs

1 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.3.188

hl7:id

II

1 … 1

M

In diesem Element wird die PharmazeutischeEmpfehlungID angegeben. Die PharmazeutischeEmpfehlungID MUSS die eMED-ID beinhalten um eine globale Eindeutigkeit zu gewährleisten.

Strukturvorschrift: PharmazeutischeEmpfehlungID = {eMED-ID}_{lokal vergebene ID}

Beispiel: 6NW2AYSYQNSU_aaa11

@root

uid

1 … 1

F

1.2.40.0.10.1.4.3.4.2.4

Wurzel OID der ID eines MedikationPharmazeutischeEmpfehlung-Entry gemäß Projekt e-Medikation.

@extension

st

1 … 1

R

PharmazeutischeEmpfehlungID = {eMedID}_{lokal vergebene ID}

Constraint

Für e-Medikation: ID eines PharmazeutischeEmpfehlung-Entry gemäß Projekt e-Medikation: Das erste ID Element enthält eine von Zentralkomponenten der e-Medikation vergebene neue ID des PharmazeutischeEmpfehlung-Entry, welche durch eine eigene OID im @root-Attribut gekennzeichnet ist. Diese neue ID ist notwendig, da das PharmazeutischeEmpfehlung-Entry bei Rückgabe in der Medikationsliste durch die Zentralkomponenten mit verschiedenen zusätzlichen Informationen ergänzt wird.

Nur für andere e-Befunde (also Befundklassen außerhalb dieses Leitfadens, wie z.B. Entlassungsbrief ärztlich) ist eine lokale OID zulässig, sofern keine PharmazeutischeEmpfehlungID vorliegt.

Bedingung:
Bei Medikationsliste @root="1.2.40.0.10.1.4.3.4.2.4.1" @extension=PharmazeutischeEmpfehlungID

Sonst @root="1.2.40.0.10.1.4.3.4.2.4" @extension=PharmazeutischeEmpfehlungID

Beispiel

Strukturbeispiel

hl7:code

CE

1 … 1

M

Pharmazeutische Empfehlung Status.

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.72 ELGA_HealthcareFacilityTypeCode (DYNAMIC)

Beispiel

Änderung der Verordnung/Abgabe

Beispiel

Änderung der Verordnung/Abgabe mit Details

Beispiel

Absetzen der Verordnung/Abgabe

Beispiel

Absetzen der Verordnung/Abgabe mit Details

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:translation

CD

0 … 1

Der genauere Änderungs- oder Absetzungsgrund

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.98 ELGA_MedikationPharmazeutischeEmpfehlungStatusDetails (DYNAMIC)

hl7:text

ED

1 … 1

M

Verweist auf die Stelle im narrativen Text-Bereich, an der die gegebene Medikation narrativ beschrieben ist (mit zusätzlichen Informationen, wie Datum, Beschreibung, etc).

Beispiel

Strukturbeispiel

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#pepos-{generierteID}, z.B.: #pepos-1

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

Beispiel

Strukturbeispiel

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:entryRelationship[hl7:substanceAdministration]
hl7:entryRelationship[hl7:supply]

hl7:entryRelationship

0 … 1

R

Geänderte Verordnung mit der Referenz zur Verordnung im zweiten ID Element.

Bei folgenden Anwendungsfällen MUSS eine Referenz zu einer Verordnung angegeben werden:

Verordnung ändern
Verordnung stornieren

ACHTUNG: Es ist immer die VerordnungsID des Verordnungs-Entry im zweiten ID Element anzugeben, welches ursprünglich im Rezept-Dokument angegeben wurde, unabhängig von etwaigen darauffolgenden Korrekturen mittels Pharmazeutischer Empfehlungen.

wo [hl7:substanceAdministration]

@typeCode

cs

1 … 1

F

COMP

@inversionInd

bl

1 … 1

F

false

hl7:seperatableInd

BL

1 … 1

M

@value

1 … 1

F

false

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.3.185 Medikation Verordnung Entry eMedikation v3 (DYNAMIC)

hl7:substanceAdministration

1 … 1

M

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

Constraint

Bei Dosierungsart 1 "Normal dosing" oder 3 "Tagesdosierung an bestimmten Tagen" (templateId = 1.3.6.1.4.1.19376.1.5.3.1.4.7.1) wird kein entryRelationship typeCode COMP als Dosiskomponente verwendet

Wiederholung der Komponente zur Aufnahme eines Einnahmezeitpunkts und -dosis bei Dosierungsvariante 2 und 4 höchstens einmal je Zeitcode!

hl7:templateId

II

1 … 1

M

Medikation Verordnung Entry eMedikation v3

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.3.185

hl7:templateId

II

1 … 1

M

eHDSI Substance Administration

@root

uid

1 … 1

F

1.3.6.1.4.1.12559.11.10.1.3.1.3.2

hl7:templateId

II

1 … 1

M

IHE PCC Medications Entry

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.7

hl7:templateId

II

1 … 1

M

HL7 CCD 3.9

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.24

hl7:templateId

II

1 … 1

M

IHE PHARM Dosage Instructions

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.9.1.3.6

Eingefügt

von 1.2.40.0.34.6.0.11.9.48 Medikation Sbadm TemplateId Options (DYNAMIC)

„Delay Start Dosing“ Markierung bei Verwendung eines „width“ Elements in Einnahmedauer.

Siehe Kapitel 6.4.1.2.6, „Einnahmedauer“

hl7:templateId

II

C

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.21

Constraint

Konditionale Konformität

Einnahmedauer beinhaltet low/high Elemente Conf: NP
Einnahmedauer beinhaltet ein width Element: Card 1..1 Conf M

Auswahl

0 … 1

Dosierungsart, mögliche Werte:

a) Normal: @root = 1.3.6.1.4.1.19376.1.5.3.1.4.7.1

b) Split: @root = 1.3.6.1.4.1.19376.1.5.3.1.4.9

c) keine Dosierung: templateID Element entfällt vollständig.

Dosierungsart: Normal (1.3.6.1.4.1.19376.1.5.3.1.4.7.1), Split (1.3.6.1.4.1.19376.1.5.3.1.4.9) oder keine Dosierung (keine der beiden TemplateIDs)

Elemente in der Auswahl:

hl7:templateId
hl7:templateId

hl7:templateId

II

0 … 1

R

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.7.1

hl7:templateId

II

0 … 1

R

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.9

hl7:id

II

0 … 1

C

ID des MedikationVerordnungs-Entry.

wo [1]

@root

uid

1 … 1

R

Wurzel OID der ID eines MedikationVerordnungs-Entry gemäß Projekt e-Medikation.

@extension

st

1 … 1

R

VerordnungsID.

Constraint

Für e-Medikation: ID eines MedikationVerordnungs-Entry gemäß der Anwendung e-Medikation: Das erste ID-Element enthält eine von der Zentralkomponente der e-Medikation vergebene neue ID des Verordnungs-Entry, welche durch eine eigene OID im @root-Attribut gekennzeichnet ist. Diese neue ID ist notwendig, da das Verordnungs-Entry bei Rückgabe in der Medikationsliste durch die Zentralkomponenten mit verschiedenen zusätzlichen Informationen ergänzt wird.

Nur für andere e-Befunde (also Dokumentenklassen außerhalb dieses Leitfadens, wie z.B. Entlassungsbrief ärztlich) ist eine lokale OID zulässig, sofern keine VerordnungsID vorliegt.

Bedingung:
Bei Medikationsliste @root="1.2.40.0.10.1.4.3.4.2.2.1" @extension=VerordnungsID

Sonst @root="1.2.40.0.10.1.4.3.4.2.2" @extension=VerordnungsID

Beispiel

Schematron assert

role

error

test

not(ancestor::hl7:ClinicalDocument/hl7:templateId[@root='1.2.40.0.34.6.0.11.0.23']) or hl7:id[1][@root='1.2.40.0.10.1.4.3.4.2.2.1']

Meldung

Bei Medikationslisten muss die erste ID die @root OID 1.2.40.0.10.1.4.3.4.2.2.1 tragen.

Schematron assert

role

error

test

not(ancestor::hl7:ClinicalDocument/hl7:templateId[@root='1.2.40.0.34.6.0.11.0.20']) or hl7:id[1][@root='1.2.40.0.10.1.4.3.4.2.2']

Meldung

Bei Verordnungen muss die erste ID die @root OID 1.2.40.0.10.1.4.3.4.2.2 tragen.

Schematron assert

role

error

test

not(ancestor::hl7:ClinicalDocument/hl7:templateId[starts-with(@root, '1.2.40.0.34.7.8.9.3')]) or hl7:id[1]

Meldung

Für e-Medikation Dokumente muss die erste ID angegeben sein.

hl7:id

II

0 … 1

C

ID des ursprünglichen MedikationVerordnungs-Entry (nur für nicht Rezept Dokumente)

wo [2]

@root

uid

1 … 1

R

Wurzel OID der ID eines MedikationVerordnungs-Entry gemäß Projekt e-Medikation.

@extension

st

1 … 1

R

VerordnungsID.

Constraint

Für e-Medikation gilt das im Verordnungs-Entry der Medikationsliste oder der pharmazeutischen Empfehlung das zweite id-Element verpflichtend anzugeben ist (1..1 M). Es muss die ID des ursprünglich im Rezept-Dokument angegebenen Verordnungs-Entry enthalten, welche den Ausgangspunkt des vorliegenden Verordnungs-Entry darstellt.

Im Verordnungs-Entry eines Rezepts darf das zweite id-Element nicht verwendet werden (0..0 NP).

In anderen e-Befunden kann dieses Element entfallen (0..1 O).

hl7:text

ED

1 … 1

M

Verweist auf die Stelle im narrativen Text-Bereich, an der die gegebene Medikation narrativ beschrieben ist (

mit

zusätzlichen Informationen, wie Datum, Beschreibung, etc).

Beispiel

Strukturbeispiel

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#vpos-{generierteID},

z.B.: #vpos-1

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

Eingefügt

von 1.2.40.0.34.6.0.11.9.49 Medikation Einnahmedauer (DYNAMIC)

Beispiel

Strukturbeispiel

<cda:ClinicalDocument>
  
  <cda:effectiveTime xsi:type="IVL_TS">
    <cda:low value="20110527000000+0200"/>    <cda:high nullFlavor="UNK"/>  </cda:effectiveTime></cda:ClinicalDocument>

Beispiel

Strukturbeispiel

<cda:ClinicalDocument>
  
  <cda:effectiveTime xsi:type="IVL_TS">
    <cda:width value="2" unit="wk"/>  </cda:effectiveTime></cda:ClinicalDocument>

Beispiel

Strukturbeispiel

<cda:ClinicalDocument>
  
  <cda:effectiveTime xsi:type="IVL_TS">
    <cda:low nullFlavor="UNK"/>    <cda:high nullFlavor="UNK"/>  </cda:effectiveTime></cda:ClinicalDocument>

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:effectiveTime[1][hl7:low]
hl7:effectiveTime[1][hl7:width]
hl7:effectiveTime[1][@nullFlavor]

hl7:effectiveTime

IVL_TS

0 … 1

R

Zeitelement zur Dokumentation der Einnahmedauer.

wo [1] [hl7:low]

hl7:low

TS

1 … 1

R

Zeitpunkt des Einnahmestarts.
Zugelassene nullFlavor: UNK

hl7:high

TS

1 … 1

R

Zeitpunkt des Einnahmeendes.
Zugelassene nullFlavor: UNK

hl7:effectiveTime

IVL_TS

0 … 1

R

Dauer der Einnahme, wenn Einnahmestart unbekannt

wo [1] [hl7:width]

hl7:width

PQ

1 … 1

M

Dauer der Einnahme, wenn Einnahmestart unbekannt

Bemerkung: Wenn ein width Element angegeben wird, MUSS auch die templateId für „Delay Start Dosing“ angegeben werden.

Siehe Kapitel „Template IDs"

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.69 ELGA_MedikationFrequenz (DYNAMIC)

hl7:effectiveTime

IVL_TS

0 … 1

R

wo [1] [@nullFlavor]

@nullFlavor

cs

1 … 1

F

NA

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Wenn die Dosierungsvariante einer Verordnung "Split" ist, ist in der Verordnung die templateId 1.3.6.1.4.1.19376.1.5.3.1.4.9 anzugeben.
	NP	Sonst

Auswahl

… 1

Elemente in der Auswahl:

hl7:effectiveTime[hl7:period and not(hl7:phase)] eingefügt vom Template 1.2.40.0.34.6.0.11.9.50 Medikation Dosierungsvariante 1: Tagesdosierung effectiveTime (DYNAMIC)
hl7:effectiveTime[2] eingefügt vom Template 1.2.40.0.34.6.0.11.9.51 Medikation Dosierungsvariante 2: Einzeldosierung (DYNAMIC)
ein Element eingefügt vom Template 1.2.40.0.34.6.0.11.9.52 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause (DYNAMIC)
hl7:effectiveTime[2] eingefügt vom Template 1.2.40.0.34.6.0.11.9.53 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.50 Medikation Dosierungsvariante 1: Tagesdosierung effectiveTime (DYNAMIC)

hl7:effectiveTime

PIVL_TS

C

Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [hl7:period and not(hl7:phase)]

@operator

cs

1 … 1

F

A

@institutionSpecified

bl

1 … 1

F

true

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..1 M
Dosierung nicht angegeben -> NP

hl7:period

PQ

1 … 1

R

Zeitraum für den die Dosis in doseQuantity vorgesehen ist.

@value

1 … 1

F

1

@unit

cs

1 … 1

R

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.69 ELGA_MedikationFrequenz (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.51 Medikation Dosierungsvariante 2: Einzeldosierung (DYNAMIC)

hl7:effectiveTime

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [2]

Eingefügt

von 1.2.40.0.34.6.0.11.9.52 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause (DYNAMIC)

Auswahl

… 1

Elemente in der Auswahl:

hl7:effectiveTime[hl7:period and hl7:phase]
hl7:effectiveTime[hl7:comp]

hl7:effectiveTime

PIVL_TS

C

Für EIN Wochentag.
Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [hl7:period and hl7:phase]

@operator

cs

1 … 1

F

A

hl7:phase

IVL_TS

1 … 1

R

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag)

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:effectiveTime

SXPR_TS

C

Für mehrere Wochentage, z. B. wöchtentlich montags und mittwochs

wo [hl7:comp]

@operator

cs

1 … 1

F

A

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..1 M
Dosierung nicht angegeben -> NP

1. Komponentencontainer ohne @operator, ggf. folgende Komponentencontainer mit @operator=I

hl7:comp

PIVL_TS

1 … 1

R

Komponentencontainer.

wo [not(@operator)]

hl7:phase

IVL_TS

1 … 1

R

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag)

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:comp

PIVL_TS

0 … *

wo [@operator='I']

@operator

cs

1 … 1

F

I

hl7:phase

IVL_TS

1 … 1

R

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

Eingefügt

von 1.2.40.0.34.6.0.11.9.53 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause (DYNAMIC)

hl7:effectiveTime

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [2]

Schematron report

role

warning

test

not(not(hl7:templateId[@root='1.3.6.1.4.1.19376.1.5.3.1.4.7.1']) or hl7:effectiveTime[2])

Meldung

effectiveTime[2] muss in den Dosierungsvarianten 1 und 3 anwesend sein

Schematron report

role

warning

test

hl7:templateId[@root='1.3.6.1.4.1.19376.1.5.3.1.4.9'] and hl7:effectiveTime[2]

Meldung

effectiveTime[2] darf in den Dosierungsvariante 'Split dosing' nicht anwesend sein

hl7:repeatNumber

IVL_INT

1 … 1

R

Anzahl der Einlösungen. Muss größer gleich 0 sein.

Dieses Element MUSS angegeben werden. Dieses Element beschreibt die mögliche maximale Anzahl von zusätzlichen Einlösungen dieser Verordnung. Bei Verwendung in der Medikationsliste wird immer der ursprüngliche Wert angegeben (ändert sich nicht nach einer Einlösung).

Beispiele :

Ein Wert von „0“ bedeutet, dass die Verordnung kein weiteres Mal eingelöst werden kann (Standardfall)
Ein Wert von „3“ bedeutet, dass die Verordnung insgesamt vier Mal eingelöst werden kann.

Alle Verordnungen eines Rezepts MÜSSEN denselben Wert aufweisen.
Zugelassene nullFlavor: MSK

Wird die Anzahl der zusätzlichen Einlösungen nicht angegeben (nullFlavor = MSK, Maskiert), kann die Anzahl vom empfangenden System nur mit 0 angenommen werden (keine zusätzlichen Einlösungen).

Maximale Anzahl der zusätzlichen Einlösungen

Bei Kassenrezepten:

Fixer Wert: 0

Bei Privatrezepten:

Maximaler Wert: 5

Beispiel

Strukturbeispiel

hl7:routeCode

CE

1 … 1

M

Art der Anwendung der Arznei. Kann bei codierten Arzneien aus der ASP-Liste entnommen werden.

Constraint

Für die e-Medikation ist das CodeSystem 1.2.40.0.10.1.4.3.4.3.4 zu verwenden.

Für den eHDSI Kontext ist das CodeSystem 0.4.0.127.0.16.1.1.2.1 zu verwenden.

Beispiel

e-Medikation

Beispiel

eHDSI ePrescription/eDispensation

Auswahl

… 1

Elemente in der Auswahl:

ein Element eingefügt vom Template 1.2.40.0.34.6.0.11.9.54 Medikation Dosierungsvariante 1: Tagesdosierung doseQuantity (DYNAMIC)
hl7:doseQuantity eingefügt vom Template 1.2.40.0.34.6.0.11.9.55 Medikation Dosierungsvariante 2: Einzeldosierung doseQuantity (DYNAMIC)
ein Element eingefügt vom Template 1.2.40.0.34.6.0.11.9.56 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity (DYNAMIC)
hl7:doseQuantity eingefügt vom Template 1.2.40.0.34.6.0.11.9.57 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.54 Medikation Dosierungsvariante 1: Tagesdosierung doseQuantity (DYNAMIC)

Auswahl

… 1

Elemente in der Auswahl:

hl7:doseQuantity[not(hl7:low|hl7:high)]
hl7:doseQuantity[hl7:low|hl7:high]

Constraint

Konditionale Konformität:
Menge in nicht-zählbaren Einheiten -> @unit 1..1 (required) aus Value-Set ELGA_MedikationMengenart
Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.) -> @unit 0..1 (otional) mit @unit aus Value-Set ELGA_MedikationMengenartAlternativ

hl7:doseQuantity

IVL_PQ

R

Dosis.
mit doseQuantity als IVL_PQ, aber als PQ instantiiert

wo [not(hl7:lowoder
hl7:high)]

@value

1 … 1

R

Tagesdosierung.

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:doseQuantity

IVL_PQ

R

mit doseQuantity als IVL_PQ

wo [hl7:lowoder
hl7:high]

hl7:low

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:high

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.55 Medikation Dosierungsvariante 2: Einzeldosierung doseQuantity (DYNAMIC)

hl7:doseQuantity

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Dosis bei Dosierungsvariante 1 und 3.

Eingefügt

von 1.2.40.0.34.6.0.11.9.56 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity (DYNAMIC)

Auswahl

… 1

Elemente in der Auswahl:

hl7:doseQuantity[not(hl7:low|hl7:high)]
hl7:doseQuantity[hl7:low|hl7:high]

Constraint

Konditionale Konformität:
Menge in nicht-zählbaren Einheiten -> @unit 1..1 (required) aus Value-Set ELGA_MedikationMengenart
Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.) -> @unit 0..1 (optional) aus Value-Set ELGA_MedikationMengenartAlternativ

hl7:doseQuantity

IVL_PQ

R

Dosis.
mit doseQuantity als IVL_PQ, aber als PQ instantiiert

wo [not(hl7:lowoder
hl7:high)]

@value

1 … 1

R

Tagesdosierung.

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:doseQuantity

IVL_PQ

R

mit doseQuantity als IVL_PQ

wo [hl7:lowoder
hl7:high]

hl7:low

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:high

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.57 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity (DYNAMIC)

hl7:doseQuantity

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Dosis bei Dosierungsvariante 1 und 3.

Schematron report

role

warning

test

not(not(hl7:templateId[@root='1.3.6.1.4.1.19376.1.5.3.1.4.7.1']) or hl7:doseQuantity)

Meldung

doseQuantity muss in den Dosierungsvarianten 1 und 3 anwesend sein

Schematron report

role

warning

test

hl7:templateId[@root='1.3.6.1.4.1.19376.1.5.3.1.4.9'] and hl7:doseQuantity

Meldung

doseQuantity darf in den Dosierungsvariante 'Split dosing' nicht anwesend sein

hl7:consumable

1 … 1

M

Komponente zur Aufnahme der Arznei auf die sich der MedikationVerordnungs-Entry bezieht.
Beinhaltet 1.2.40.0.34.6.0.11.3.186 Arznei Entry v3 (DYNAMIC)

@typeCode

cs

1 … 1

F

CSM

Beispiel

Strukturbeispiel

Eingefügt

C

von 1.2.40.0.34.6.0.11.1.2.2.1 Author v2 Prescriber (DYNAMIC)

Dieses Element wird nur bei ELGA MedikationVerordnungs-Entrys verwendet, welche im Rahmen der Medikationsliste vorliegen.

Es beinhaltet den Verfasser des Rezepts auf dem diese Verordnung ausgestellt wurde. Das author/time Element hat dabei die Bedeutung „Datum der Verordnung“.

Siehe Kapitel „Teilnehmende Parteien“, Abschnitt „Verfasser des Dokuments (author)“ (bezogen auf das Rezept-Dokument).

Constraint

Konditionale Konformität :

Element wird in Medikationsliste verwendet und eine Referenz zu einer Verdnung ist vorhanden: Card 1..1 Conf M

Sonst NP

hl7:author

C

Verfasser des Dokuments.

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

1 … 1

M

Internationaler Funktionscode des Verfassers des Dokuments, z.B: „Generalist medical practitioners“, „Specialist medical practitioners“,„Nursing professionals“.

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

F

2.16.840.1.113883.2.9.6.2.7

@codeSystemName

st

1 … 1

F

ISCO-08

@displayName

st

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.3.6.1.4.1.12559.11.10.1.3.1.42.1 eHDSIHealthcareProfessionalRole (DYNAMIC)

Auswahl

1 … 1

Der Zeitpunkt, zu 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

wo [not(@nullFlavor)]

hl7:time

TS.AT.TZ

0 … 1

wo [@nullFlavor='UNK']

@nullFlavor

cs

1 … 1

F

UNK

hl7:assignedAuthor

1 … 1

M

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System des/der datenerstellenden Gerätes/Software.

ODER Identifikation des/der datenerstellenden Gerätes/Software.

Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NA“ haben und es dürfen keine anderen Attribute vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein und es muss mindestens ein Attribut vorhanden sein

@nullFlavor

cs

0 … 1

F

NA

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.

@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:addr

AD

1 … *

R

Angabe der Adresse des Verfassers des Dokuments
Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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.

hl7:assignedPerson

1 … 1

M

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)

hl7:representedOrganization

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 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.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

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

von 1.2.40.0.34.6.0.11.9.58 Medikation Dosierungsvariante 2: Einzeldosierung entryRelationship (DYNAMIC)

hl7:entryRelationship

C

Komponente zur Aufnahme eines Einnahmezeitpunkts und –dosis bei Dosierungsvariante 2 und 4.

Wiederholung höchstens einmal je Zeitcode!

wo [hl7:substanceAdministration/hl7:effectiveTime [@xsi:type='EIVL_TS']]

@typeCode

cs

1 … 1

F

COMP

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..* M
Dosierung nicht angegeben -> NP

hl7:sequenceNumber

INT

1 … 1

M

Aufsteigende Nummerierung der Unterelemente.

Eingefügt

von 1.2.40.0.34.6.0.11.9.59 Medikation Splitdose-Einnahmezeitpunkte 1 (DYNAMIC)

hl7:substanceAdministration

1 … 1

M

Abbildung eines Einnahmezeitpunkts und –dosis als untergeordnetes substanceAdministration-Element.

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Menge in nicht-zählbaren Einheiten, zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS"
0..1	O	Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.), zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS" oder Freitext

hl7:effectiveTime

EIVL_TS

1 … 1

M

Zeitelement zur Aufnahme des Einnahmezeitpunkts.

wo [@xsi:type='EIVL_TS']

hl7:event

1 … 1

M

Einnahmezeitpunkt.

@code

cs

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.59 ELGA_Einnahmezeitpunkte (DYNAMIC)

hl7:offset

IVL_PQ

1 … 1

M

Zeitversatz (immer mit 0 Sekunden angegeben).

@value

1 … 1

F

0

@unit

cs

1 … 1

F

s

hl7:doseQuantity

IVL_PQ

1 … 1

M

Dosis.

hl7:consumable

1 … 1

M

hl7:manufacturedProduct

1 … 1

M

hl7:manufacturedMaterial

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

Eingefügt

von 1.2.40.0.34.6.0.11.9.60 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship (DYNAMIC)

hl7:entryRelationship

C

Komponente zur Aufnahme eines Einnahmezeitpunkts und –dosis bei Dosierungsvariante 2 und 4.

Wiederholung höchstens einmal je Zeitcode!

wo [hl7:substanceAdministration/hl7:effectiveTime [@xsi:type='SXPR_TS']]

@typeCode

cs

1 … 1

F

COMP

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..* M
Dosierung nicht angegeben -> NP

hl7:sequenceNumber

INT

1 … 1

M

Aufsteigende Nummerierung der Unterelemente.

Eingefügt

von 1.2.40.0.34.6.0.11.9.61 Medikation Splitdose-Einnahmezeitpunkte 2 (DYNAMIC)

hl7:substanceAdministration

1 … 1

M

Abbildung eines Einnahmezeitpunkts und –dosis als untergeordnetes substanceAdministration-Element.

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Menge in nicht-zählbaren Einheiten, zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS"
0..1	O	Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.), zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS" oder Freitext

hl7:effectiveTime

SXPR_TS

1 … 1

M

Zeitelement zur Aufnahme des Einnahmezeitpunkts.

wo [@xsi:type='SXPR_TS']

Constraint

Die comp-Komponenten mit PIVL_TS müssen bei allen Einnahmezeitpunkten gleich angegeben werden!

1. Komponentencontainer mit @operator=A, ggf. folgende Komponentencontainer mit @operator=I

hl7:comp

EIVL_TS

1 … 1

M

Komponentencontainer

wo [@xsi:type='EIVL_TS']

hl7:event

1 … 1

M

Einnahmezeitpunkt.

@code

cs

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.59 ELGA_Einnahmezeitpunkte (DYNAMIC)

hl7:offset

IVL_PQ

1 … 1

M

Zeitversatz (immer mit 0 Sekunden angegeben).

@value

1 … 1

F

0

@unit

cs

1 … 1

F

s

hl7:comp

PIVL_TS

1 … 1

M

Komponentencontainer zur Aufnahme der Einnahmetage.
Diese Komponenten MÜSSEN bei allen Einnahmezeitpunkten (SequenceNumber) gleich angegeben werden!

wo [@xsi:type='PIVL_TS'] [@operator='A']

@operator

cs

1 … 1

F

A

hl7:phase

IVL_TS

1 … 1

R

Phase der Einnahme.

hl7:value

TS

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag).

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:comp

PIVL_TS

0 … *

2.+ Komponentencontainer zur Aufnahme der Einnahmetage

wo [@xsi:type='PIVL_TS'] [@operator='I']

hl7:phase

IVL_TS

1 … 1

R

hl7:value

TS

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:doseQuantity

IVL_PQ

1 … 1

M

Dosis.

hl7:consumable

1 … 1

M

hl7:manufacturedProduct

1 … 1

M

hl7:manufacturedMaterial

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

Schematron assert

role

error

test

not(hl7:templateId[@root='1.3.6.1.4.1.19376.1.5.3.1.4.7.1']) or not(hl7:entryRelationship[@typeCode='COMP'][hl7:substanceAdministration])

Meldung

Bei Dosierungsart 1 "Normal dosing" oder 3 "Tagesdosierung an bestimmten Tagen" (templateId = 1.3.6.1.4.1.19376.1.5.3.1.4.7.1) wird kein entryRelationship typeCode COMP als Dosiskomponente verwendet

Variable let

Name

seq

Value

hl7:entryRelationship/hl7:substanceAdministration/hl7:effectiveTime[@value='0']//hl7:event/@code

Schematron assert

role

error

test

empty($seq[position() = index-of($seq,.)[2]])

Meldung

Wiederholung der Komponente zur Aufnahme eines Einnahmezeitpunkts und -dosis bei Dosierungsvariante 2 und 4 höchstens einmal je Zeitcode!

hl7:entryRelationship

1 … 1

M

Komponente zur Aufnahme der Packungsanzahl.

Da sich die Angaben zur Arznei (siehe Vorkapitel) jeweils auf eine Packung der Arznei beziehen, MUSS die Anzahl der auszugebenden Packungen der Arznei in einer eigenen Komponente zusätzlich angegeben werden (mindestens 1). Bei magistralen Zubereitungen wird die Anzahl der auszugebenden Einheiten der Arznei in derselben Art und Weise gehandhabt wie bei Arzneispezialitäten. Die Menge einer Einheit der Arznei (z.B. 200g einer magistral zubereiteten Salbe in einer gewissen Zusammensetzung) ist in den ergänzenden Informationen zu der magistralen Zubereitung anzugeben.

wo [@typeCode='COMP'] [hl7:supply]

@typeCode

cs

1 … 1

F

COMP

Beispiel

Strukturbeispiel

hl7:supply

1 … 1

M

Abbildung der Packungsanzahl als untergeordnetes supply-Element.

@classCode

cs

1 … 1

F

SPLY

@moodCode

cs

1 … 1

F

RQO

Beispiel

hl7:independentInd

BL

1 … 1

M

Indikator, ob die Komponente unabhängig verwendet werden darf.

@value

1 … 1

F

false

hl7:quantity

PQ

1 … 1

M

Gibt die Packungsanzahl an, die verschrieben werden. Muss größer gleich 1 sein.

Das Attribut value muss vorhanden sein und die Packungsanzahl angeben. Bei Verschreibungen für eine Gesamtmenge (z. B. 400 Tabletten) muss das Attribut value gleich 1 sein, und die Gesamtmenge ist in das Element hl7:consumable/hl7:manufacturedProduct/hl7:manufacturedMaterial/pharm:asContent/pharm:containerPackagedProduct/pharm:quantity einzutragen. Weitere Informationen finden Sie in der Beschreibung dieses Elements.

Das Attribut unit muss vorhanden sein und der UCUM-Einheit 1 entsprechen.

@value

real

1 … 1

R

@unit

cs

1 … 1

F

1

hl7:entryRelationship

0 … 1

Komponente zur Aufnahme der Zusatzinformationen, Informationen zur alternativen Einnahme und Informationen zur Arznei

wo [@typeCode='SUBJ'] [hl7:act/hl7:templateId [@root='2.16.840.1.113883.10.20.1.49']]

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.62 Medikation Patient Instructions (DYNAMIC)

hl7:act

1 … 1

M

Abbildung der Zusatzbemerkungen als untergeordnetes act-Element.

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.49

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

PINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die Zusatzinformationen für den Patienten, Informationen zur alternativen Einnahme und Informationen zur Arznei angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#patinfo-{generierteID}, z.B.: #patinfo-1

Schematron assert

role

error

test

starts-with(@value, '#patinfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 3

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.1

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.161 ELGA_ActCode_PatInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#zinfo|altein|arzneiinfo|veri-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #altein-1

Schematron assert

role

error

test

starts-with(@value, '#zinfo-') or starts-with(@value, '#altein-') or starts-with(@value, '#arzneiinfo-') or starts-with(@value, '#veri-')

Meldung

Die Referenz muss mit "#zinfo-", "#altein-", "#arzneiinfo-" oder "#veri-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:effectiveTime

IVL_TS

0 … 1

C

Constraint

Wenn eine Verifizierung, d.h. eine Überprüfung, ob das Arzneimittel wie für diese Behandlung vorgesehen wirkt, mit "veri" im code-Element oder mit "#veri-{generierteID}" im reference-Element festgelegt wird, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime-Element festgelegt werden.

hl7:entryRelationship

C

Komponente zur Aufnahme der ergänzenden Informationen zur Abgabe oder zu der magistralen Zubereitung.

wo [@typeCode='SUBJ'] [hl7:act/hl7:templateId [@root='2.16.840.1.113883.10.20.1.43']]

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

Constraint

Konditionale Konformität:

Arznei ist eine magistrale Zubereitung: Card 1..1 Conf M

Arznei ist keine magistrale Zubereitung: Card 0..1 Conf O

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.63 Medikation Pharmacist Instructions (DYNAMIC)

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.43

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3.1

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

FINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die ergänzenden Informationen zur Abgabe oder zu der magistralen Zubereitungen angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#abginfo-{generierteID}, z.B.: #abginfo-1

Schematron assert

role

error

test

starts-with(@value, '#abginfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 2

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.2

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.160 ELGA_ActCode_AbgInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#erginfo|magzub-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #magzub-1

Schematron assert

role

error

test

starts-with(@value, '#erginfo-') or starts-with(@value, '#magzub-')

Meldung

Die Referenz muss mit "#erginfo-" oder "#magzub-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

Eingefügt

0 … 1

von 1.2.40.0.34.6.0.11.9.64 Medikation Therapieart (DYNAMIC)

hl7:entryRelationship

0 … 1

Therapieart dieses MedikationVerordnung-Entry

wo [@typeCode='COMP'] [hl7:act/hl7:templateId [@root='1.2.40.0.34.11.8.1.3.4']]

@typeCode

cs

1 … 1

F

COMP

Beispiel

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.1.3.4

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.30 ELGA_MedikationTherapieArt (DYNAMIC)

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:entryRelationship

0 … *

Komponente zur Aufnahme der Indikation, dem Grund warum die Behandlung mit diesem Präperat unternommen wird.

wo [@typeCode='SUBJ'] [hl7:observation/hl7:templateId [@root='1.2.40.0.34.6.0.11.3.6']]

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.3.6 Problem Entry (DYNAMIC)

hl7:observation

1 … 1

M

Container zur Angabe eines Problems (Diagnose etc).

@classCode

cs

1 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

@negationInd

bl

1 … 1

R

SOLL standardmäßig auf false gesetzt werden.

Kann auf true gesetzt werden, um anzuzeigen, dass das dokumentierte Problem nicht beobachtet wurde.

hl7:templateId

II

1 … 1

M

ELGA

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.3.6

hl7:templateId

II

1 … 1

M

HL7 CCD Problem observation

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.28

hl7:templateId

II

1 … 1

M

IHE Problem Entry

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.5

hl7:id

II

1 … *

M

ID des Problem-Entry.

Auch wenn nur ein Problem-Entry angegeben ist, soll sich die ID von der ID des Problem/Bedenken-Entry unterscheiden.

Grundsätzlich sind die Vorgaben für „Identifikations-Elemente“ zu befolgen.

hl7:code

CD

1 … 1

M

Code des Problems.
Die Art des angegebenen Problems (Diagnose, Symptom, etc.) wird codiert in diesem Element angegeben.

Verweis auf speziellen Implementierungsleitfaden:

Welche der Problemarten angegeben werden müssen bzw. sollen, kann im jeweiligen speziellen Implementierungsleitfaden eingeschränkt werden.

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.35 atcdabbr_Problemarten_VS (DYNAMIC)

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.1 Narrative Text Reference (DYNAMIC)

hl7:text

ED

1 … 1

M

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im menschenlesbaren Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts mit Zusatzinformationen umschließen.

Alternativ kann @value auch mit dem url-scheme "http" oder "https" beginnen.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#') or starts-with(@value,'http')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element, or begin with the 'http' or 'https' url-scheme.

hl7:statusCode

CS

1 … 1

M

Muss unabhängig von effectiveTime auf „completed“ gesetzt werden. Der medizinische Status des Problems wird im entryRelationship.Problem Status Observation angegeben.

@code

CONF

1 … 1

F

completed

hl7:effectiveTime

IVL_TS

1 … 1

M

Zeitintervall, in dem das Problem existent war/ist.

Grundsätzlich sind die Vorgaben für „Zeit-Elemente“ zu befolgen.

hl7:low

TS.AT.VAR

1 … 1

R

„Beginn des Problems“: Entspricht dem Zeitpunkt, zu dem das Problem erstmals aufgetreten ist. Kann auch unbekannt sein (nullFlavor "UNK")

hl7:high

TS.AT.VAR

0 … 1

C

„Ende des Problems“: muss angegeben werden, wenn das Problem nicht mehr besteht.

Wenn nicht angegeben, gilt das Problem als weiterhin bestehend.

Ist kein Datum der Lösung bekannt, wird der nullFlavor "UNK" angegeben.

Auswahl

1 … 1

Gesundheitsprobleme dürfen nur wie folgt angegeben werden:

Codierte Angabe des Gesundheitsproblems:
@value enthält den Code des Gesundheitsproblems einem Value Set (ICD, ICPC2 ...).
Codierte Angabe ohne passenden Code:
xsi:type='CD', nullFlavor: OTH
In diesem Fall ist das Element <translation> verpflichtend.
originalText.reference enthält den Verweis auf die narrative Beschreibung des Problems!
Uncodierte Angabe:
xsi:type='CD', nullFlavor: NA
In diesem Fall ist die Textreferenz <originalText> verpflichtend.
originalText.reference enthält den Verweis auf die narrative Beschreibung des Problems!

Hinweis: Die Wahl des Codesystems ist abhängig von der Problemart! Für Diagnosen kann ein gültiger Code aus der vom für Gesundheit zuständigen Bundesministeriums veröffentlichen aktuellen ICD Liste herangezogen werden.

Elemente in der Auswahl:

hl7:value[not(@nullFlavor)]
hl7:value[@nullFlavor='OTH']
hl7:value[@nullFlavor='NA']

hl7:value

CD

0 … 1

Codierte Angabe des Gesundheitsproblems

Codesysteme bitte in der aktuellen Version verwenden. Z.B.:

1.2.40.0.34.5.184/192/209/222/228 - ICD (Internationalen Klassifikation der Krankheiten) in der jeweils aktuellen Fassung des für Gesundheit zuständigen Bundesministeriums
1.2.40.0.34.5.175 - ICPC2 (International Classification of Primary Care)
2.16.840.1.113883.6.254 - ICF (WHO International Classification of Function)
2.16.840.1.113883.6.96 - SNOMED CT (Systematized Nomenclature of Medicine - Clinical Terms)
etc.

wo [not(@nullFlavor)]

@xsi:type

1 … 1

F

CD

@code

cs

1 … 1

R

@codeSystem

oid

1 … 1

R

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

Eingegebener Freitext, der die Grundlage der im Entry angegebenen Information ist.
Das Element verweist auf die Stelle im Textbereich (section.text), in dem das Problem beschrieben ist (ohne zusätzliche Informationen, wie Datum, Beschreibung, etc).

Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen.

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:qualifier

CR

0 … *

R

Qualifier zur genaueren Beschreibung des Problems.

z.B. zur Angabe der Art der Diagnose.

wo [hl7:name [@code='106229004']]

hl7:name

CD

1 … 1

M

@code

CONF

1 … 1

F

106229004

@codeSystem

1 … 1

F

2.16.840.1.113883.6.96 (SNOMED Clinical Terms)

hl7:value

CD

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.23 ELGA_ArtderDiagnose (DYNAMIC)

hl7:translation

CD

0 … *

Dieses Feld wird verwendet, wenn Codes aus einem abweichenden Value Set angegeben werden.

z.B. für Übersetzungen in alternative Codesysteme oder wenn kein geeigneter Code im vorgegebene VS vorhanden ist.

hl7:value

CD

0 … 1

Codierte Angabe des Gesundheitsproblems ohne passenden Code

wo [@nullFlavor='OTH']

@xsi:type

1 … 1

F

CD

@nullFlavor

cs

1 … 1

F

OTH

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

Eingegebener Freitext, der die Grundlage der im Entry angegebenen Information ist.
Das Element verweist auf die Stelle im Textbereich (section.text), in dem das Problem beschrieben ist (ohne zusätzliche Informationen, wie Datum, Beschreibung, etc).

Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen.

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:translation

CD

1 … *

M

Dieses Feld wird verwendet, wenn Codes aus einem abweichenden Value Set angegeben werden.

z.B. für Übersetzungen in alternative Codesysteme oder wenn kein geeigneter Code im vorgegebene VS vorhanden ist.

hl7:value

CD

0 … 1

Uncodierte Angabe des Gesundheitsproblems

wo [@nullFlavor='NA']

@xsi:type

1 … 1

F

CD

@nullFlavor

cs

1 … 1

F

NA

Beispiel

Nicht-codierte Diagnosen

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

Eingegebener Freitext, der die Grundlage der im Entry angegebenen Information ist.
Das Element verweist auf die Stelle im Textbereich (section.text), in dem das Problem beschrieben ist (ohne zusätzliche Informationen, wie Datum, Beschreibung, etc).

Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen.

hl7:originalText

ED

1 … 1

M

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:targetSiteCode

CD

0 … *

R

Anatomische Lage des Problems

Beinhaltet 1.2.40.0.34.6.0.11.9.42 Laterality Qualifier (DYNAMIC)

hl7:performer

0 … *

R

Beinhaltet 1.2.40.0.34.6.0.11.9.17 Performer Body (DYNAMIC)

hl7:author

0 … *

R

Dieses Author-Element KANN verwendet werden, um anzugeben, wer das Problem dokumentiert hat. Wenn nicht angegeben, gilt das jeweils "darüberlegende" Author-Element (Section, Document)
Beinhaltet 1.2.40.0.34.6.0.11.9.36 Author Body (DYNAMIC)

hl7:informant

0 … *

R

Beinhaltet 1.2.40.0.34.6.0.11.9.3 Informant Body (DYNAMIC)

hl7:participant

0 … *

R

Beinhaltet 1.2.40.0.34.6.0.11.9.13 Participant Body (DYNAMIC)

hl7:entryRelationship

0 … *

R

Beinhaltet 1.2.40.0.34.6.0.11.3.11 Comment Entry (DYNAMIC)

@typeCode

cs

1 … 1

F

COMP

@contextConductionInd

cs

0 … 1

F

true

hl7:entryRelationship

0 … 1

R

Dieses EntryRelationship dient zur Darstellung des Schweregrads des Gesundheitsproblems

Beinhaltet 1.2.40.0.34.6.0.11.3.38 Severity Observation (DYNAMIC)

@typeCode

cs

1 … 1

F

SUBJ

@contextConductionInd

cs

0 … 1

F

true

hl7:entryRelationship

0 … 1

R

Dieses EntryRelationship dient zur Darstellung der Kritikalität des Gesundheitsproblems.
Beinhaltet 1.2.40.0.34.6.0.11.3.35 Criticality Observation (DYNAMIC)

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

@contextConductionInd

cs

0 … 1

F

true

hl7:entryRelationship

0 … 1

R

Dieses EntryRelationship dient zur Darstellung der Gewissheit, mit der das Gesundheitsproblem

Beinhaltet 1.2.40.0.34.6.0.11.3.36 Certainty Observation (DYNAMIC)

@typeCode

cs

1 … 1

F

SUBJ

@contextConductionInd

cs

0 … 1

F

true

hl7:entryRelationship

0 … 1

R

Klinischer Status des Gesundheitsproblems

Beinhaltet 1.2.40.0.34.6.0.11.3.49 Problem Status Observation (DYNAMIC)

@typeCode

cs

1 … 1

F

REFR

@contextConductionInd

cs

0 … 1

F

true

Eingefügt

0 … 1

C

von 1.2.40.0.34.6.0.11.9.65 Medikation ID des Containers (DYNAMIC)
ID des Verordnungs-Entry Containers (Rezept-Dokument)

Constraint

Konditionale Konformität für ID des Verordnungs-Entry Containers (Rezept-Dokument)

Element wird in Medikationsliste oder Pharmazeutischen Empfehlung verwendet: Card 1..1 Conf M
Element wird im Rezept verwendet: Card 0..0 Conf NP

hl7:reference

0 … 1

C

ID des Verordnungs-Entry Containers (Rezept-Dokument).

@typeCode

cs

1 … 1

F

XCRPT

hl7:externalDocument

1 … 1

M

hl7:id

II

1 … 1

M

ID des MedikationVerordnung-Entry.

@root

uid

1 … 1

F

1.2.40.0.10.1.4.3.4.2.1

@extension

st

1 … 1

R

Verpflichtende eMED-ID

hl7:entryRelationship

0 … 1

R

Geänderte Abgabe mit der Referenz zur Abgabe im zweiten ID Element.

Bei folgenden Anwendungsfällen MUSS eine Referenz zu einer Abgabe angegeben werden:

Abgabe ändern
Abgabe absetzen

ACHTUNG: Es ist immer die AbgabeID des Abgabe-Entry im zweiten ID Element anzugeben, welches ursprünglich im Abgabe-Dokument angegeben wurde, unabhängig von etwaigen darauffolgenden Korrekturen mittels Pharmazeutischer Empfehlungen.

wo [hl7:supply]

@typeCode

cs

1 … 1

F

COMP

@inversionInd

bl

1 … 1

F

false

hl7:seperatableInd

BL

1 … 1

M

@value

1 … 1

F

false

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.3.187 Medikation Abgabe Entry eMedikation v3 (DYNAMIC)

hl7:supply

1 … 1

M

@classCode

cs

1 … 1

F

SPLY

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

R

Medikation Abgabe Entry eMedikation v3

@root

uid

1 … 1

F

1.2.40.0.34.6.0.11.3.187

hl7:templateId

II

1 … 1

R

eHDSI Supply

@root

uid

1 … 1

F

1.3.6.1.4.1.12559.11.10.1.3.1.3.3

hl7:templateId

II

1 … 1

R

IHE Supply entry (IHE PCC)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.7.3

hl7:templateId

II

1 … 1

R

Supply activity (CCD)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.34

hl7:id

II

C

ID des MedikationAbgabe-Entry.

wo [1]

@root

uid

1 … 1

R

Wurzel OID der ID eines MedikationAbgabe-Entry gemäß Anwendung e-Medikation

@extension

st

1 … 1

R

AbgabeID = {eMedID}_{lokal vergebene ID}

Constraint

Für e-Medikation: ID eines MedikationAbgabe-Entries gemäß Anwendung e-Medikation: Das erste ID-Element enthält eine von Zentralkomponenten der e-Medikation vergebene neue ID des Abgabe-Entry, welche durch eine eigene OID im @root-Attribut gekennzeichnet ist. Diese neue ID ist notwendig, da das Abgabe-Entry bei Rückgabe in der Medikationsliste durch die Zentralkomponenten mit verschiedenen zusätzlichen Informationen ergänzt wird.

Nur für andere e-Befunde (also Dokumentenklassen außerhalb dieses Leitfadens, wie z.B. Entlassungsbrief ärztlich) ist eine lokale OID zulässig, sofern keine AbgabeID vorliegt.

Bedingung:
Bei Medikationsliste @root="1.2.40.0.10.1.4.3.4.2.3.1" @extension=AbgabeID

Sonst @root="1.2.40.0.10.1.4.3.4.2.3" @extension=AbgabeID

Beispiel

hl7:id

II

C

ID des ursprünglichen MedikationAbgabe-Entry (aus dem Abgabe-Dokument)

wo [2]

@root

uid

1 … 1

R

Wurzel OID der ID eines MedikationAbgabe-Entry gemäß Anwendung e-Medikation

@extension

st

1 … 1

R

AbgabeID = {eMedID}_{lokal vergebene ID}

Constraint

Für e-Medikation:
Im Abgabe-Entry der Medikationsliste oder der pharmazeutischen Empfehlung ist das zweite ID-Element verpflichtend anzugeben (1..1 M). Es muss die ID des ursprünglich im Abgabe-Dokument angegebenen Abgabe-Entry enthalten, welche den Ausgangspunkt des vorliegenden Abgabe-Entry darstellt.

Im Abgabe-Entry einer Abgabe darf das zweite id-Element nicht verwendet werden (NP).

In anderen e-Befunden kann dieses Element entfallen (0..1).

Konditionale Konformität

Abgabe-Entry liegt in Medikationsliste oder Pharmazeutischen Empfehlung vor: Card 1..1 Conf M
Abgabe-Entry in einer Abgabe: NP

Beispiel

hl7:code

CE

0 … 1

Code des MedikationAbgabe-Entry (Abgabeart). Dieses Element dient zur Kennzeichnung, ob die Abgabe eine zugrundeliegende Verordnung vollständig oder partiell (z.B. im Falle einer Bestellung) erfüllt.

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.159 ELGA_MedikationAbgabeArt (DYNAMIC)

Beispiel

Strukturbeispiel

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)
Textinhalt, der codiert wurde. Beispielsweise wo im Text die Information steht, das hier ein "First Fill - Complete" oder "Refill - Part Fill" durchgeführt wurde. Gemäß Vorgaben im „Allgemeinen Implementierungsleitfaden“, Kapitel „Codierungs-Elemente“.

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:text

ED

1 … 1

M

Verweist auf die Stelle im narrativen Text-Bereich, an der die gegebene Medikation narrativ beschrieben ist (mit zusätzlichen Informationen, wie Datum, Beschreibung, etc).

Beispiel

Strukturbeispiel

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#apos-{generierteID}, z.B.: #apos-1

hl7:quantity

PQ

1 … 1

M

Gibt die Packungsanzahl an, die zu einem Rezept abgegeben werden.

Das Attribut value muss vorhanden sein und die Packungsanzahl angeben. Bei Verschreibungen für eine Gesamtmenge (z. B. 400 Tabletten) muss das Attribut value gleich 1 sein, und die Gesamtmenge ist in das Element hl7:product/hl7:manufacturedProduct/hl7:manufacturedMaterial/pharm:asContent/pharm:quantity einzutragen. Weitere Informationen finden Sie in der Beschreibung dieses Elements.

Das Attribut unit muss vorhanden sein und der UCUM-Einheit 1 entsprechen.

@value

real

1 … 1

R

@unit

cs

1 … 1

F

1

hl7:product

1 … 1

M

Komponente zur Aufnahme der Arznei auf die sich der MedikationAbgabe-Entry bezieht.
Beinhaltet 1.2.40.0.34.6.0.11.3.186 Arznei Entry v3 (DYNAMIC)

@typeCode

cs

0 … 1

F

PRD

hl7:performer

1 … 1

R

@nullFlavor

cs

0 … 1

F

NI

@typeCode

cs

1 … 1

F

PRF

Constraint

Konditionale Konformität für die Attribute und Elemente im performer-Element:

<TBODY>

</TBODY>

C&C nullFlavor	C&C andere Attribute C&C Elemente	Prädikat
0..0 NP	wie beschrieben	Dieses Element wird in e-Medikations Medikationsliste oder eHDSI Kontext verwendet.
1..1 M	0..0 NP	Sonst

hl7:time

TS.DATE.MIN

1 … 1

R

hl7:assignedEntity

1 … 1

M

Eingefügt

von 1.2.40.0.34.6.0.11.9.68 Medikation AssignedEntityElementsV3 (DYNAMIC)

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

R

Mindestens eine Id der validierenden Person.

Zugelassene nullFlavor: UNK

hl7:addr

AD

1 … 1

R

Ein Adress-Element der validierenden Person.

Zugelassene nullFlavor: UNK

hl7:telecom

TEL.AT

1 … *

R

Mindestens ein Telecom-Element der validierenden Person.

Zugelassene nullFlavor: UNK

hl7:assignedPerson

1 … 1

M

Persondendaten der validierenden Person.

Eingefügt

von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Namen-Element (Person)

@use

cs

0 … 1

Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.

Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“.

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

hl7:prefix

ENXP

0 … *

Beliebig viele Präfixe zum Namen, z.B. Akademische Titel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!

@qualifier

cs

0 … 1

Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:family

ENXP

1 … *

M

Mindestens ein Hauptname (Nachname).

@qualifier

cs

0 … 1

Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:given

ENXP

1 … *

M

Mindestens ein Vorname

@qualifier

cs

0 … 1

Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:suffix

ENXP

0 … *

Beliebig viele Suffixe zum Namen

@qualifier

cs

0 … 1

Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:representedOrganization

0 … 1

R

Organistationsdaten der validierenden Person.

Eingefügt

von 1.2.40.0.34.6.0.11.9.5.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … *

R

Beliebig viele, mindestens eine ID der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.

@root

uid

1 … 1

R

@extension

st

0 … 1

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.

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten der Organisation.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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

1 … 1

R

Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

Schematron assert

role

error

test

count(ancestor::hl7:templateId[@root='1.2.40.0.34.6.0.11.0.23'])=0 or count(hl7:author)=2

Meldung

In einer Medikationsliste muss der Verfasser der Verordnung / der Abgabe (author-Element) angegeben werden.

Eingefügt

0 … 2

C

von 1.2.40.0.34.6.0.11.9.66 Medikation AuthorElements (DYNAMIC)

1. <author> Element: Verfasser der Verordnung zu dieser Abgabe.
Das erste <author> Element beinhaltet den Verfasser des Rezepts auf dem die Verordnung ausgestellt wurde, auf die eine Referenz existiert. Das author/time Element hat dabei die Bedeutung „Datum der Verordnung“.

Zugelassene nullFlavor: NA

Da das <author> Element im CDA Schema gewisse Unterelemente zwingend benötigt, ist ein einfaches <author nullFlavor=‘NA‘/> nicht ausreichend und würde zu einer CDA Schema Verletzung führen. Im Falle der Anwendung von nullFlavor=‘NA‘ sind demnach die erforderlichen Unterelemente mit diesem Attribut zu versehen.

Diese Elemente werden nur bei ELGA MedikationAbgabe-Entries verwendet, welche im Rahmen der Medikationsliste vorliegen.

2. <author> Element: Verfasser der Abgabe
Das zweite <author> Element beinhaltet den Verfasser der Abgabe. Das author/time Element hat dabei die Bedeutung „Datum der Abgabe“.

Diese Elemente werden nur bei ELGA MedikationAbgabe-Entries verwendet, welche im Rahmen der Medikationsliste vorliegen.

Constraint

Konditionale Konformität für die author-Elemente:

Card	Conf	Prädikat
	NP	Dieses Element wird nicht in der Medikationsliste verwendet. Die author-Elemente werden nur bei ELGA MedikationAbgabe-Entries verwendet, welche im Rahmen der Medikationsliste vorliegen.
1..	R	Dieses Element wird in der Medikationsliste verwendet, dann: wenn eine Referenz zu einer Verordnung vorhanden ist ,wird im 1. Author-Element der Verfasser der Verordnung genannt; wenn keine Referenz zu einer Verordnung vorhanden ist, muss das Author-Element null sein (siehe Beispiel)
..2	M	Dieses Element wird in der Medikationsliste verwendet, dann wird im 2. Author-Element der Verfasser der Abgabe genannt.

Beispiel

1. <author> Element: Verfasser der Verordnung, falls Referenz zu Verordnung vorhanden

<author> : Author Element, übernommen aus dem zugrundeliegenden Rezept-Dokument zu der Abgabe : </author>

Beispiel

1. <author> Element: Keine Referenz zu einer Vordnung vorhanden, Verfasser der Verordnung (1. Author-Element) ist null

Beispiel

Verfasser einer Abgabe (2. Author-Element)

Auswahl

0 … 2

Elemente in der Auswahl:

hl7:author[not(@nullFlavor)]
hl7:author[@nullFlavor]

hl7:author

Verfasser des Dokuments.

wo [not(@nullFlavor)]

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

0 … 1

Funktionscode des Verfassers des Dokuments

z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“, …

Eigene Codes und Bezeichnungen können verwendet werden.

Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.

hl7:time

TS.DATE.MIN

1 … 1

R

Der Zeitpunkt an dem das Dokument verfasst wurde. Grundsätzlich sind die Vorgaben für „ Zeit-Elemente “ zu befolgen.

Zugelassene nullFlavor: UNK

hl7:assignedAuthor

1 … 1

M

Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.

@classCode

cs

0 … 1

F

ASSIGNED

Beispiel

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System/ des/der datenerstellenden Gerätes/Software.

Grundsätzlich sind die Vorgaben für „ Identifikations-Elemente “ zu befolgen.

hl7:code

CE

0 … 1

Angabe der Fachrichtung des Verfassers des Dokuments („Sonderfach“ gem. Ausbildungsordnung) z.B: „Facharzt/Fachärzting für Gynäkologie“,

Wenn ein Autor mehreren ärztlichen Sonderfächern zugeordnet ist, kann das anzugebende Sonderfach gewählt werden. Additivfächer werden nicht angegeben.
Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.

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.

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:assignedPerson
hl7:assignedAuthoringDevice

hl7:assignedPerson

… 1

Personendaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.

Eingefügt

von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Namen-Element (Person)

@use

cs

0 … 1

Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.

Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“.

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

hl7:prefix

ENXP

0 … *

Beliebig viele Präfixe zum Namen, z.B. Akademische Titel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!

@qualifier

cs

0 … 1

Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:family

ENXP

1 … *

M

Mindestens ein Hauptname (Nachname).

@qualifier

cs

0 … 1

Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:given

ENXP

1 … *

M

Mindestens ein Vorname

@qualifier

cs

0 … 1

Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:suffix

ENXP

0 … *

Beliebig viele Suffixe zum Namen

@qualifier

cs

0 … 1

Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:assignedAuthoringDevice

… 1

@classCode

cs

0 … 1

F

DEV

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:manufacturerModelName

SC

0 … 1

Hersteller und Modellbezeichnung des datenerstellenden Gerätes.

hl7:softwareName

SC

0 … 1

Bezeichnung (und ggf Version) der datenerstellenden Software.

hl7:representedOrganization

1 … 1

M

Eingefügt

von 1.2.40.0.34.6.0.11.9.5.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … *

R

Beliebig viele, mindestens eine ID der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.

@root

uid

1 … 1

R

@extension

st

0 … 1

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.

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten der Organisation.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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

1 … 1

R

Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:author

Verfasser nicht bekannt/nicht anwendbar

wo [@nullFlavor]

@nullFlavor

cs

1 … 1

F

NA

Beispiel

hl7:time

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

hl7:assignedAuthor

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

hl7:id

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

hl7:entryRelationship

1 … 1

M

Referenz zur Verordnung per VerordnungsID. Wird für die Kompatibilität mit der eHDSI ePrescription/eDispensation immer angeführt.
Falls tatsächliche keine Verordnung vorhanden ist, ist die VerordnungsID "0" anzugeben.

ACHTUNG: Es ist immer die VerordnungsID des Verordnungs-Entry anzugeben, welches ursprünglich im Rezept-Dokument angegeben wurde, unabhängig von etwaigen darauffolgenden Korrekturen mittels Pharmazeutischer Empfehlungen.

wo [@typeCode='REFR']

@typeCode

cs

1 … 1

F

REFR

Beispiel

Strukturbeispiel

<entryRelationship typeCode="REFR">
  
  <substanceAdministration classCode="SBADM" moodCode="INT">
    <id root="1.2.40.0.10.1.4.3.4.2.2" extension="...VerordnungsID..."/>    <consumable>
      <manufacturedProduct>
        <manufacturedMaterial nullFlavor="NA"/>      </manufacturedProduct>    </consumable>  </substanceAdministration></entryRelationship>

hl7:substanceAdministration

1 … 1

M

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

hl7:id

II

1 … 1

M

VerordnungsID.

@root

uid

1 … 1

F

1.2.40.0.10.1.4.3.4.2.2

Wurzel OID der ID eines MedikationVerordnungs-Entry gemäß Anwendung e-Medikation.

@extension

st

1 … 1

R

VerordnungsID. Strukturvorschrift: VerordnungsID = {eMedID}_{lokal vergebene ID}

hl7:consumable

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.62 Medikation Patient Instructions (DYNAMIC)

hl7:act

0 … 1

R

Abbildung der Zusatzbemerkungen als untergeordnetes act-Element.

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.49

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

PINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die Zusatzinformationen für den Patienten, Informationen zur alternativen Einnahme und Informationen zur Arznei angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#patinfo-{generierteID}, z.B.: #patinfo-1

Schematron assert

role

error

test

starts-with(@value, '#patinfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 3

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.1

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.161 ELGA_ActCode_PatInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#zinfo|altein|arzneiinfo|veri-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #altein-1

Schematron assert

role

error

test

starts-with(@value, '#zinfo-') or starts-with(@value, '#altein-') or starts-with(@value, '#arzneiinfo-') or starts-with(@value, '#veri-')

Meldung

Die Referenz muss mit "#zinfo-", "#altein-", "#arzneiinfo-" oder "#veri-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:effectiveTime

IVL_TS

0 … 1

C

Constraint

Wenn eine Verifizierung, d.h. eine Überprüfung, ob das Arzneimittel wie für diese Behandlung vorgesehen wirkt, mit "veri" im code-Element oder mit "#veri-{generierteID}" im reference-Element festgelegt wird, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime-Element festgelegt werden.

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.63 Medikation Pharmacist Instructions (DYNAMIC)

hl7:act

0 … 1

R

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.43

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3.1

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

FINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die ergänzenden Informationen zur Abgabe oder zu der magistralen Zubereitungen angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#abginfo-{generierteID}, z.B.: #abginfo-1

Schematron assert

role

error

test

starts-with(@value, '#abginfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 2

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.2

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.160 ELGA_ActCode_AbgInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#erginfo|magzub-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #magzub-1

Schematron assert

role

error

test

starts-with(@value, '#erginfo-') or starts-with(@value, '#magzub-')

Meldung

Die Referenz muss mit "#erginfo-" oder "#magzub-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

0 … 1

Komponente zur Aufnahme der Zusatzinformationen für den Patienten, Informationen zur alternativen Einnahme und Informationen zur Arznei.

wo [@typeCode='SUBJ'] [hl7:act/hl7:templateId [@root='2.16.840.1.113883.10.20.1.49']]

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.62 Medikation Patient Instructions (DYNAMIC)

hl7:act

1 … 1

M

Abbildung der Zusatzbemerkungen als untergeordnetes act-Element.

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.49

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

PINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die Zusatzinformationen für den Patienten, Informationen zur alternativen Einnahme und Informationen zur Arznei angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#patinfo-{generierteID}, z.B.: #patinfo-1

Schematron assert

role

error

test

starts-with(@value, '#patinfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 3

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.1

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.161 ELGA_ActCode_PatInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#zinfo|altein|arzneiinfo|veri-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #altein-1

Schematron assert

role

error

test

starts-with(@value, '#zinfo-') or starts-with(@value, '#altein-') or starts-with(@value, '#arzneiinfo-') or starts-with(@value, '#veri-')

Meldung

Die Referenz muss mit "#zinfo-", "#altein-", "#arzneiinfo-" oder "#veri-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:effectiveTime

IVL_TS

0 … 1

C

Constraint

Wenn eine Verifizierung, d.h. eine Überprüfung, ob das Arzneimittel wie für diese Behandlung vorgesehen wirkt, mit "veri" im code-Element oder mit "#veri-{generierteID}" im reference-Element festgelegt wird, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime-Element festgelegt werden.

hl7:entryRelationship

0 … 1

Ergänzende Informationen zur Abgabe und magistralen Zubereitung.

wo [@typeCode='SUBJ'] [hl7:act/hl7:templateId [@root='2.16.840.1.113883.10.20.1.43']]

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Arznei ist eine magistrale Zubereitung
0..1	O	Arznei ist keine magistrale Zubereitung

Eingefügt

1 … 1

M

von 1.2.40.0.34.6.0.11.9.63 Medikation Pharmacist Instructions (DYNAMIC)

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.43

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3.1

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

FINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die ergänzenden Informationen zur Abgabe oder zu der magistralen Zubereitungen angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#abginfo-{generierteID}, z.B.: #abginfo-1

Schematron assert

role

error

test

starts-with(@value, '#abginfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 2

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.2

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.160 ELGA_ActCode_AbgInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#erginfo|magzub-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #magzub-1

Schematron assert

role

error

test

starts-with(@value, '#erginfo-') or starts-with(@value, '#magzub-')

Meldung

Die Referenz muss mit "#erginfo-" oder "#magzub-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

Eingefügt

0 … 1

von 1.2.40.0.34.6.0.11.9.64 Medikation Therapieart (DYNAMIC)
Therapieart.
Im Falle von Abgaben zu einer Verordnung nur anzugeben, falls dieses sich von der Therapieart der Verordnung unterscheidet.

hl7:entryRelationship

0 … 1

Therapieart dieses MedikationVerordnung-Entry

wo [@typeCode='COMP'] [hl7:act/hl7:templateId [@root='1.2.40.0.34.11.8.1.3.4']]

@typeCode

cs

1 … 1

F

COMP

Beispiel

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.1.3.4

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.30 ELGA_MedikationTherapieArt (DYNAMIC)

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

hl7:entryRelationship

0 … 1

Komponente zur Aufnahme der optionalen Dosierungsinformationen.
Beinhaltet 1.2.40.0.34.6.0.11.9.67 Medikation Altered Dosage Instructions (DYNAMIC)

wo [@typeCode='COMP'] [hl7:substanceAdministration/hl7:templateId [@root='1.3.6.1.4.1.19376.1.9.1.3.6']]

@typeCode

cs

1 … 1

F

COMP

Beispiel

Strukturbeispiel

<entryRelationship typeCode="COMP">
  <substanceAdministration classCode="SBADM" moodCode="INT">
    <templateId root="1.3.6.1.4.1.19376.1.9.1.3.6"/>     : ... Einnahmedauer ... : ... Dosierungsvarianten 1 + 3 ... : ... Art der Anwendung ... :     <consumable>
      <manufacturedProduct>
        <manufacturedMaterial nullFlavor="NA"/>      </manufacturedProduct>    </consumable>     : ... Dosierungsvarianten 2 + 4 ... :   </substanceAdministration></entryRelationship>

hl7:entryRelationship

0 … 1

C

Falls das Arznei Entry in dieser Abgabe sich nicht mit dem Arznei Entry der Verordnung gleicht, wie z.B. bei Abgabe eines Generikum, MUSS dieses entryRelationship vorhanden sein.

Wenn im Gegenteil, das Arznei Entry in dieser Abgabe sich nicht mit dem Arznei Entry der Verordnung gleicht, MUSS dieses entryRelationsship entfallen.

wo [@typeCode='COMP'] [hl7:act]

@typeCode

cs

1 … 1

F

COMP

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

EVN

hl7:code

1 … 1

M

@code

CONF

1 … 1

F

SUBST

@codeSystem

1 … 1

F

2.16.840.1.113883.5.6 (HL7ActClass)

Eingefügt

0 … 1

C

von 1.2.40.0.34.6.0.11.9.65 Medikation ID des Containers (DYNAMIC)
ID des Verordnungs-Entry Containers (Abgabe-Dokument).

Wird das ELGA MedikationAbgabe-Entry im Rahmen der Medikationsliste verwendet, MUSS die ID des Abgabe-Dokuments, welches das Abgabe-Entry ursprünglich beinhaltete, angegeben sein.

Constraint

Konditionale Konformität für ID des Verordnungs-Entry Containers (Abgabe-Dokument)

Card	Conf	Prädikat
1..1	M	Element wird in Medikationsliste verwendet
	NP	Sonst

Beispiel

Strukturbeispiel

hl7:reference

0 … 1

C

ID des Verordnungs-Entry Containers (Rezept-Dokument).

@typeCode

cs

1 … 1

F

XCRPT

hl7:externalDocument

1 … 1

M

hl7:id

II

1 … 1

M

ID des MedikationVerordnung-Entry.

@root

uid

1 … 1

F

1.2.40.0.10.1.4.3.4.2.1

@extension

st

1 … 1

R

Verpflichtende eMED-ID

7.3.5 Weitere CDA Fragmente

Die weiteren CDA Fragmente, oder auch Compilation Templates genannt, wurden großteils aus dem bestehenden Art-Decor Repository vom "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente" übernommen. Diese sind unter [[21]] zu finden.

Die weiteren CDA Fragmente welche spezifisch für die e-Medikation v3 angepasst wurden sind folgende:

7.3.5.1 Address Compilation v2

Id

1.2.40.0.34.6.0.11.9.25.2

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑23 15:58:09

Status

Entwurf

Versions-Label

2.0.0+20250228

Name

atcdabbr_other_AddressCompilation_v2

Bezeichnung

Address Compilation v2

Beschreibung

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.

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (2023‑04‑13 13:21:00)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (2021‑02‑19 13:05:47)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (2019‑02‑28 14:24:14)

ref

at-cda-bbr-

Beispiel

Österreichische Postadresse - G2

<addr use="WP">
<streetAddressLine>Mozartgasse 1-7/2/1</streetAddressLine> <postalCode>7000</postalCode> <city>Eisenstadt</city> <state>Burgenland</state> <country>AT</country> <additionalLocator>Station A, Zimmer 9</additionalLocator></addr>

Beispiel

Österreichische Postadresse - G3

<addr use="WP">
<streetName>Mozartgasse</streetName> <houseNumber>1-7/2/1</houseNumber> <postalCode>7000</postalCode> <city>Eisenstadt</city> <state>Burgenland</state> <country>AT</country> <additionalLocator>Station A, Zimmer 9</additionalLocator></addr>

Item

DT

Kard

Konf

Beschreibung

Label

@use

cs

0 … 1

Die genaue Bedeutung der angegebenen Adresse kann über das @use Attribut angegeben werden.
Wird kein @use Attribut angegeben, gilt bei Personen die Adresse als Wohnadresse „H“ und bei Organisationen als Büroadresse „WP“.

Wird ein Hauptwohnsitz "HP" angegeben, gelten die mit "H" deklarierten Wohnsitze als Nebenwohnsitze.

Zulässige Werte gemäß Value Set "ELGA_AddressUse".

hl7:streetAddressLine

ADXP

0 … 1

C

Straße mit Hausnummer, z.B. Musterstraße 11a/2/1

Constraint

Es muss entweder streetAddressLine oder streetName UND houseNumber angegeben werden.

hl7:streetName

ADXP

0 … 1

C

Straße ohne Hausnummer, z.B. Musterstraße

hl7:houseNumber

ADXP

0 … 1

C

Hausnummer, z.B. 11a/2/1

hl7:postalCode

ADXP

1 … 1

M

Postleitzahl

hl7:city

ADXP

1 … 1

M

Stadt

hl7:state

ADXP

0 … 1

Bundesland

hl7:country

ADXP

1 … 1

M

Staat.

Für die EHDSI Kompatibilität müssen die ISO 2 Ländercodes (ISO-3166-1 Alpha 2) angegeben werden, z.B. „AT“ für Österreich, „DE“ für Deutschland.

Schematron assert

role

info

test

string-length(text()) = 2

Meldung

Es wird EMPFOHLEN, den Staat im ISO 2 Ländercode anzugeben.

hl7:additionalLocator

ADXP

0 … 1

Zusätzliche Addressinformationen, z.B. Station, Zimmernummer im Altersheim.

Schematron assert

role

error

test

not(hl7:streetAddressLine and (hl7:streetName or hl7:houseNumber)) or ((hl7:streetAddressLine or (hl7:streetName and hl7:houseNumber)) and not((hl7:streetAddressLine and hl7:streetName and hl7:houseNumber) or (hl7:streetAddressLine and (hl7:streetName or hl7:houseNumber))))

Meldung

Es muss entweder streetAddressLine oder streetName UND houseNumber angegeben werden.

7.3.5.2 Medikation AssignedEntityElements V3

Id

1.2.40.0.34.6.0.11.9.68

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 05:20:35

Status

Entwurf

Versions-Label

3.0.0+20250228

Name

atcdabbr_other_MedikationAssignedEntityElementsV3

Bezeichnung

Medikation AssignedEntityElementsV3

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.11	Inklusion	Person Name Compilation G2 M (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.9.5.2	Inklusion	Organization Compilation with id, name, addr and telecom v2 (2.0.0+20250228)	DYNAMIC

Beziehung

Adaptation: Template 1.2.40.0.34.11.90003 AssignedEntityElements (2011‑12‑19)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.90003 AssignedEntityElements (2011‑12‑19)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … *

R

Mindestens eine Id der validierenden Person.

Zugelassene nullFlavor: UNK

hl7:addr

AD

1 … 1

R

Ein Adress-Element der validierenden Person.

Zugelassene nullFlavor: UNK

hl7:telecom

TEL.AT

1 … *

R

Mindestens ein Telecom-Element der validierenden Person.

Zugelassene nullFlavor: UNK

hl7:assignedPerson

1 … 1

M

Persondendaten der validierenden Person.

Eingefügt

von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Namen-Element (Person)

@use

cs

0 … 1

Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.

Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“.

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

hl7:prefix

ENXP

0 … *

Beliebig viele Präfixe zum Namen, z.B. Akademische Titel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!

@qualifier

cs

0 … 1

Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:family

ENXP

1 … *

M

Mindestens ein Hauptname (Nachname).

@qualifier

cs

0 … 1

Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:given

ENXP

1 … *

M

Mindestens ein Vorname

@qualifier

cs

0 … 1

Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:suffix

ENXP

0 … *

Beliebig viele Suffixe zum Namen

@qualifier

cs

0 … 1

Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:representedOrganization

0 … 1

R

Organistationsdaten der validierenden Person.

Eingefügt

von 1.2.40.0.34.6.0.11.9.5.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … *

R

Beliebig viele, mindestens eine ID der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.

@root

uid

1 … 1

R

@extension

st

0 … 1

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.

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten der Organisation.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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

1 … 1

R

Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

7.3.5.3 Organization Compilation with id, name, addr and telecom v2

Id

1.2.40.0.34.6.0.11.9.5.2

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑23 16:15:08

Status

Entwurf

Versions-Label

2.0.0+20250228

Name

atcdabbr_other_OrganizationCompilationWithIdNameAddrTelecom_v2

Bezeichnung

Organization Compilation with id, name, addr and telecom v2

Beschreibung

Wiederverwendbare Compilation mit verpflichtender Angabe des name-Elements.
Minimale Adressangabe möglich.

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.25.2	Containment	Address Compilation v2 (2.0.0+20250228)	DYNAMIC

Beziehung

Adaptation: Template 1.2.40.0.34.6.0.11.9.30 Organization Compilation with name, addr minimal and telecom (2021‑06‑28 14:00:05)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.9.30 Organization Compilation with name, addr minimal and telecom (2021‑02‑19 13:31:37)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.9.30 Organization Compilation with name, addr minimal and telecom (2019‑05‑16 08:42:59)

ref

at-cda-bbr-

Spezialisierung: Template 1.2.40.0.34.6.0.11.9.20 Organization Compilation with name, addr minimal (2019‑04‑18 11:28:59)

ref

at-cda-bbr-

Beispiel

Strukturbeispiel

<placeholder classCode="ORG" determinerCode="INSTANCE">
  
  <id root="1.2.40.0.34.99.4613.3" assigningAuthorityName="GDA Index"/>  
  <name>Amadeus Spital - Chirurgische Abteilung</name>  
  <telecom value="tel:+43.6138.3453446.0"/>  <telecom value="fax:+43.6138.3453446.4674"/>  <telecom value="mailto:info@amadeusspital.at"/>  <telecom value="http://www.amadeusspital.at"/>  
  <addr>
    
  </addr></placeholder>

Beispiel

Strukturbeispiel - minimal

<placeholder classCode="ORG" determinerCode="INSTANCE">
  
  <name>Amadeus Spital - Chirurgische Abteilung</name>  
  <telecom value="tel:+43.6138.3453446.0"/>  <telecom value="fax:+43.6138.3453446.4674"/>  <telecom value="mailto:info@amadeusspital.at"/>  <telecom value="http://www.amadeusspital.at"/>  
  <addr>
    
  </addr></placeholder>

Item

DT

Kard

Konf

Beschreibung

Label

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … *

R

Beliebig viele, mindestens eine ID der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.

@root

uid

1 … 1

R

@extension

st

0 … 1

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.

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten der Organisation.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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

1 … 1

R

Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

Die weiteren CDA Fragmente welche in der e-Medikation direkt aus dem bestehenden Art-Decor Repository vom "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente" verwendet worden sind, sind folgende:

7.3.5.4 Medikation Altered Dosage Instructions

Id

1.2.40.0.34.6.0.11.9.67

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 19:04:35

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationAlteredDosageInformation

Bezeichnung

Medikation Altered Dosage Instructions

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.9.67

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 12 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.48	Inklusion	Medikation Sbadm TemplateId Options (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.49	Inklusion	Medikation Einnahmedauer (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.50	Inklusion	Medikation Dosierungsvariante 1: Tagesdosierung effectiveTime (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.51	Inklusion	Medikation Dosierungsvariante 2: Einzeldosierung (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.52	Inklusion	Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.53	Inklusion	Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.54	Inklusion	Medikation Dosierungsvariante 1: Tagesdosierung doseQuantity (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.55	Inklusion	Medikation Dosierungsvariante 2: Einzeldosierung doseQuantity (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.56	Inklusion	Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.57	Inklusion	Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.58	Inklusion	Medikation Dosierungsvariante 2: Einzeldosierung entryRelationship (1.0.0+20250228)	DYNAMIC
1.2.40.0.34.6.0.11.9.60	Inklusion	Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship (1.0.0+20250228)	DYNAMIC

Beziehung

Adaptation: Template 1.2.40.0.34.11.30035 Altered Dosage Instructions (2013‑12‑21)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:substanceAdministration

1 … 1

M

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

R

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.9.1.3.6

Eingefügt

von 1.2.40.0.34.6.0.11.9.48 Medikation Sbadm TemplateId Options (DYNAMIC)

hl7:templateId

II

C

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.21

Constraint

Konditionale Konformität

Einnahmedauer beinhaltet low/high Elemente Conf: NP
Einnahmedauer beinhaltet ein width Element: Card 1..1 Conf M

Auswahl

0 … 1

Dosierungsart, mögliche Werte:

a) Normal: @root = 1.3.6.1.4.1.19376.1.5.3.1.4.7.1

b) Split: @root = 1.3.6.1.4.1.19376.1.5.3.1.4.9

c) keine Dosierung: templateID Element entfällt vollständig.

Dosierungsart: Normal (1.3.6.1.4.1.19376.1.5.3.1.4.7.1), Split (1.3.6.1.4.1.19376.1.5.3.1.4.9) oder keine Dosierung (keine der beiden TemplateIDs)

Elemente in der Auswahl:

hl7:templateId
hl7:templateId

hl7:templateId

II

0 … 1

R

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.7.1

hl7:templateId

II

0 … 1

R

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.9

Eingefügt

von 1.2.40.0.34.6.0.11.9.49 Medikation Einnahmedauer (DYNAMIC)

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:effectiveTime[1][hl7:low]
hl7:effectiveTime[1][hl7:width]
hl7:effectiveTime[1][@nullFlavor]

hl7:effectiveTime

IVL_TS

0 … 1

R

Zeitelement zur Dokumentation der Einnahmedauer.

wo [1] [hl7:low]

hl7:low

TS

1 … 1

R

Zeitpunkt des Einnahmestarts.
Zugelassene nullFlavor: UNK

hl7:high

TS

1 … 1

R

Zeitpunkt des Einnahmeendes.
Zugelassene nullFlavor: UNK

hl7:effectiveTime

IVL_TS

0 … 1

R

Dauer der Einnahme, wenn Einnahmestart unbekannt

wo [1] [hl7:width]

hl7:width

PQ

1 … 1

M

Dauer der Einnahme, wenn Einnahmestart unbekannt

Bemerkung: Wenn ein width Element angegeben wird, MUSS auch die templateId für „Delay Start Dosing“ angegeben werden.

Siehe Kapitel „Template IDs"

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.69 ELGA_MedikationFrequenz (DYNAMIC)

hl7:effectiveTime

IVL_TS

0 … 1

R

wo [1] [@nullFlavor]

@nullFlavor

cs

1 … 1

F

NA

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Wenn die Dosierungsvariante einer Verordnung "Split" ist, ist in der Verordnung die templateId 1.3.6.1.4.1.19376.1.5.3.1.4.9 anzugeben.
	NP	Sonst

Auswahl

Elemente in der Auswahl:

hl7:effectiveTime[hl7:period and not(hl7:phase)] eingefügt vom Template 1.2.40.0.34.6.0.11.9.50 Medikation Dosierungsvariante 1: Tagesdosierung effectiveTime (DYNAMIC)
hl7:effectiveTime[2] eingefügt vom Template 1.2.40.0.34.6.0.11.9.51 Medikation Dosierungsvariante 2: Einzeldosierung (DYNAMIC)
ein Element eingefügt vom Template 1.2.40.0.34.6.0.11.9.52 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause (DYNAMIC)
hl7:effectiveTime[2] eingefügt vom Template 1.2.40.0.34.6.0.11.9.53 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.50 Medikation Dosierungsvariante 1: Tagesdosierung effectiveTime (DYNAMIC)

hl7:effectiveTime

PIVL_TS

C

Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [hl7:period and not(hl7:phase)]

@operator

cs

1 … 1

F

A

@institutionSpecified

bl

1 … 1

F

true

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..1 M
Dosierung nicht angegeben -> NP

hl7:period

PQ

1 … 1

R

Zeitraum für den die Dosis in doseQuantity vorgesehen ist.

@value

1 … 1

F

1

@unit

cs

1 … 1

R

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.69 ELGA_MedikationFrequenz (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.51 Medikation Dosierungsvariante 2: Einzeldosierung (DYNAMIC)

hl7:effectiveTime

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [2]

Eingefügt

von 1.2.40.0.34.6.0.11.9.52 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause (DYNAMIC)

Auswahl

… 1

Elemente in der Auswahl:

hl7:effectiveTime[hl7:period and hl7:phase]
hl7:effectiveTime[hl7:comp]

hl7:effectiveTime

PIVL_TS

C

Für EIN Wochentag.
Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [hl7:period and hl7:phase]

@operator

cs

1 … 1

F

A

hl7:phase

IVL_TS

1 … 1

R

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag)

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:effectiveTime

SXPR_TS

C

Für mehrere Wochentage, z. B. wöchtentlich montags und mittwochs

wo [hl7:comp]

@operator

cs

1 … 1

F

A

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..1 M
Dosierung nicht angegeben -> NP

1. Komponentencontainer ohne @operator, ggf. folgende Komponentencontainer mit @operator=I

hl7:comp

PIVL_TS

1 … 1

R

Komponentencontainer.

wo [not(@operator)]

hl7:phase

IVL_TS

1 … 1

R

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag)

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:comp

PIVL_TS

0 … *

wo [@operator='I']

@operator

cs

1 … 1

F

I

hl7:phase

IVL_TS

1 … 1

R

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

Eingefügt

von 1.2.40.0.34.6.0.11.9.53 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause (DYNAMIC)

hl7:effectiveTime

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [2]

Auswahl

Elemente in der Auswahl:

ein Element eingefügt vom Template 1.2.40.0.34.6.0.11.9.54 Medikation Dosierungsvariante 1: Tagesdosierung doseQuantity (DYNAMIC)
hl7:doseQuantity eingefügt vom Template 1.2.40.0.34.6.0.11.9.55 Medikation Dosierungsvariante 2: Einzeldosierung doseQuantity (DYNAMIC)
ein Element eingefügt vom Template 1.2.40.0.34.6.0.11.9.56 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity (DYNAMIC)
hl7:doseQuantity eingefügt vom Template 1.2.40.0.34.6.0.11.9.57 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.54 Medikation Dosierungsvariante 1: Tagesdosierung doseQuantity (DYNAMIC)

Auswahl

… 1

Elemente in der Auswahl:

hl7:doseQuantity[not(hl7:low|hl7:high)]
hl7:doseQuantity[hl7:low|hl7:high]

Constraint

Konditionale Konformität:
Menge in nicht-zählbaren Einheiten -> @unit 1..1 (required) aus Value-Set ELGA_MedikationMengenart
Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.) -> @unit 0..1 (otional) mit @unit aus Value-Set ELGA_MedikationMengenartAlternativ

hl7:doseQuantity

IVL_PQ

R

Dosis.
mit doseQuantity als IVL_PQ, aber als PQ instantiiert

wo [not(hl7:lowoder
hl7:high)]

@value

1 … 1

R

Tagesdosierung.

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:doseQuantity

IVL_PQ

R

mit doseQuantity als IVL_PQ

wo [hl7:lowoder
hl7:high]

hl7:low

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:high

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.55 Medikation Dosierungsvariante 2: Einzeldosierung doseQuantity (DYNAMIC)

hl7:doseQuantity

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Dosis bei Dosierungsvariante 1 und 3.

Eingefügt

von 1.2.40.0.34.6.0.11.9.56 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity (DYNAMIC)

Auswahl

… 1

Elemente in der Auswahl:

hl7:doseQuantity[not(hl7:low|hl7:high)]
hl7:doseQuantity[hl7:low|hl7:high]

Constraint

Konditionale Konformität:
Menge in nicht-zählbaren Einheiten -> @unit 1..1 (required) aus Value-Set ELGA_MedikationMengenart
Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.) -> @unit 0..1 (optional) aus Value-Set ELGA_MedikationMengenartAlternativ

hl7:doseQuantity

IVL_PQ

R

Dosis.
mit doseQuantity als IVL_PQ, aber als PQ instantiiert

wo [not(hl7:lowoder
hl7:high)]

@value

1 … 1

R

Tagesdosierung.

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:doseQuantity

IVL_PQ

R

mit doseQuantity als IVL_PQ

wo [hl7:lowoder
hl7:high]

hl7:low

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:high

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

Eingefügt

von 1.2.40.0.34.6.0.11.9.57 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity (DYNAMIC)

hl7:doseQuantity

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Dosis bei Dosierungsvariante 1 und 3.

hl7:routeCode

CE

0 … 1

Art der Anwendung der Arznei

@codeSystem

CONF

0 … 1

F

1.2.40.0.10.1.4.3.4.3.4

hl7:consumable

1 … 1

M

hl7:manufacturedProduct

1 … 1

M

hl7:manufacturedMaterial

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

Auswahl

Elemente in der Auswahl:

hl7:entryRelationship
hl7:entryRelationship[hl7:substanceAdministration/hl7:effectiveTime[@xsi:type='EIVL_TS']] eingefügt vom Template 1.2.40.0.34.6.0.11.9.58 Medikation Dosierungsvariante 2: Einzeldosierung entryRelationship (DYNAMIC)
hl7:entryRelationship
hl7:entryRelationship[hl7:substanceAdministration/hl7:effectiveTime[@xsi:type='SXPR_TS']] eingefügt vom Template 1.2.40.0.34.6.0.11.9.60 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship (DYNAMIC)

hl7:entryRelationship

NP

Untergeordnete Komponenten für „Split dosing“ am Ende des ELGA MedikationVerordnungs-Entry entfallen bei Dosierungsvariante 1.

Eingefügt

von 1.2.40.0.34.6.0.11.9.58 Medikation Dosierungsvariante 2: Einzeldosierung entryRelationship (DYNAMIC)

hl7:entryRelationship

C

Komponente zur Aufnahme eines Einnahmezeitpunkts und –dosis bei Dosierungsvariante 2 und 4.

Wiederholung höchstens einmal je Zeitcode!

wo [hl7:substanceAdministration/hl7:effectiveTime [@xsi:type='EIVL_TS']]

@typeCode

cs

1 … 1

F

COMP

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..* M
Dosierung nicht angegeben -> NP

hl7:sequenceNumber

INT

1 … 1

M

Aufsteigende Nummerierung der Unterelemente.

Eingefügt

von 1.2.40.0.34.6.0.11.9.59 Medikation Splitdose-Einnahmezeitpunkte 1 (DYNAMIC)

hl7:substanceAdministration

1 … 1

M

Abbildung eines Einnahmezeitpunkts und –dosis als untergeordnetes substanceAdministration-Element.

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Menge in nicht-zählbaren Einheiten, zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS"
0..1	O	Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.), zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS" oder Freitext

hl7:effectiveTime

EIVL_TS

1 … 1

M

Zeitelement zur Aufnahme des Einnahmezeitpunkts.

wo [@xsi:type='EIVL_TS']

hl7:event

1 … 1

M

Einnahmezeitpunkt.

@code

cs

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.59 ELGA_Einnahmezeitpunkte (DYNAMIC)

hl7:offset

IVL_PQ

1 … 1

M

Zeitversatz (immer mit 0 Sekunden angegeben).

@value

1 … 1

F

0

@unit

cs

1 … 1

F

s

hl7:doseQuantity

IVL_PQ

1 … 1

M

Dosis.

hl7:consumable

1 … 1

M

hl7:manufacturedProduct

1 … 1

M

hl7:manufacturedMaterial

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

hl7:entryRelationship

NP

Untergeordnete Komponenten für „Split dosing“ am Ende des ELGA MedikationVerordnungs-Entry entfallen bei Dosierungsvariante 3.

Eingefügt

von 1.2.40.0.34.6.0.11.9.60 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship (DYNAMIC)

hl7:entryRelationship

C

Komponente zur Aufnahme eines Einnahmezeitpunkts und –dosis bei Dosierungsvariante 2 und 4.

Wiederholung höchstens einmal je Zeitcode!

wo [hl7:substanceAdministration/hl7:effectiveTime [@xsi:type='SXPR_TS']]

@typeCode

cs

1 … 1

F

COMP

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..* M
Dosierung nicht angegeben -> NP

hl7:sequenceNumber

INT

1 … 1

M

Aufsteigende Nummerierung der Unterelemente.

Eingefügt

von 1.2.40.0.34.6.0.11.9.61 Medikation Splitdose-Einnahmezeitpunkte 2 (DYNAMIC)

hl7:substanceAdministration

1 … 1

M

Abbildung eines Einnahmezeitpunkts und –dosis als untergeordnetes substanceAdministration-Element.

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Menge in nicht-zählbaren Einheiten, zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS"
0..1	O	Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.), zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS" oder Freitext

hl7:effectiveTime

SXPR_TS

1 … 1

M

Zeitelement zur Aufnahme des Einnahmezeitpunkts.

wo [@xsi:type='SXPR_TS']

Constraint

Die comp-Komponenten mit PIVL_TS müssen bei allen Einnahmezeitpunkten gleich angegeben werden!

1. Komponentencontainer mit @operator=A, ggf. folgende Komponentencontainer mit @operator=I

hl7:comp

EIVL_TS

1 … 1

M

Komponentencontainer

wo [@xsi:type='EIVL_TS']

hl7:event

1 … 1

M

Einnahmezeitpunkt.

@code

cs

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.59 ELGA_Einnahmezeitpunkte (DYNAMIC)

hl7:offset

IVL_PQ

1 … 1

M

Zeitversatz (immer mit 0 Sekunden angegeben).

@value

1 … 1

F

0

@unit

cs

1 … 1

F

s

hl7:comp

PIVL_TS

1 … 1

M

Komponentencontainer zur Aufnahme der Einnahmetage.
Diese Komponenten MÜSSEN bei allen Einnahmezeitpunkten (SequenceNumber) gleich angegeben werden!

wo [@xsi:type='PIVL_TS'] [@operator='A']

@operator

cs

1 … 1

F

A

hl7:phase

IVL_TS

1 … 1

R

Phase der Einnahme.

hl7:value

TS

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag).

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:comp

PIVL_TS

0 … *

2.+ Komponentencontainer zur Aufnahme der Einnahmetage

wo [@xsi:type='PIVL_TS'] [@operator='I']

hl7:phase

IVL_TS

1 … 1

R

hl7:value

TS

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:doseQuantity

IVL_PQ

1 … 1

M

Dosis.

hl7:consumable

1 … 1

M

hl7:manufacturedProduct

1 … 1

M

hl7:manufacturedMaterial

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

7.3.5.5 Medikation AuthorElements

Id

1.2.40.0.34.6.0.11.9.66

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 19:03:34

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationAuthorElements

Bezeichnung

Medikation AuthorElements

Beschreibung

Der Dokumentersteller („author“) ist in der Regel die „ das Dokument verfassende Person “ oder ein „ datenerstellendes Gerät “. Damit ist diejenige Person oder das Gerät gemeint, welche das Dokument „inhaltlich“ verfasst (z.B.: diktiert). Die das Dokument „schreibende“ Person (z.B. Schreibkraft, Stationsschwester, …) wird in CDA in einem eigenen Element (dataEnterer) abgebildet (siehe „ Personen der Dateneingabe („dataEnterer“) “).

Es kann auch mehr als ein Dokumentersteller angegeben werden (mehrere author-Elemente).

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.11	Inklusion	Person Name Compilation G2 M (1.0.1+20230717)	DYNAMIC
1.2.40.0.34.6.0.11.9.5.2	Inklusion	Organization Compilation with id, name, addr and telecom v2 (2.0.0+20250228)	DYNAMIC

Beziehung

Adaptation: Template 1.2.40.0.34.11.90004 AuthorElements (2015‑02‑17)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.90004 AuthorElements (2015‑02‑17)

ref

elgabbr-

Beispiel

Strukturbeispiel für eine Person als „author“

<author typeCode="AUT" contextControlCode="OP">
  
  <functionCode code="OA" displayName="Diensthabender Oberarzt" codeSystem="1.2.40.0.34.99.111.2.1" codeSystemName="Amadeus Spital Funktionen"/>  
  <time value="20081224082015+0100"/>  <assignedAuthor classCode="ASSIGNED">
    
    <id root="1.2.40.0.34.99.111.1.3" extension="1111" assigningAuthorityName="Amadeus Spital"/>    
    <code code="107" displayName="Fachärztin/Facharzt für Chirurgie" codeSystem="1.2.40.0.34.5.160" codeSystemName="ELGA_Fachaerzte"/>    
    <telecom value="tel:+43.1.40400"/>    <telecom value="mailto:herbert.mustermann@organization.at"/>    <assignedPerson classCode="PSN" determinerCode="INSTANCE">
      
      <name>
        <prefix qualifier="AC">Univ.-Prof. Dr.</prefix>        <given>Isabella</given>        <family>Stern</family>      </name>    </assignedPerson>    
    <representedOrganization>
      <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      
      <name>Amadeus Spital, 1. Chirurgische Abteilung</name>      
      <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="mailto:chirurgie@amadeusspital.at"/>      <addr>
        <streetName>Mozartgasse</streetName>        <houseNumber>1-7</houseNumber>        <postalCode>5350</postalCode>        <city>St.Wolfgang</city>        <state>Salzburg</state>        <country>AT</country>      </addr>    </representedOrganization>  </assignedAuthor></author>

Beispiel

Strukturbeispiel für datenerstellende Geräte als „author“

<author>
  
  <time value="20081224082015+0100"/>  <assignedAuthor>
    
    <id root="86562fe5-b509-4ce9-b976-176fd376e477"/>    
    <assignedAuthoringDevice>
      <manufacturerModelName>Good Health System</manufacturerModelName>      <softwareName>Best Health Software Application</softwareName>    </assignedAuthoringDevice>    <representedOrganization>
      <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      
      <name>Amadeus Spital, 1. Chirurgische Abteilung</name>      
      <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="mailto:chirurgie@amadeusspital.at"/>      <addr>
        <streetName>Mozartgasse</streetName>        <houseNumber>1-7</houseNumber>        <postalCode>5350</postalCode>        <city>St.Wolfgang</city>        <state>Salzburg</state>        <country>AT</country>      </addr>    </representedOrganization>  </assignedAuthor></author>

Item

DT

Kard

Konf

Beschreibung

Label

Auswahl

Elemente in der Auswahl:

hl7:author[not(@nullFlavor)]
hl7:author[@nullFlavor]

hl7:author

Verfasser des Dokuments.

wo [not(@nullFlavor)]

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

0 … 1

Funktionscode des Verfassers des Dokuments

z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“, …

Eigene Codes und Bezeichnungen können verwendet werden.

Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.

hl7:time

TS.DATE.MIN

1 … 1

R

Der Zeitpunkt an dem das Dokument verfasst wurde. Grundsätzlich sind die Vorgaben für „ Zeit-Elemente “ zu befolgen.

Zugelassene nullFlavor: UNK

hl7:assignedAuthor

1 … 1

M

Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.

@classCode

cs

0 … 1

F

ASSIGNED

Beispiel

hl7:id

II

1 … *

R

Identifikation des Verfassers des Dokuments im lokalen System/ des/der datenerstellenden Gerätes/Software.

Grundsätzlich sind die Vorgaben für „ Identifikations-Elemente “ zu befolgen.

hl7:code

CE

0 … 1

Angabe der Fachrichtung des Verfassers des Dokuments („Sonderfach“ gem. Ausbildungsordnung) z.B: „Facharzt/Fachärzting für Gynäkologie“,

Wenn ein Autor mehreren ärztlichen Sonderfächern zugeordnet ist, kann das anzugebende Sonderfach gewählt werden. Additivfächer werden nicht angegeben.
Grundsätzlich sind die Vorgaben für „code-Element CE CWE“ zu befolgen.

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.

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:assignedPerson
hl7:assignedAuthoringDevice

hl7:assignedPerson

… 1

Personendaten des Verfassers des Dokuments.

Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen.

Eingefügt

von 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Namen-Element (Person)

@use

cs

0 … 1

Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.

Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“.

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

hl7:prefix

ENXP

0 … *

Beliebig viele Präfixe zum Namen, z.B. Akademische Titel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!

@qualifier

cs

0 … 1

Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:family

ENXP

1 … *

M

Mindestens ein Hauptname (Nachname).

@qualifier

cs

0 … 1

Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:given

ENXP

1 … *

M

Mindestens ein Vorname

@qualifier

cs

0 … 1

Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:suffix

ENXP

0 … *

Beliebig viele Suffixe zum Namen

@qualifier

cs

0 … 1

Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:assignedAuthoringDevice

… 1

@classCode

cs

0 … 1

F

DEV

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:manufacturerModelName

SC

0 … 1

Hersteller und Modellbezeichnung des datenerstellenden Gerätes.

hl7:softwareName

SC

0 … 1

Bezeichnung (und ggf Version) der datenerstellenden Software.

hl7:representedOrganization

1 … 1

M

Eingefügt

von 1.2.40.0.34.6.0.11.9.5.2 Organization Compilation with id, name, addr and telecom v2 (DYNAMIC)

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … *

R

Beliebig viele, mindestens eine ID der Organisation. z.B.: ID aus dem GDA-Index, DVR-Nummer, ATU-Nummer, etc.

@root

uid

1 … 1

R

@extension

st

0 … 1

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.

hl7:telecom

TEL.AT

1 … *

R

Kontaktdaten der Organisation.

Grundsätzlich sind die Vorgaben für „Kontaktdaten-Element“ zu befolgen.

@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

1 … 1

R

Adresse der Organisation.

Beinhaltet 1.2.40.0.34.6.0.11.9.25.2 Address Compilation v2 (DYNAMIC)

hl7:author

Verfasser nicht bekannt/nicht anwendbar

wo [@nullFlavor]

@nullFlavor

cs

1 … 1

F

NA

Beispiel

hl7:time

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

hl7:assignedAuthor

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

hl7:id

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

7.3.5.6 Medikation Dosierungsvariante 1: Tagesdosierung doseQuantity

Id

1.2.40.0.34.6.0.11.9.54

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:33:32

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationDosierung1dq

Bezeichnung

Medikation Dosierungsvariante 1: Tagesdosierung doseQuantity

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30037 Dosierungsvariante 1: Tagesdosierung doseQuantity (2015‑09‑05)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30037 Dosierungsvariante 1: Tagesdosierung doseQuantity (2015‑09‑05)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

Auswahl

… 1

Elemente in der Auswahl:

hl7:doseQuantity[not(hl7:low|hl7:high)]
hl7:doseQuantity[hl7:low|hl7:high]

Constraint

Konditionale Konformität:
Menge in nicht-zählbaren Einheiten -> @unit 1..1 (required) aus Value-Set ELGA_MedikationMengenart
Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.) -> @unit 0..1 (otional) mit @unit aus Value-Set ELGA_MedikationMengenartAlternativ

hl7:doseQuantity

IVL_PQ

R

Dosis.
mit doseQuantity als IVL_PQ, aber als PQ instantiiert

wo [not(hl7:lowoder
hl7:high)]

@value

1 … 1

R

Tagesdosierung.

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:doseQuantity

IVL_PQ

R

mit doseQuantity als IVL_PQ

wo [hl7:lowoder
hl7:high]

hl7:low

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:high

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

7.3.5.7 Medikation Dosierungsvariante 1: Tagesdosierung effectiveTime

Id

1.2.40.0.34.6.0.11.9.50

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 17:02:58

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationDosierung1

Bezeichnung

Medikation Dosierungsvariante 1: Tagesdosierung effectiveTime

Beschreibung

Dosierungsvariante 1 (Tagesdosierung) bedeutet, dass die angegebene Dosis im Laufe eines bestimmten Zeitraums (z.B. an einem Tag, innerhalb einer Woche, …) eingenommen werden muss.

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30007 Dosierungsvariante 1: Tagesdosierung effectiveTime (2014‑09‑02)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30007 Dosierungsvariante 1: Tagesdosierung effectiveTime (2014‑09‑02)

ref

elgabbr-

Beispiel

Strukturbeispiel

<cda:effectiveTime operator="A" institutionSpecified="true">
<period value="1" unit="d"/></cda:effectiveTime>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:effectiveTime

PIVL_TS

C

Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [hl7:period and not(hl7:phase)]

@operator

cs

1 … 1

F

A

@institutionSpecified

bl

1 … 1

F

true

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..1 M
Dosierung nicht angegeben -> NP

hl7:period

PQ

1 … 1

R

Zeitraum für den die Dosis in doseQuantity vorgesehen ist.

@value

1 … 1

F

1

@unit

cs

1 … 1

R

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.69 ELGA_MedikationFrequenz (DYNAMIC)

7.3.5.8 Medikation Dosierungsvariante 2: Einzeldosierung

Id

1.2.40.0.34.6.0.11.9.51

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 17:07:42

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationDosierung2

Bezeichnung

Medikation Dosierungsvariante 2: Einzeldosierung

Beschreibung

Dosierungsvariante 2 (Einzeldosierung) bedeutet, dass zu gewissen Zeitpunkten des Tages eine gewisse Dosis eingenommen werden muss. Die Frequenz der Einnahme ist bei dieser Dosierungsvariante fixiert auf „täglich“.

Die Angabe dieser Dosierungsvariante erfolgt in Form eines „Split dosing“.

Im Falle von „Split dosing“ können die Einnahmezeitpunkte nicht einfach in Form eines zweiten effectiveTime und eines doseQuantity-Elements angegeben werden, sondern MÜSSEN als eigene „Komponenten“ (entryRelationship typeCode=“COMP“), welche jeweils den Zeitpunkt und die dazugehörige Dosis beinhalten, angegeben werden.

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30008 Dosierungsvariante 2: Einzeldosierung (2020‑07‑21 13:25:19)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30008 Dosierungsvariante 2: Einzeldosierung (2013‑12‑20)

ref

elgabbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:effectiveTime

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [2]

7.3.5.9 Medikation Dosierungsvariante 2: Einzeldosierung doseQuantity

Id

1.2.40.0.34.6.0.11.9.55

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:34:45

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationDosierung2dq

Bezeichnung

Medikation Dosierungsvariante 2: Einzeldosierung doseQuantity

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30039 Dosierungsvariante 2: Einzeldosierung doseQuantity (2013‑12‑19)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30039 Dosierungsvariante 2: Einzeldosierung doseQuantity (2013‑12‑19)

ref

elgabbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:doseQuantity

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Dosis bei Dosierungsvariante 1 und 3.

7.3.5.10 Medikation Dosierungsvariante 2: Einzeldosierung entryRelationship

Id

1.2.40.0.34.6.0.11.9.58

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:37:38

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationDosierung2er

Bezeichnung

Medikation Dosierungsvariante 2: Einzeldosierung entryRelationship

Beschreibung

Untergeordnete Komponenten für „Split dosing“ am Ende des ELGA MedikationVerordnungs-Entry MÜSSEN angegeben werden.

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.59	Inklusion	Medikation Splitdose-Einnahmezeitpunkte 1 (1.0.0+20250228)	DYNAMIC

Beziehung

Adaptation: Template 1.2.40.0.34.11.30040 Dosierungsvariante 2: Einzeldosierung entryRelationship (2020‑07‑21 13:36:02)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30040 Dosierungsvariante 2: Einzeldosierung entryRelationship (2014‑09‑01)

ref

elgabbr-

Beispiel

<hl7:entryRelationship typeCode="COMP">
<sequenceNumber value="1"/> 
</hl7:entryRelationship>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:entryRelationship

C

Komponente zur Aufnahme eines Einnahmezeitpunkts und –dosis bei Dosierungsvariante 2 und 4.

Wiederholung höchstens einmal je Zeitcode!

wo [hl7:substanceAdministration/hl7:effectiveTime [@xsi:type='EIVL_TS']]

@typeCode

cs

1 … 1

F

COMP

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..* M
Dosierung nicht angegeben -> NP

hl7:sequenceNumber

INT

1 … 1

M

Aufsteigende Nummerierung der Unterelemente.

Eingefügt

von 1.2.40.0.34.6.0.11.9.59 Medikation Splitdose-Einnahmezeitpunkte 1 (DYNAMIC)

hl7:substanceAdministration

1 … 1

M

Abbildung eines Einnahmezeitpunkts und –dosis als untergeordnetes substanceAdministration-Element.

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Menge in nicht-zählbaren Einheiten, zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS"
0..1	O	Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.), zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS" oder Freitext

hl7:effectiveTime

EIVL_TS

1 … 1

M

Zeitelement zur Aufnahme des Einnahmezeitpunkts.

wo [@xsi:type='EIVL_TS']

hl7:event

1 … 1

M

Einnahmezeitpunkt.

@code

cs

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.59 ELGA_Einnahmezeitpunkte (DYNAMIC)

hl7:offset

IVL_PQ

1 … 1

M

Zeitversatz (immer mit 0 Sekunden angegeben).

@value

1 … 1

F

0

@unit

cs

1 … 1

F

s

hl7:doseQuantity

IVL_PQ

1 … 1

M

Dosis.

hl7:consumable

1 … 1

M

hl7:manufacturedProduct

1 … 1

M

hl7:manufacturedMaterial

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

7.3.5.11 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause

Id

1.2.40.0.34.6.0.11.9.52

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 17:09:15

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationDosierung3

Bezeichnung

Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause

Beschreibung

Dosierungsvariante 3 (Tagesdosierung an bestimmten Tagen einer Woche) bedeutet, dass wie bei Dosierungsvariante 1 die angegebene Dosis im Laufe eines Tages eingenommen werden muss, wobei dies aber nur an bestimmten Wochentagen erfolgen soll. Die Frequenz der Einnahme ist bei dieser Dosierungsvariante fixiert auf „wöchentlich“.
Hinweis: Der Datentyp des effectiveTime-Elements der Dosierungsart ändert sich, wenn die Einnahme an EINEM (PIVL_TS) oder an MEHREREN Wochentagen (SXPR_TS, dazu mehrere comp-Unterelemente) erfolgen soll.

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30009 Dosierungsvariante 3: Tagesdosierung mit Einnahmepause (2015‑09‑05)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30009 Dosierungsvariante 3: Tagesdosierung mit Einnahmepause (2015‑09‑05)

ref

elgabbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

Auswahl

… 1

Elemente in der Auswahl:

hl7:effectiveTime[hl7:period and hl7:phase]
hl7:effectiveTime[hl7:comp]

hl7:effectiveTime

PIVL_TS

C

Für EIN Wochentag.
Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [hl7:period and hl7:phase]

@operator

cs

1 … 1

F

A

hl7:phase

IVL_TS

1 … 1

R

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag)

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:effectiveTime

SXPR_TS

C

Für mehrere Wochentage, z. B. wöchtentlich montags und mittwochs

wo [hl7:comp]

@operator

cs

1 … 1

F

A

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..1 M
Dosierung nicht angegeben -> NP

1. Komponentencontainer ohne @operator, ggf. folgende Komponentencontainer mit @operator=I

hl7:comp

PIVL_TS

1 … 1

R

Komponentencontainer.

wo [not(@operator)]

hl7:phase

IVL_TS

1 … 1

R

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag)

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:comp

PIVL_TS

0 … *

wo [@operator='I']

@operator

cs

1 … 1

F

I

hl7:phase

IVL_TS

1 … 1

R

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

7.3.5.12 Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity

Id

1.2.40.0.34.6.0.11.9.56

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:35:38

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationDosierung3dq

Bezeichnung

Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30041 Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity (2015‑09‑05)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30041 Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity (2015‑09‑05)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

Auswahl

… 1

Elemente in der Auswahl:

hl7:doseQuantity[not(hl7:low|hl7:high)]
hl7:doseQuantity[hl7:low|hl7:high]

Constraint

Konditionale Konformität:
Menge in nicht-zählbaren Einheiten -> @unit 1..1 (required) aus Value-Set ELGA_MedikationMengenart
Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.) -> @unit 0..1 (optional) aus Value-Set ELGA_MedikationMengenartAlternativ

hl7:doseQuantity

IVL_PQ

R

Dosis.
mit doseQuantity als IVL_PQ, aber als PQ instantiiert

wo [not(hl7:lowoder
hl7:high)]

@value

1 … 1

R

Tagesdosierung.

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:doseQuantity

IVL_PQ

R

mit doseQuantity als IVL_PQ

wo [hl7:lowoder
hl7:high]

hl7:low

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

hl7:high

PQ

@value

1 … 1

R

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.32 ELGA_MedikationMengenart (DYNAMIC)

oder

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.67 ELGA_MedikationMengenartAlternativ (DYNAMIC)

7.3.5.13 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause

Id

1.2.40.0.34.6.0.11.9.53

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:31:57

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationDosierung4

Bezeichnung

Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause

Beschreibung

Dosierungsvariante 4 (Einzeldosierung an bestimmten Tagen) bedeutet, dass wie bei Dosierungsvariante 2 zu gewissen Zeitpunkten des Tages eine gewisse Dosis eingenommen werden muss, wobei dies nur an bestimmten Tagen erfolgen soll. Die Frequenz der Einnahme ist bei dieser Dosierungsvariante fixiert auf „wöchentlich“.

Die Angabe dieser Dosierungsvariante erfolgt in Form eines „Split dosing“.

Im Falle von „Split dosing“ können die Einnahmezeitpunkte nicht einfach in Form eines zweiten effectiveTime und eines doseQuantity-Elements angegeben werden, sondern MÜSSEN als eigene „Komponenten“ (entryRelationship typeCode=“COMP“), welche jeweils den Zeitpunkt und die dazugehörige Dosis beinhalten, angegeben werden.

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30010 Dosierungsvariante 4: Einzeldosierung mit Einnahmepause (2020‑07‑21 13:28:53)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30010 Dosierungsvariante 4: Einzeldosierung mit Einnahmepause (2013‑12‑19)

ref

elgabbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:effectiveTime

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

wo [2]

7.3.5.14 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity

Id

1.2.40.0.34.6.0.11.9.57

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:36:30

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationDosierung4dq

Bezeichnung

Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30043 Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity (2013‑12‑19)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30043 Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity (2013‑12‑19)

ref

elgabbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:doseQuantity

NP

Das weitere effectiveTime-Element und das doseQuantity-Element nach dem effectiveTime-Element für die Einnahmedauer entfallen.
Dosis bei Dosierungsvariante 1 und 3.

7.3.5.15 Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship

Id

1.2.40.0.34.6.0.11.9.60

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:40:23

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationDosierung4er

Bezeichnung

Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship

Beschreibung

Untergeordnete Komponenten für „Split dosing“ am Ende des ELGA MedikationVerordnungs-Entry MÜSSEN angegeben werden.

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.61	Inklusion	Medikation Splitdose-Einnahmezeitpunkte 2 (1.0.0+20250228)	DYNAMIC

Beziehung

Adaptation: Template 1.2.40.0.34.11.30044 Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship (2020‑07‑21 13:37:00)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30044 Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship (2014‑09‑01)

ref

elgabbr-

Beispiel

<hl7:entryRelationship typeCode="COMP">
<sequenceNumber value="1"/> 
</hl7:entryRelationship>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:entryRelationship

C

Komponente zur Aufnahme eines Einnahmezeitpunkts und –dosis bei Dosierungsvariante 2 und 4.

Wiederholung höchstens einmal je Zeitcode!

wo [hl7:substanceAdministration/hl7:effectiveTime [@xsi:type='SXPR_TS']]

@typeCode

cs

1 … 1

F

COMP

Constraint

Konditionale Konformität:
Dosierung angegeben -> 1..* M
Dosierung nicht angegeben -> NP

hl7:sequenceNumber

INT

1 … 1

M

Aufsteigende Nummerierung der Unterelemente.

Eingefügt

von 1.2.40.0.34.6.0.11.9.61 Medikation Splitdose-Einnahmezeitpunkte 2 (DYNAMIC)

hl7:substanceAdministration

1 … 1

M

Abbildung eines Einnahmezeitpunkts und –dosis als untergeordnetes substanceAdministration-Element.

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Menge in nicht-zählbaren Einheiten, zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS"
0..1	O	Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.), zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS" oder Freitext

hl7:effectiveTime

SXPR_TS

1 … 1

M

Zeitelement zur Aufnahme des Einnahmezeitpunkts.

wo [@xsi:type='SXPR_TS']

Constraint

Die comp-Komponenten mit PIVL_TS müssen bei allen Einnahmezeitpunkten gleich angegeben werden!

1. Komponentencontainer mit @operator=A, ggf. folgende Komponentencontainer mit @operator=I

hl7:comp

EIVL_TS

1 … 1

M

Komponentencontainer

wo [@xsi:type='EIVL_TS']

hl7:event

1 … 1

M

Einnahmezeitpunkt.

@code

cs

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.59 ELGA_Einnahmezeitpunkte (DYNAMIC)

hl7:offset

IVL_PQ

1 … 1

M

Zeitversatz (immer mit 0 Sekunden angegeben).

@value

1 … 1

F

0

@unit

cs

1 … 1

F

s

hl7:comp

PIVL_TS

1 … 1

M

Komponentencontainer zur Aufnahme der Einnahmetage.
Diese Komponenten MÜSSEN bei allen Einnahmezeitpunkten (SequenceNumber) gleich angegeben werden!

wo [@xsi:type='PIVL_TS'] [@operator='A']

@operator

cs

1 … 1

F

A

hl7:phase

IVL_TS

1 … 1

R

Phase der Einnahme.

hl7:value

TS

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag).

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:comp

PIVL_TS

0 … *

2.+ Komponentencontainer zur Aufnahme der Einnahmetage

wo [@xsi:type='PIVL_TS'] [@operator='I']

hl7:phase

IVL_TS

1 … 1

R

hl7:value

TS

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:doseQuantity

IVL_PQ

1 … 1

M

Dosis.

hl7:consumable

1 … 1

M

hl7:manufacturedProduct

1 … 1

M

hl7:manufacturedMaterial

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

7.3.5.16 Medikation Einnahmedauer

Id

1.2.40.0.34.6.0.11.9.49

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 16:57:09

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationEinnahmedauer

Bezeichnung

Medikation Einnahmedauer

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30006 Einnahmedauer (2013‑12‑20)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30006 Einnahmedauer (2013‑12‑20)

ref

elgabbr-

Beispiel

Einnahme von 27.05.2011 bis 03.06.2011 bzw. Einnahme von 27.05.2011, Dauer 1 Woche lang

Beispiel

Einnahme von 27.05.2011, Ende unbekannt

Beispiel

Einnahmestart unbekannt, Dauer 2 Wochen lang

Beispiel

Dosierungsinformationen sind angegeben, aber Einnahmedauer unbekannt

Item

DT

Kard

Konf

Beschreibung

Label

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:effectiveTime[1][hl7:low]
hl7:effectiveTime[1][hl7:width]
hl7:effectiveTime[1][@nullFlavor]

hl7:effectiveTime

IVL_TS

0 … 1

R

Zeitelement zur Dokumentation der Einnahmedauer.

wo [1] [hl7:low]

hl7:low

TS

1 … 1

R

Zeitpunkt des Einnahmestarts.
Zugelassene nullFlavor: UNK

hl7:high

TS

1 … 1

R

Zeitpunkt des Einnahmeendes.
Zugelassene nullFlavor: UNK

hl7:effectiveTime

IVL_TS

0 … 1

R

Dauer der Einnahme, wenn Einnahmestart unbekannt

wo [1] [hl7:width]

hl7:width

PQ

1 … 1

M

Dauer der Einnahme, wenn Einnahmestart unbekannt

Bemerkung: Wenn ein width Element angegeben wird, MUSS auch die templateId für „Delay Start Dosing“ angegeben werden.

Siehe Kapitel „Template IDs"

@unit

cs

0 … 1

CONF

Der Wert von @unit MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.69 ELGA_MedikationFrequenz (DYNAMIC)

hl7:effectiveTime

IVL_TS

0 … 1

R

wo [1] [@nullFlavor]

@nullFlavor

cs

1 … 1

F

NA

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Wenn die Dosierungsvariante einer Verordnung "Split" ist, ist in der Verordnung die templateId 1.3.6.1.4.1.19376.1.5.3.1.4.9 anzugeben.
	NP	Sonst

7.3.5.17 Medikation ID des Containers

Id

1.2.40.0.34.6.0.11.9.65

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:46:09

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationIddescontainers

Bezeichnung

Medikation ID des Containers

Beschreibung

Wird das ELGA MedikationVerordnungs-Entry im Rahmen der Medikationsliste verwendet, MUSS die ID des Rezept-Dokuments, welches das Verordnungs-Entry ursprünglich beinhaltete, angegeben sein.

Bemerkung: Es ist immer die ID des Rezept-Dokuments anzugeben, mittels welchem das Verordnungs-Entry ursprünglich angelegt wurde, auch wenn z.B. das vorliegende Verordnungs-Entry das Ergebnis von Änderungen mittels Pharmazeutischer Empfehlungen ist und demnach eine andere VerordnungsID als das ursprüngliche besitzt.

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.90013 ID des Containers (2020‑07‑21 13:38:52)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.90013 ID des Containers (2015‑04‑23)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:reference

ID des Verordnungs-Entry Containers (Rezept-Dokument).

@typeCode

cs

1 … 1

F

XCRPT

hl7:externalDocument

1 … 1

M

hl7:id

II

1 … 1

M

ID des MedikationVerordnung-Entry.

@root

uid

1 … 1

F

1.2.40.0.10.1.4.3.4.2.1

@extension

st

1 … 1

R

Verpflichtende eMED-ID

7.3.5.18 Medikation Patient Instructions

Id

1.2.40.0.34.6.0.11.9.62

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:42:42

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationPatientInstructions

Bezeichnung

Medikation Patient Instructions

Beschreibung

Abbildung der Zusatzbemerkungen zu Verordnungen, Abgaben oder Korrekturmeldungen (Pharmazeutische Empfehlungen)

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.9.62

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30033 Patient Instructions (2020‑10‑06 13:32:41)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30033 Patient Instructions (2014‑09‑10)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:act

Abbildung der Zusatzbemerkungen als untergeordnetes act-Element.

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.49

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

PINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die Zusatzinformationen für den Patienten, Informationen zur alternativen Einnahme und Informationen zur Arznei angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#patinfo-{generierteID}, z.B.: #patinfo-1

Schematron assert

role

error

test

starts-with(@value, '#patinfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 3

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.1

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.161 ELGA_ActCode_PatInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#zinfo|altein|arzneiinfo|veri-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #altein-1

Schematron assert

role

error

test

starts-with(@value, '#zinfo-') or starts-with(@value, '#altein-') or starts-with(@value, '#arzneiinfo-') or starts-with(@value, '#veri-')

Meldung

Die Referenz muss mit "#zinfo-", "#altein-", "#arzneiinfo-" oder "#veri-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:effectiveTime

IVL_TS

0 … 1

C

Constraint

Wenn eine Verifizierung, d.h. eine Überprüfung, ob das Arzneimittel wie für diese Behandlung vorgesehen wirkt, mit "veri" im code-Element oder mit "#veri-{generierteID}" im reference-Element festgelegt wird, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime-Element festgelegt werden.

7.3.5.19 Medikation Pharmacist Instructions

Id

1.2.40.0.34.6.0.11.9.63

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:44:04

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationPharmacistInstructions

Bezeichnung

Medikation Pharmacist Instructions

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.6.0.11.9.63

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30034 Pharmacist Instructions (2020‑10‑06 13:34:04)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30034 Pharmacist Instructions (2014‑09‑10)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:act

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.43

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.3.1

hl7:code

CE

1 … 1

M

@code

CONF

1 … 1

F

FINSTRUCT

@codeSystem

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.2

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die ergänzenden Informationen zur Abgabe oder zu der magistralen Zubereitungen angeführt sind)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#abginfo-{generierteID}, z.B.: #abginfo-1

Schematron assert

role

error

test

starts-with(@value, '#abginfo-')

Meldung

Die Referenz muss mit "#patinfo-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 2

M

Komponente zur Aufnahme der Referenz zu einer Unterkategorie (mindestens eine Unterkategorie muss angegeben sein).

@typeCode

cs

1 … 1

F

SUBJ

@inversionInd

bl

1 … 1

F

true

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.0.3.2

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.160 ELGA_ActCode_AbgInfo (DYNAMIC)

hl7:text

ED

1 … 1

M

Text Element (verweist auf die Stelle im narrativen Text-Bereich, an der die entsprechende Unterkategorie angeführt ist)

hl7:reference

TEL

1 … 1

M

@value

1 … 1

R

#erginfo|magzub-{generierteID} Der Prefix muss dem gewählten Code entsprechen. z.B.: #magzub-1

Schematron assert

role

error

test

starts-with(@value, '#erginfo-') or starts-with(@value, '#magzub-')

Meldung

Die Referenz muss mit "#erginfo-" oder "#magzub-" starten!

hl7:statusCode

CS

1 … 1

M

@code

CONF

1 … 1

F

completed

7.3.5.20 Medikation Sbadm TemplateId Options

Id

1.2.40.0.34.6.0.11.9.48

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 16:51:45

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationSbadmtemplateidoptions

Bezeichnung

Medikation Sbadm TemplateId Options

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.90012 Sbadm TemplateId Options (2015‑02‑17)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.90012 Sbadm TemplateId Options (2015‑02‑17)

ref

elgabbr-

Beispiel

Strukturbeispiel Dosierungsvariante 1: Tagesdosierung

Beispiel

Strukturbeispiel Dosierungsvariante 2 (Einzeldosierung)

Item

DT

Kard

Konf

Beschreibung

Label

hl7:templateId

II

C

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.21

Constraint

Konditionale Konformität

Einnahmedauer beinhaltet low/high Elemente Conf: NP
Einnahmedauer beinhaltet ein width Element: Card 1..1 Conf M

Auswahl

0 … 1

Dosierungsart, mögliche Werte:

a) Normal: @root = 1.3.6.1.4.1.19376.1.5.3.1.4.7.1

b) Split: @root = 1.3.6.1.4.1.19376.1.5.3.1.4.9

c) keine Dosierung: templateID Element entfällt vollständig.

Dosierungsart: Normal (1.3.6.1.4.1.19376.1.5.3.1.4.7.1), Split (1.3.6.1.4.1.19376.1.5.3.1.4.9) oder keine Dosierung (keine der beiden TemplateIDs)

Elemente in der Auswahl:

hl7:templateId
hl7:templateId

hl7:templateId

II

0 … 1

R

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.7.1

hl7:templateId

II

0 … 1

R

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.9

7.3.5.21 Medikation Splitdose-Einnahmezeitpunkte 1

Id

1.2.40.0.34.6.0.11.9.59

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:38:53

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationSplitdose1

Bezeichnung

Medikation Splitdose-Einnahmezeitpunkte 1

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30046 Splitdose-Einnahmezeitpunkte 1 (2015‑09‑05)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30046 Splitdose-Einnahmezeitpunkte 1 (2015‑09‑05)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:substanceAdministration

1 … 1

M

Abbildung eines Einnahmezeitpunkts und –dosis als untergeordnetes substanceAdministration-Element.

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Menge in nicht-zählbaren Einheiten, zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS"
0..1	O	Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.), zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS" oder Freitext

hl7:effectiveTime

EIVL_TS

1 … 1

M

Zeitelement zur Aufnahme des Einnahmezeitpunkts.

wo [@xsi:type='EIVL_TS']

hl7:event

1 … 1

M

Einnahmezeitpunkt.

@code

cs

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.59 ELGA_Einnahmezeitpunkte (DYNAMIC)

hl7:offset

IVL_PQ

1 … 1

M

Zeitversatz (immer mit 0 Sekunden angegeben).

@value

1 … 1

F

0

@unit

cs

1 … 1

F

s

hl7:doseQuantity

IVL_PQ

1 … 1

M

Dosis.

hl7:consumable

1 … 1

M

hl7:manufacturedProduct

1 … 1

M

hl7:manufacturedMaterial

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

7.3.5.22 Medikation Splitdose-Einnahmezeitpunkte 2

Id

1.2.40.0.34.6.0.11.9.61

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:41:24

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationSplitdose2

Bezeichnung

Medikation Splitdose-Einnahmezeitpunkte 2

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.40.0.34.11.30047 Splitdose-Einnahmezeitpunkte 2 (2015‑09‑05)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.30047 Splitdose-Einnahmezeitpunkte 2 (2015‑09‑05)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:substanceAdministration

1 … 1

M

Abbildung eines Einnahmezeitpunkts und –dosis als untergeordnetes substanceAdministration-Element.

@classCode

cs

1 … 1

F

SBADM

@moodCode

cs

1 … 1

F

INT

Constraint

Konditionale Konformität

Card	Conf	Prädikat
1..1	M	Menge in nicht-zählbaren Einheiten, zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS"
0..1	O	Menge in zählbaren Einheiten (Tabletten, Kapseln, etc.), zulässige Werte gemäß Value-Set "ELGA_MedikationMengenart_VS" oder Freitext

hl7:effectiveTime

SXPR_TS

1 … 1

M

Zeitelement zur Aufnahme des Einnahmezeitpunkts.

wo [@xsi:type='SXPR_TS']

Constraint

Die comp-Komponenten mit PIVL_TS müssen bei allen Einnahmezeitpunkten gleich angegeben werden!

1. Komponentencontainer mit @operator=A, ggf. folgende Komponentencontainer mit @operator=I

hl7:comp

EIVL_TS

1 … 1

M

Komponentencontainer

wo [@xsi:type='EIVL_TS']

hl7:event

1 … 1

M

Einnahmezeitpunkt.

@code

cs

1 … 1

R

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.59 ELGA_Einnahmezeitpunkte (DYNAMIC)

hl7:offset

IVL_PQ

1 … 1

M

Zeitversatz (immer mit 0 Sekunden angegeben).

@value

1 … 1

F

0

@unit

cs

1 … 1

F

s

hl7:comp

PIVL_TS

1 … 1

M

Komponentencontainer zur Aufnahme der Einnahmetage.
Diese Komponenten MÜSSEN bei allen Einnahmezeitpunkten (SequenceNumber) gleich angegeben werden!

wo [@xsi:type='PIVL_TS'] [@operator='A']

@operator

cs

1 … 1

F

A

hl7:phase

IVL_TS

1 … 1

R

Phase der Einnahme.

hl7:value

TS

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag).

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:comp

PIVL_TS

0 … *

2.+ Komponentencontainer zur Aufnahme der Einnahmetage

wo [@xsi:type='PIVL_TS'] [@operator='I']

hl7:phase

IVL_TS

1 … 1

R

hl7:value

TS

hl7:period

PQ

1 … 1

R

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:doseQuantity

IVL_PQ

1 … 1

M

Dosis.

hl7:consumable

1 … 1

M

hl7:manufacturedProduct

1 … 1

M

hl7:manufacturedMaterial

1 … 1

R

@nullFlavor

cs

1 … 1

F

NA

7.3.5.23 Medikation Therapieart

Id

1.2.40.0.34.6.0.11.9.64

ref

at-cda-bbr-

Gültigkeit ab

2025‑02‑28 18:45:08

Status

Entwurf

Versions-Label

1.0.0+20250228

Name

atcdabbr_other_MedikationTherapieart

Bezeichnung

Medikation Therapieart

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.6.0.11.9.2	Inklusion	Original Text Reference (1.0.0+20210219)	DYNAMIC

Beziehung

Adaptation: Template 1.2.40.0.34.11.30045 Therapieart (2014‑09‑10)

ref

elgabbr-

Beispiel

<hl7:entryRelationship typeCode="COMP">
  <act classCode="ACT" moodCode="INT">
    <templateId root="1.2.40.0.34.11.8.1.3.4"/>    <code code="EINZEL" codeSystem="1.2.40.0.10.1.4.3.4.3.6" displayName="Einzelverordnung">
      
    </code>  </act></hl7:entryRelationship>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:entryRelationship

0 … 1

Therapieart dieses MedikationVerordnung-Entry

wo [@typeCode='COMP'] [hl7:act/hl7:templateId [@root='1.2.40.0.34.11.8.1.3.4']]

@typeCode

cs

1 … 1

F

COMP

Beispiel

hl7:act

1 … 1

M

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

INT

hl7:templateId

II

1 … 1

M

@root

uid

1 … 1

F

1.2.40.0.34.11.8.1.3.4

hl7:code

CE

1 … 1

M

CONF

Der Wert von @code MUSS gewählt werden aus dem Value Set 1.2.40.0.34.10.30 ELGA_MedikationTherapieArt (DYNAMIC)

Eingefügt

0 … 1

R

von 1.2.40.0.34.6.0.11.9.2 Original Text Reference (DYNAMIC)

hl7:originalText

ED

0 … 1

R

Textinhalt, der codiert wurde.

hl7:reference

TEL

1 … 1

M

Die Referenz auf den entsprechenden Text im narrativen Teil muss durch Bezugnahme auf den Inhalt[@ID] angegeben werden: reference[@value='#xxx'].
Die Referenz ist mit einem content-Element mit ID-Attribut anzugeben, dieses Element DARF NUR den Textinhalt des codierten Inhalts umschließen und KEINE zusätzlichen Markup oder Strukturelemente.

@value

1 … 1

R

Schematron assert

role

error

test

starts-with(@value,'#')

Meldung

The @value attribute content MUST conform to the format '#xxx', where xxx is the ID of the corresponding 'content'-element.

7.3.5.24 Person Name Compilation G2 M

Id

1.2.40.0.34.6.0.11.9.11

ref

at-cda-bbr-

Gültigkeit ab

2023‑03‑31 11:20:05

Andere Versionen mit dieser Id:

atcdabbr_other_PersonNameCompilationG2M vom 2021‑02‑19 13:36:55
atcdabbr_other_PersonNameCompilationG2M vom 2019‑04‑02 10:09:43

Status

Aktiv

Versions-Label

1.0.1+20230717

Name

atcdabbr_other_PersonNameCompilationG2M

Bezeichnung

Person Name Compilation G2 M

Beschreibung

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.

Klassifikation

Template-Typ nicht spezifiziert

Offen/Geschlossen

Geschlossen (nur definierte Elemente sind erlaubt)

Beziehung

Version: Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (2021‑02‑19 13:36:55)

ref

at-cda-bbr-

Version: Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (2019‑04‑02 10:09:43)

ref

at-cda-bbr-

Adaptation: Template 1.2.40.0.34.6.0.11.9.6 Person Name Compilation G2 (2019‑02‑12 14:00:33)

ref

at-cda-bbr-

Beispiel

Strukturbeispiel

<name use="L">
<prefix qualifier="NB">Gräfin</prefix> <given>Sissi</given> <family>Österreich</family> <family qualifier="BR">Habsburg</family> <suffix qualifier="AC">MSc</suffix></name>

Item

DT

Kard

Konf

Beschreibung

Label

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Namen-Element (Person)

@use

cs

0 … 1

Die genaue Bedeutung des angegebenen Namens, z.B. Angabe eines Künstlernamens mit „A" für „Artist“.

Zulässige Werte gemäß Value Set „ELGA_EntityNameUse“.

Wird kein @use Attribut angegeben, gilt der Name als rechtlicher Name („L“).

hl7:prefix

ENXP

0 … *

Beliebig viele Präfixe zum Namen, z.B. Akademische Titel

Achtung: Die Angabe der Anrede („Frau“, „Herr“), ist im CDA nicht vorgesehen!

@qualifier

cs

0 … 1

Bedeutung eines prefix-Elements, z.B. Angabe eines akademischen mit "AC" für „Academic“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier".

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:family

ENXP

1 … *

M

Mindestens ein Hauptname (Nachname).

@qualifier

cs

0 … 1

Bedeutung eines family-Elements, z.B. Angabe eines Geburtsnamen mit „BR" für „Birth“.

Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:given

ENXP

1 … *

M

Mindestens ein Vorname

@qualifier

cs

0 … 1

Die genaue Bedeutung eines given-Elements, beispielsweise dass das angegebene Element einen Geburtsnamen bezeichnet, z.B. BR („Birth“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

hl7:suffix

ENXP

0 … *

Beliebig viele Suffixe zum Namen

@qualifier

cs

0 … 1

Die genaue Bedeutung eines suffix-Elements, beispielsweise dass das angegebene Suffix einen akademischen Titel darstellt, z.B.: AC („Academic“).
Zulässige Werte gemäß Value Set „ELGA_EntityNamePartQualifier“.

CONF

Der Wert von @qualifier MUSS gewählt werden aus dem Value Set 1.2.40.0.34.6.0.10.8 ELGA_EntityNamePartQualifier (DYNAMIC)

8 Anhang

8.1 Tabellenverzeichnis

↑ Übersichtstabelle der CDA Strukturen des Headers
↑ Übersichtstabelle der e-Medikation CDA Strukturen

8.2 Einzelnachweise

↑ Logical Observation Identifiers Names & Codes (LOINC) loinc.org
↑ ^2,0 ^2,1 Regenstrief Institute, Inc. www.regenstrief.org
↑ Unified Code for Units of Measure (UCUM) www.unitsofmeasure.org
↑ WHO ICD-10 www.who.int/classifications/icd/en/
↑ ^5,0 ^5,1 www.who.int
↑ Internationale statistische Klassifikation der Krankheiten und verwandter Gesundheitsprobleme 10. Revision, hier unter dem neuesten LKF Paket auffindbar
↑ Anatomical Therapeutic Chemical Classification System (ATC) https://www.who.int/tools/atc-ddd-toolkit/atc-classification
↑ ARGE Pharma im Fachverband der chemischen Industrie Österreichs (FCIO) argepharma.fcio.at
↑ EDQM Council of Europe www.edqm.eu
↑ Health informatics - Medical / health device communication standards ISO/IEEE 11073 Nomenclature Part 10101: Nomenclature
↑ Health informatics - Medical / health device communication standards ISO/IEEE 11073 Nomenclature Amendment 1 Part 10101: Nomenclature Amendment 1: Additional Definitions
↑ Österreichischer e-Health Terminologieserver: termgit.elga.gv.at
↑ Health Level Seven International [1]
↑ ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical Document Architecture, Release 2 [2]
↑ World Wide Web Consortium. Extensible Markup Language, 1.0, 5th Edition. [3]
↑ HL7 Version 3 Product Suite [4]
↑ ART-DECOR® www.art-decor.org
↑ HL7 Clinical Document Architecture (CDA) [5]
↑ HL7 Version 3: Reference Information Model (RIM) [6]
↑ HL7 Version 3 Standard: Data Types – Abstract Specification, Release 2[7]
↑ HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 [8]
↑ HL7 Austria [9]

8.3 Literatur und Weblinks

Clinical Document Architcture (CDA®) Release 2.0 https://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
Boone, Keith W. "The CDA-Book", Springer, 2011 https://www.springer.com/gp/book/9780857293350
Anleitungsartikel "Art-Decor-Tabellen verstehen (auf wiki.hl7.at)".

8.4 Revisionsliste/Release-Log und Erratum

Der Release-Log, weitere Hinweise wie auch bekannte Probleme werden auf der Diskussionsseite im Wiki gesammelt.

[23] Übersichtstabelle der CDA Strukturen des Headers

[24] Übersichtstabelle der e-Medikation CDA Strukturen

[LOINC-1] Logical Observation Identifiers Names & Codes (LOINC) loinc.org

[regenstrief-2] 2,0 ^2,1 Regenstrief Institute, Inc. www.regenstrief.org

[UCUM-3] Unified Code for Units of Measure (UCUM) www.unitsofmeasure.org

[ICD-10-4] WHO ICD-10 www.who.int/classifications/icd/en/

[WHO-5] 5,0 ^5,1 www.who.int

[ICD-10-AT-6] Internationale statistische Klassifikation der Krankheiten und verwandter Gesundheitsprobleme 10. Revision, hier unter dem neuesten LKF Paket auffindbar

[7] Anatomical Therapeutic Chemical Classification System (ATC) https://www.who.int/tools/atc-ddd-toolkit/atc-classification

[FCIO-8] ARGE Pharma im Fachverband der chemischen Industrie Österreichs (FCIO) argepharma.fcio.at

[9] EDQM Council of Europe www.edqm.eu

[11073nomenclature-10] Health informatics - Medical / health device communication standards ISO/IEEE 11073 Nomenclature Part 10101: Nomenclature

[11073nomenclatureamendment-11] Health informatics - Medical / health device communication standards ISO/IEEE 11073 Nomenclature Amendment 1 Part 10101: Nomenclature Amendment 1: Additional Definitions

[Terminologieserver-12] Österreichischer e-Health Terminologieserver: termgit.elga.gv.at

[HL7-13] Health Level Seven International [1]

[14] ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical Document Architecture, Release 2 [2]

[15] World Wide Web Consortium. Extensible Markup Language, 1.0, 5th Edition. [3]

[16] HL7 Version 3 Product Suite [4]

[17] ART-DECOR® www.art-decor.org

[CDA-18] HL7 Clinical Document Architecture (CDA) [5]

[RIM-19] HL7 Version 3: Reference Information Model (RIM) [6]

[HL7_Version_3_Standard:_Data_Types-20] HL7 Version 3 Standard: Data Types – Abstract Specification, Release 2[7]

[Templates_Specification-21] HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 [8]

[22] HL7 Austria [9]

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[Tabelle 1]

[Tabelle 2]

@@ Zeile 5: / Zeile 5: @@
 |description=Die e-Medikation enthält Daten zu einer Person einzelnen Verordnungen, Abgaben, pharmazeutischen Empfehlungen und diese nochmals gesammelt als Medikationsliste.
 }}
-{{#customtitle:e-Medikation (Version 3.0.0+20250228-ballot)}}
+{{#customtitle:e-Medikation (Version 3.0.0+20250615)}}
 {{#css:
 @media Screen{
@@ Zeile 41: / Zeile 41: @@
 |Namespace = ILF
 |Type      = Implementierungsleitfaden
-|Version   = 3.0.0+20250228-ballot
+|Version   = 3.0.0+20250615
 |Submitted = ELGA GmbH
 |Copyright = © HL7 Austria 2025
@@ Zeile 62: / Zeile 62: @@
 Die Grundlage der Datenaustauschformate ist der internationale [[CDA-Grundlagen|CDA-Standard]], der sich in ELGA bereits bewährt hat. Er erlaubt es Sender und Empfänger, sich ohne vorherige Absprache zu verstehen. Der Standard hat zum Ziel, einen umfassenden Austausch von semantisch interoperablen Informationen zwischen allen beteiligten Akteuren bei der Behandlung von Patienten zu ermöglichen. Der Datenaustausch findet hierbei nicht nur innerhalb einer Einrichtung, sondern auch zwischen kooperierenden Einrichtungen und über Sektorengrenzen hinaus statt. Die Empfänger der Dokumente sollen die Inhalte benutzen und weiterverwenden können, ohne sich vorher mit dem Ersteller absprechen zu müssen.
-Die wesentliche Funktion von ELGA ist die Bereitstellung von patientenbezogenen medizinischen Dokumenten, die in vielen unterschiedlichen Informationssystemen der verschiedenen Gesundheitsdiensteanbieter erstellt werden. Zu den relevanten medizinischen Daten gehören auch die Medikationsdaten, die über die ELGA-Anwendung „e-Medikation“ verfügbar gemacht werden. Dazu errichtet und betreibt der Hauptverband der Sozialversicherungen ein Informationssystem, das Ärzten, Apothekern und den ELGA- Teilnehmern selbst eine Übersicht über verordnete und abgegebene Medikamente bietet. Diese Medikationsdaten sollen nicht nur von Benutzern gelesen, sondern auch wieder in die IT-Systeme integriert und dort weiterverwendet werden können („Semantische Interoperabilität“). Rechtsgrundlage für die Umsetzung der e-Medikation ist das „ELGA-Gesetz“ (GTelG 2012 §16a) sowie die „ELGA-Verordnung“ (ELGA-VO 2015 §14, 15 und 16).
+Die wesentliche Funktion von ELGA ist die Bereitstellung von patientenbezogenen medizinischen Dokumenten, die in vielen unterschiedlichen Informationssystemen der verschiedenen Gesundheitsdiensteanbieter erstellt werden. Zu den relevanten medizinischen Daten gehören auch die Medikationsdaten, die über die ELGA-Anwendung „e-Medikation“ verfügbar gemacht werden. Dazu errichtet und betreibt der Hauptverband der Sozialversicherungen ein Informationssystem, das Ärzten, Apothekern und den ELGA-Teilnehmern selbst eine Übersicht über verordnete und abgegebene Medikamente bietet. Diese Medikationsdaten sollen nicht nur von Benutzern gelesen, sondern auch wieder in die IT-Systeme integriert und dort weiterverwendet werden können („Semantische Interoperabilität“). Rechtsgrundlage für die Umsetzung der e-Medikation ist das „ELGA-Gesetz“ (GTelG 2012 §16a) sowie die „ELGA-Verordnung“ (ELGA-VO 2015 §14, 15 und 16).
 Der Implementierungsleitfaden orientiert sich an den elementaren Konzepten und dem zugrunde liegenden Modell des Dokuments [[ILF:Allgemeiner_Implementierungsleitfaden_2020|Allgemeiner Implementierungsleitfaden]]. Dort werden die notwendigen Datentypen, Dokument-Metadaten (Header), die Möglichkeiten der Textstrukturierung, grundlegende Vorgaben für die Anwendung von Terminologien, einige allgemein genutzten Inhaltsstrukturen (Sections) sowie Codebeispiele und praktische Implementierungshilfen gezeigt. Alle weiteren, für diesen Leitfaden benötigten Elemente werden hier erklärt. Die Notation der Spezifikation der Datenaustauschformate folgt der "Art-Decor"-Schreibweise, die auf einer eigenen Seite ([[Hilfe:Art-Decor-Tabellen_verstehen|Art-Decor-Tabellen verstehen]]) erläutert wird.
@@ Zeile 77: / Zeile 77: @@
 '''Parallelbetriebs-Informationen e-Medikation v2 und v3'''
-Für die 18-monatige Übergangszeit wird die ersten zwölf Monate die v2 Medikationsliste als Default beim Abruf geliefert werden. Danach wird für die restliche Übergangszeit wie auch danach die v3 Medikationsliste als Default beim Abruf geliefert. Nach der Übergangszeit werden nur noch v3 Dokumente akzeptiert. Beim Abruf einzelner Rezepte, Abgaben oder Pharmazeutischen Empfehlungen werden die Dokumente in jeweils der Version geliefert, in welcher sie auch erstellt wurden.
+Während der 18-monatigen Übergangszeit wird in den ersten zwölf Monaten die v2-Medikationsliste standardmäßig beim Abruf bereitgestellt. Anschließend wird für die verbleibende Übergangszeit sowie danach die v3-Medikationsliste standardmäßig geliefert. Nach der Übergangszeit werden nur noch v3 Dokumente akzeptiert. Beim Abruf einzelner Rezepte, Abgaben oder von Pharmazeutischen Empfehlungen werden die Dokumente in jeweils der Version geliefert, in welcher sie auch erstellt wurden. Weiters können v3 Abgaben auf v2 Rezepte folgen, wie auch v2 Abgaben auf v3 Rezepte. Das selbe gilt auch für die Pharmazeutische Empfehlung.
-Eine Abwärtskompatibilität zwischen v2 und v3 ist nicht möglicht. Sobald der v3 Leitfaden verordnet ist, werden die zusätzlich möglichen Inhalte der v3 Dokumente zumindest im narrativen Teil der v2 Dokumente abgebildet. Um die neuen v3 Informationen maschinenlesbar zu bekommen, müssen die neuen v3 Dokumente selbst verwendet werden!
+Eine Abwärtskompatibilität zwischen v2 und v3 ist nicht möglich. Sobald der v3 Leitfaden verordnet ist, werden die zusätzlich möglichen Inhalte der v3 Dokumente zumindest im narrativen Teil der v2 Dokumente abgebildet. Um die Maschinenlesbarkeit der neuen v3-Informationen zu erlangen, müssen die neuen v3-Dokumente selbst verwendet werden!
 {{EndYellowBox}}
@@ Zeile 90: / Zeile 90: @@
 ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050<br />
 Internet: [[http://www.elga.gv.at|www.elga.gv.at]]<br />
-Email: [[mailto:cda@elga.gv.at|cda@elga.gv.at]]
+E-Mail: [[mailto:cda@elga.gv.at|cda@elga.gv.at]]<br />
+Geschäftsführer: Mag. Dr. Stefan Sabutsch, Dr. Edith Bulant-Wodak, MBA
+''Redaktion, Projektleitung, Koordination: ''<br />
+* Mag. Dr. Stefan Sabutsch, [mailto:stefan.sabutsch@elga.gv.at stefan.sabutsch@elga.gv.at]
+* Dr. Emmanuel Helm, [mailto:emmanuel.helm@elga.gv.at emmanuel.helm@elga.gv.at] (Version 3)
 ''Abbildungen:'' © ELGA GmbH
@@ Zeile 97: / Zeile 102: @@
 Die Nutzung ist ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.
-Download unter [[https://www.gesundheit.gv.at|www.gesundheit.gv.at]] und [[https://www.elga.gv.at/cda|www.elga.gv.at/cda]]
+Download unter [[https://www.gesundheit.gv.at|www.gesundheit.gv.at]] und [[https://www.elga.gv.at/technischer-hintergrund/technische-elga-leitfaeden/|www.elga.gv.at/]]
 </div></div>
@@ Zeile 118: / Zeile 123: @@
 Die Verbindlichkeit und die Umsetzungsfrist dieses Leitfadens sind im Gesundheitstelematikgesetz 2012, BGBl.I Nr.111/2012 sowie in den darauf fußenden ELGA-Verordnungen geregelt.
-Der Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten ("Mandatory" [M], "Required" [R] und "Fixed" [F]), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.
+Der Leitfaden in seiner jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind vom zuständigen Minister auf [[https://www.gesundheit.gv.at|www.gesundheit.gv.at]] zu veröffentlichen. Der Zeitplan zur Bereitstellung der Datenaustauschformate wird durch das Gesundheitstelematikgesetz 2012 und darauf basierenden Durchführungsverordnungen durch den zuständigen Bundesminister vorgegeben. Hauptversionen, also Aktualisierungen des Implementierungsleitfadens, welche zusätzliche verpflichtende Konformitätskriterien enthalten ("Mandatory" [M], "Required" [R] und "Fixed" [F]), sind mit ihren Fristen zur Bereitstellung per Verordnung kundzumachen. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter [[https://www.gesundheit.gv.at|www.gesundheit.gv.at]]veröffentlicht werden.
 Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit österreichischem und europäischem Recht, insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz, Gesundheitstelematikgesetz 2012, DSGVO) zu erfolgen. Technische Möglichkeiten können gesetzliche Bestimmungen selbstverständlich nicht verändern, vielmehr sind die technischen Möglichkeiten im Einklang mit den Gesetzen zu nutzen.
@@ Zeile 138: / Zeile 143: @@
 {{BeginILFBox}}
 Die e-Medikation basiert auf den Vorgaben des '''[[ILF:Allgemeiner_Implementierungsleitfaden_2020|Allgemeinen Implementierungsleitfadens (Version 3)]]'''.{{EndILFBox}}
-Für die Modellierung der technischen Spezifikation der Inhalte wurde bei dieser Hauptversion der e-Medikation die [[https://art-decor.ehdsi.eu/art-decor/decor-templates--epsos-|Art-Decor Spezifikation des eHDSI CDA Leitfaden für "eHDSI ePrescription" und "eHDSI eDispensation"]] als wesentliche Grundlage gewählt, um eine "Abwärtskompatibilität" herzustellen. Das Bedeutet, das jedes e-Medikation Rezept CDA nach eHDSI ePrescription Spezifikation valide ist und jedes e-Medikation Abgabe CDA nach eHDSI eDispensation Spezifikation valide ist. Für eine tatsächliche Übertragung in den eHDSI Kontext wären jedoch Transformations-Schritte notwendig! Darunter fallen die Auftrennung jeder Verordnungen in einzelne Rezepte, die Auftrennung von jedem Abgabe-Entry in eine eigene Abgabe wie auch das Herausextrahieren der Informationen der Pharmazeutischen Empfehlung als einzelne ePrescription oder eDispensations. Zusätzlich sind Übersetzungen von Terminologien notwendig. Man beachte jedoch das andersrum, nicht jede eHDSI ePrescription oder eHDSI eDispensation valdie zur e-Medikation Spezifikation sind!
+Für die Modellierung der technischen Spezifikation der Inhalte wurde bei dieser Hauptversion der e-Medikation die [[https://art-decor.ehdsi.eu/art-decor/decor-templates--epsos-|Art-Decor Spezifikation des eHDSI CDA Leitfaden für "eHDSI ePrescription" und "eHDSI eDispensation"]] als wesentliche Grundlage gewählt, um eine "Abwärtskompatibilität" herzustellen. Das Bedeutet, das jedes e-Medikation Rezept CDA nach eHDSI ePrescription Spezifikation valide ist und jedes e-Medikation Abgabe CDA nach eHDSI eDispensation Spezifikation valide ist. Für eine tatsächliche Übertragung in den eHDSI Kontext wären jedoch Transformations-Schritte notwendig! Darunter fallen die Auftrennung jeder Verordnung in einzelne Rezepte, die Auftrennung von jedem Abgabe-Entry in eine eigene Abgabe wie auch das Extrahieren der Informationen der Pharmazeutischen Empfehlung als einzelne ePrescription oder eDispensations. Zusätzlich sind Übersetzungen von Terminologien notwendig. Es ist jedoch zu beachten, dass umgekehrt nicht jede eHDSI ePrescription oder eHDSI eDispensation valide zur e-Medikation Spezifikation sind!
 ==Wichtige unterstützende Materialien==
@@ Zeile 148: / Zeile 153: @@
 * CDA2PDF Suite (Tool zur Erzeugung einer PDF-Datei zur Ausgabe am Drucker)
 * ein erweitertes CDA-Schema
-* Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
+* Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA-Dateien
 Die im weiteren angeführten Templatespezifikationen wurden im Art-Decor Projektrepository [[https://art-decor.org/art-decor/decor-templates--at-emed-?section=templates|e-Medikation]] erstellt und können dort eingesehen werden.
@@ Zeile 163: / Zeile 168: @@
 ''<u>Themenbezogene Hinweise zur besonderen Beachtung:</u>''
 {{BeginYellowBox}}
-'''Hinweis:'''<br />Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden
+'''Hinweis:'''<br />Es dürfen keine Elemente oder Attribute verwendet werden, die nicht vom allgemeinen oder einem speziellen ELGA-Implementierungsleitfaden definiert wurden.
 {{EndYellowBox}}
 ''<u>Hinweis auf anderen Implementierungsleitfaden:</u>''
@@ Zeile 169: / Zeile 174: @@
 '''Verweis'''<br />Verweis auf den Allgemeinen Leitfaden:…
 {{EndILFBox}}
-''<u>Themenbezogenes CDA Beispiel-Fragment im XML Format:</u>''
-<pre class="ilfbox_code">
-<BEISPIEL>
-<languageCode code="de-AT" />
-</pre>
 <div class="toccolours mw-collapsible mw-collapsed" overflow:auto;">
@@ Zeile 181: / Zeile 181: @@
 Nutzen Sie die bereitgestellten Links im Dokument (z.B. im Inhaltsverzeichnis), um direkt in der PDF-Version dieses Dokuments zu navigieren. Folgende Tastenkombinationen können Ihnen die Nutzung des Leitfadens erleichtern:
-*Rücksprung: Alt + Pfeil links und Retour: Alt + Pfeil rechts
+*Rücksprung: Alt + Pfeil links und Vorwärts: Alt + Pfeil rechts
 *Seitenweise blättern: "Bild" Tasten
 *Scrollen: Pfeil nach oben bzw. unten
-*Zoomen: Strg + Mouserad drehen
+*Zoomen: Strg + Mausrad drehen
 *Suchen im Dokument: Strg + F
 </div></div>
@@ Zeile 192: / Zeile 192: @@
 =Leitfadenerstellungs- und Harmonisierungsprozess=
 Für die Ausgestaltung der Inhalte von "CDA Implementierungsleitfäden" ist eine breite Beteiligung der Stakeholder wesentlich, um die praktische Nutzbarkeit und die Akzeptanz durch die ELGA-Benutzer sicherzustellen.
-Für diese interdisziplinären Expertengruppen stehen nicht die technischen, sondern vor allem medizinisch-inhaltliche Aspekte im Vordergrund. Die technischen Inhalte werden großteils von den Redaktionsteams beigetragen.
+Für diese interdisziplinären Expertengruppen stehen nicht die technischen, sondern vor allem medizinisch-inhaltliche Aspekte im Vordergrund. Die technischen Inhalte werden Großteils von den Redaktionsteams beigetragen.
-Ein wesentlicher Schritt auf dem Weg zur Interoperabilität der IT-Systeme im Gesundheitswesen ist die Einigung auf Vorgaben für einheitliche Dokumentation und Codierung der Information. Diese durch die Arbeitsgruppen erreichte "Harmonisierung" etabliert neue nationale Qualitätsstandards der medizinischen Dokumentation.
+Ein wesentlicher Schritt auf dem Weg zur Interoperabilität der IT-Systeme im Gesundheitswesen ist die Einigung auf Vorgaben für eine einheitliche Dokumentation und Codierung der Informationen. Diese durch die Arbeitsgruppen erreichte "Harmonisierung" etabliert neue nationale Qualitätsstandards der medizinischen Dokumentation.
 Die Leitfäden werden über ein reguläres Standardisierungsverfahren ("Ballot") durch die HL7 Anwendergruppe Österreich (HL7 Austria) zu einem nationalen HL7 Standard.
 {{BeginILFBox}}
@@ Zeile 209: / Zeile 209: @@
 Neue und geänderte Anforderungen sowie Verbesserungen können neue Versionen der bestehenden Spezifikationen notwendig machen.
-Der CDA-Koordinator evaluiert in regelmäßigen Abständen, ob und welche Änderungen (etwa durch neue medizinische oder gesetzliche Anforderungen) notwendig sind. Aufgrund des Berichtes des CDA-Koordinators empfiehlt die ELGA GmbH die Erstellung von Revisionsversionen der bestehenden Leitfäden. Die geplanten Änderungen sollen mit den maßgeblichen Stakeholdern abgestimmt werden.
+Der CDA-Koordinator evaluiert in regelmäßigen Abständen, ob, und welche Änderungen (etwa durch neue medizinische oder gesetzliche Anforderungen) notwendig sind. Aufgrund des Berichts des CDA-Koordinators empfiehlt die ELGA GmbH die Erstellung von Revisionsversionen der bestehenden Leitfäden. Die geplanten Änderungen sollen mit den maßgeblichen Stakeholdern abgestimmt werden.
-Neue Versionen, die "verpflichtende Elemente" (Sections oder Entries) neu einführen oder entfernen, sind "Hauptversionen", die jedenfalls über eine Durchführungsverordnung verbindlich gemacht und veröffentlicht werden. Andere Versionen sind "Nebenversionen". Alle verbindlichen Versionen sind  auf http://www.gesundheit.gv.at zu veröffentlichen.
+Neue Versionen, die "verpflichtende Elemente" (Sections oder Entries) neu einführen oder entfernen, sind "Hauptversionen", die jedenfalls über eine Durchführungsverordnung verbindlich gemacht und veröffentlicht werden. Andere Versionen sind "Nebenversionen". Alle verbindlichen Versionen sind auf [[https://www.gesundheit.gv.at|www.gesundheit.gv.at]] zu veröffentlichen.
 == Autoren und Mitwirkende ==
 Der vorliegende Leitfaden wurde unter der Leitung der ELGA GmbH von den Autoren und unter Mitwirkung der genannten Personen (Mitglieder der Arbeitsgruppe) erstellt. Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht.
 Die HL7 Austria und die ELGA GmbH genehmigen ausdrücklich die Anwendung des Leitfadens ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente und weisen darauf hin, dass dies mit dem Einverständnis aller Mitwirkenden erfolgt.
-===Version 1&2===
-====Autoren====
-'''Das Redaktionsteam''' für die Hauptversion v1&2 bestand aus folgenden Personen<sup>1</sup>:
-{| class="wikitable"
-! Name
-! Organisation
-! Rolle
-|-
-| Stefan Sabutsch
-| ELGA GmbH, HL7 Austria
-| Herausgeber, Projektleiter, CDA Koordinator
-|-
-| Jürgen Brandstätter
-| CodeWerk Software Services and Development GmbH
-| Autor, Fachkoordinator
-|}
-====Mitwirkende====
-'''Teilnehmer der Arbeitsgruppe e-Medikation v1&2 2015'''<sup>1</sup>:
-Michael Bauer (SVC - Sozialversicherungs-Chipkarten Betriebs- und Errichtungsgesellschaft m.b.H.),
-Michael Deimel (SVC),
-Tanja Krammer (SVC),
-Martin Asenbaum (SVC),
-Alexander Kollmann (ELGA GmbH),
-Oliver Kuttin (ELGA GmbH),
-Carina Seerainer (ELGA GmbH)
 ===Version 3 (aktuell)===
@@ Zeile 297: / Zeile 270: @@
 <sup>1</sup> Personen sind ohne Titel angegeben
+===Version 1&2===
+====Autoren====
+'''Das Redaktionsteam''' für die Hauptversion v1&2 bestand aus folgenden Personen<sup>1</sup>:
+{| class="wikitable"
+! Name
+! Organisation
+! Rolle
+|-
+| Stefan Sabutsch
+| ELGA GmbH, HL7 Austria
+| Herausgeber, Projektleiter, CDA Koordinator
+|-
+| Jürgen Brandstätter
+| CodeWerk Software Services and Development GmbH
+| Autor, Fachkoordinator
+|}
+====Mitwirkende====
+'''Teilnehmer der Arbeitsgruppe e-Medikation v1&2 2015'''<sup>1</sup>:
+Michael Bauer (SVC - Sozialversicherungs-Chipkarten Betriebs- und Errichtungsgesellschaft m.b.H.),
+Michael Deimel (SVC),
+Tanja Krammer (SVC),
+Martin Asenbaum (SVC),
+Alexander Kollmann (ELGA GmbH),
+Oliver Kuttin (ELGA GmbH),
+Carina Seerainer (ELGA GmbH)
 =Technischer Hintergrund=
@@ Zeile 308: / Zeile 308: @@
 ==Voraussetzungen für den Zugriff auf e-Medikation in ELGA==
-Der ELGA GDA ist in ELGA angemeldet, berechtigt und besitzt eine gültige Kontaktbestätigung für den Patienten.
+Der ELGA-GDA muss in ELGA angemeldet und berechtigt sein sowie eine gültige Kontaktbestätigung für den Patienten besitzen. Zudem muss der Patient ELGA-Teilnehmer sein und darf keinen generellen, partiellen oder situativen Widerspruch gegen ELGA oder die e-Medikation eingelegt haben.
-Der Patient ist ELGA-Teilnehmer und hat keinen generellen, partiellen oder situativen Widerspruch hinsichtlich ELGA oder der e-Medikation eingelegt.
 ==Anwendungsfälle des Dokumentenmanagements==
-Die folgenden Kapiteln aus dem allgemeinen Leitfaden stellen eine Zusammenfassung der Inhalte der ELGA-Gesamtarchitektur, des Leitfadens XDS Metadaten und Usability Styleguides zum Thema e-Befunde dar. Detailinformationen sind in den entsprechenden Dokumenten nachzulesen (verfügbar auf der Homepage der [[https://www.elga.gv.at/|ELGA GmbH]]). Die wesentlichen Anwendungsfälle sind
+Die folgenden Kapitel aus dem allgemeinen Leitfaden stellen eine Zusammenfassung der Inhalte der ELGA-Gesamtarchitektur, des Leitfadens XDS Metadaten und Usability Styleguides zum Thema e-Befunde dar. Detailinformationen sind in den entsprechenden Dokumenten nachzulesen (verfügbar auf der Homepage der [[https://www.elga.gv.at/|ELGA GmbH]]). Die wesentlichen Anwendungsfälle sind
 *[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schreiben_und_Einbringen_von_Dokumenten|Schreiben und Einbringen von Dokumenten]]
 *[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Versionierung_von_Dokumenten|Versionierung von Dokumenten]]
@@ Zeile 320: / Zeile 319: @@
 ==Anwendungsfälle zur Nutzung der e-Medikation==
-Die Einsatzszenarien für dieses Datenaustauschformat werden in Form von Anwendungsfälle beschrieben, um dem Leser den Hintergrund zu vermitteln. Diese Anwendungsfälle gibt zusätzlichen Einblick zur aktuelle Umsetzung der ELGA-Anwendung e-Medikation.
+Die Einsatzszenarien für dieses Datenaustauschformat werden in Form von Anwendungsfällen beschrieben, um dem Leser den Hintergrund zu vermitteln. Diese Anwendungsfälle bieten zusätzlichen Einblick in die aktuelle Umsetzung der ELGA-Anwendung e-Medikation sowie dem Zusammenspiel der CDA-Dokumente.
-Zum besseren Verständnis des Implementierungsleitfaden e-Medikation sowie dem Zusammenspiel der CDA-Dokumente werden im Folgenden die Anwendungsfälle für die e-Medikation kurz dargestellt.
 Folgende '''Akteure''' werden in der ELGA-Anwendung e-Medikation (eMEDAT) definiert:
 * Akteure im niedergelassenen Bereich
 ** Arzt
-*** Kassenarzt
+*** Allgemeinmediziner mit und ohne Kassenvertrag
-*** Wahlarzt
+*** Facharzt mit und ohne Kassenvertrag
-*** Facharzt
+*** Hausapotheker (Da im GDA-Index jeder GDA nur eine Rolle besitzt und es die Rolle „Hausapotheker“ nicht gibt, haben Hausapotheker dieselbe Rolle wie niedergelassene Ärzte ohne Hausapotheke. Somit hat jeder Arzt auch die Funktionalitäten zur Abgabe zur Verfügung.)
-*** Hausapotheker (Da im GDA-Index jeder GDA nur eine Rolle besitzt und es eine Rolle „Hausapotheker“ nicht gibt, haben Hausapotheker dieselbe Rolle wie niedergelassene Ärzte ohne Hausapotheke. Somit hat jeder Arzt auch die Funktionalitäten zur Abgabe zur Verfügung.)
 *** etc.
 **	Arztpraxisassistent
 *	Krankenanstalt
-**	In der e-Medikation erfolgt keine Unterscheidung in stationären und ambulanten Bereich.
+**	In der e-Medikation erfolgt keine Unterscheidung zwischen stationären und ambulanten Bereich.
 *	Akteure in der Apotheke
 **	Pharmazeut
-**	Pharmazeutisch-kaufmännisch(er/e) Assistent
+**	Pharmazeutisch-kaufmännischer Assistent
+** Pharmazeutisch-technischer Assistent
 *	Einrichtung der Pflege
-**	Die Umsetzung der Berechtigungen (z.B. darf nur ein Arzt eine Verordnung in e-Medikation speichern), obliegt der GDA-Software.
+** Die GDA-Software muss eine klare Identifikation des ärztlichen Personals ermöglichen, so das nur diese eine Verordnung durchführen können! Wenn die Pflegesoftware keine Möglichkeit dazu hat, dann können auch keine Verordnungen ausgestellt werden.
-**	Pflegeperson (siehe Vertreter, Vollmachtnehmer)
 *	ELGA-Teilnehmer
+** Patient
 **	Vertreter
 *** ELGA-Ombudsstelle
 *** Vollmachtnehmer
-*** gesetzlicher Vertreter
+*** Gesetzlicher Vertreter
 *** etc.
-Der gegenständliche Implementierungsleitfaden „e-Medikation“ definiert die folgenden '''CDA-Dokumente''': Rezept, Abgabe, Korrekturmeldung (Pharmazeutische Empfehlung) und Medikationsliste. Um den Medikationsprozess und die folgend beschriebenen Anwendungsfälle abbilden zu können, werden diese Dokumente mit den folgenden Status in der e-Medikation abgebildet:
+Der gegenständliche Implementierungsleitfaden „e-Medikation“ definiert die folgenden '''CDA-Dokumente''': Rezept, Abgabe, Korrekturmeldung (Pharmazeutische Empfehlung) und Medikationsliste. Eine Korrekturmeldung jeglicher Rezepte oder Abgaben erfolgt immer mit der Pharmazeutischen Empfehlung. Um den Medikationsprozess und die folgend beschriebenen Anwendungsfälle abbilden zu können, werden diese Dokumente mit den folgenden Status in der e-Medikation abgebildet:
 *	Rezept (PRESCRIPTION; Ein Rezept wird durch ein Prescription Dokument abgebildet und kann eine oder mehrere Verordnungen enthalten. Bezüglich der möglichen Statuswerte unterscheiden sich das Prescription Dokument und die einzelnen Verordnungen.)
 ** OFFEN
@@ Zeile 372: / Zeile 369: @@
 ===Verordnung(en) mit Rezept anlegen===
-Im Zuge der Behandlung stellt der Arzt fest, dass dem ELGA Teilnehmer ein oder mehrere Arzneimittel verordnet werden müssen. Eine Verordnung besteht immer nur aus genau einer Medikation (= ein Arzneimittel). Das Rezept kann aus mehreren Verordnungen bestehen und bildet somit die Klammer über die Verordnungen. Das Rezept mit den Verordnungen wird mit einer eindeutigen eMED-ID versehen. Eine Speicherung von Verordnungen ohne Zuordnung eines Rezeptes ist nicht gültig.
+Im Zuge der Behandlung stellt der Arzt fest, dass dem ELGA-Teilnehmer ein oder mehrere Arzneimittel verordnet werden müssen. Eine Verordnung besteht immer nur aus genau einer Medikation (= ein Arzneimittel). Das Rezept kann aus mehreren Verordnungen bestehen und bildet somit die Klammer über die Verordnungen. Das Rezept mit den Verordnungen wird mit einer eindeutigen eMED-ID versehen. Eine Speicherung von Verordnungen ohne Zuordnung eines Rezeptes ist nicht gültig.
-Die Prüfungen der Arzneimittel z.B. auf potentielle Wechselwirkungen, Kontraindikationen, Dosierungen, etc. wie auch Bewilligungen von Arzneimitteln erfolgen in der Eigenverantwortung des Arztes und sind nicht Gegenstand der e-Medikation. Die Verordnung wird als geprüft und ggf. bewilligt angesehen, wenn die zugeordnete Verordnung in der e-Medikation gespeichert ist. Die Verordnung ist gültig, sobald sie in der e-Medikation gespeichert ist, somit ist eine Verordnung in der Zukunft nicht möglicht!
+Die Prüfungen der Arzneimittel z.B. auf potenzielle Wechselwirkungen, Kontraindikationen, Dosierungen, etc. wie auch Bewilligungen von Arzneimitteln erfolgen in der Eigenverantwortung des Arztes und sind nicht Gegenstand der e-Medikation. Die Verordnung wird als geprüft und ggf. bewilligt angesehen, wenn das zugeordnete Rezept in der e-Medikation gespeichert ist. Jede Verordnung ist gültig, sobald sie in der e-Medikation gespeichert ist, somit ist eine Verordnung in der Zukunft nicht möglich! Außnahmen gelten nur für das Substitutionsrezept.
 ====Vorbedingung====
-*	ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/ Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
+*	ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
 *	e-Medikation Vorbedingung: keine
@@ Zeile 388: / Zeile 385: @@
 ====Ablauf====
-Die Erfassung eines Rezepts mit Verordnung stellt folgende Prozessschritte in der GDA- Software dar:
+Die Erfassung eines Rezepts mit Verordnung stellt folgende Prozessschritte in der GDA-Software dar:
-*	Arzneimittel auswählen: Der Arzt wählt eine oder mehrere Arzneimittelspezialitäten aus einem Katalog („ASP-Liste“, die Liste der humanen Arzneispezialitäten gelistet nach PZN) aus, wobei Handelsname, Pharmazentralnummer (PZN) sowie andere Daten zur Beschreibung des Arzneimittels (Stärke, Darreichungsform, Packungsgröße, Zulassungsnummer etc.) automatisch aus einem Katalog mit allen ELGA-relevanten Arzneimittelspezialitäten übernommen werden können.
+*	Arzneimittel auswählen: Der Arzt wählt eine oder mehrere Arzneimittelspezialitäten aus einem Katalog („ASP-Liste“, die Liste der humanen Arzneispezialitäten gelistet nach PZN) aus, wobei Handelsname, Pharmazentralnummer (PZN) sowie andere Daten zur Beschreibung des Arzneimittels (Stärke, Darreichungsform, Packungsgröße, Zulassungsnummer etc.) automatisch aus einem Katalog mit allen ELGA-relevanten Arzneimittelspezialitäten übernommen werden können. Alternativ zu einer Arzeimittelspezialität kann auch eine magsitrale Zubereitung gespeichert werden. In diesem Fall ist zwingend mindestens ein Wirkstoff codiert anzugeben.
 *	eMED-ID anfordern: Die Vergabe der eindeutigen eMED-ID erfolgt zentral durch die Serverkomponente e-Medikation und kann über eine entsprechende Schnittstelle angefordert werden.
 *	Arzneimittel ausnehmen: Arzneimittel können von der Speicherung in e-Medikation ausgenommen werden (funktionale Anforderung an die GDA-Software)
@@ Zeile 402: / Zeile 399: @@
 Das Rezept wird durch eine Rezeptart gekennzeichnet, um die Gültigkeitsdauer prüfen zu können. In e-Medikation werden folgende Rezeptarten berücksichtigt:
-*	Kassenrezept – 1 Monat gültig und entspricht dem Zeitraum vom Ausstellungszeitpunkt bis zum gleichen Tag im Folgemonat 23:59 Uhr; eine Einlösung möglich; im Zuge des „Besorgerprozesses“ wird bei einer gespeicherten Teilabgabe die gesamte Gültigkeitsdauer auf 3 Monate verlängert; Es ist nicht möglich, zusätzliche Einlösungen anzugeben.
+* Kassenrezept – Gültig für einen Monat vom Ausstellungszeitpunkt bis zum gleichen Tag des Folgemonats 23:59 Uhr; eine Einlösung möglich; im Zuge des Prozesses „Besorger“ (siehe unten) wird bei einer gespeicherten Teilabgabe die gesamte Gültigkeitsdauer auf 3 Monate verlängert; es ist nicht möglich, zusätzliche Einlösungen anzugeben.
-** Beispiel: Wenn ein Kassenrezept am 1.4., 16:45 Uhr ausgestellt wird, dann ist es bis 2.5., 00:01 Uhr gültig. Möglicherweise führt das erwähnte „add_month“ dazu, dass die die Gültigkeit in dem Fall auf die Uhrzeit genau, also auf 2.5., 16:45 Uhr gesetzt wird, was dann zu dem Fehler führt.
+** Beispiel: Wenn ein Kassenrezept am 1.4., 16:45 Uhr ausgestellt wird, dann ist es bis 1.5., 23:59 Uhr gültig.
 * Privatrezept - 12 Monate gültig, sofern die erste Einlösung innerhalb von 1 Monat ab Erstelldatum erfolgt ist
-** Die maximale Gültigkeitsdauer beträgt 365 Tage bzw. sind bis zu 6 Einlösungen möglich, wobei Gültigkeitsdauer und Anzahl der möglichen Einlösungen vom Arzt definiert werden können. Dabei muss das Privatrezept innerhalb des ersten Monats erstmalig eingelöst werden (§ 4 Abs. 1 RezeptpflichtG).
+** Die maximale Gültigkeitsdauer beträgt 365 Tage bzw. sind bis zu 6 Einlösungen möglich, wobei Gültigkeitsdauer und Anzahl der möglichen Einlösungen vom Arzt definiert werden können. (§ 4 Abs. 1 RezeptpflichtG).
-* Substitutionsrezept – Maximale Gültigkeitsdauer von 12 Monaten. Das "GültigVon" Datum darf maximal einen Monat in der Zukunft liegen.
+* Substitutionsrezept – Maximale Gültigkeitsdauer von 12 Monaten. Das "GültigVon" Datum darf maximal einen Monat in der Zukunft liegen. Es ist nicht möglich, zusätzliche Einlösungen anzugeben.
-Es ist nicht möglich, zusätzliche Einlösungen anzugeben.
 Die Gültigkeitsdauer je Rezeptart folgt den rechtlichen Vorgaben. Es wird daher der Ausstellungstag in die Berechnung der Einlösefrist nicht mit eingerechnet. Die Gültigkeiten von Rezepten und somit die Verfügbarkeit in e-Medikation ergeben sich folgendermaßen:
-* Wenn ein Rezept mit den Verordnungen in e-Medikation gespeichert ist, dann erhält das Rezept/Verordnung den Status OFFEN.
+* Wenn ein Rezept mit den Verordnungen in e-Medikation gespeichert ist, dann erhält das Rezept und seine Verordnungen den Status OFFEN.
 * Ein Kassenrezept muss innerhalb von 1 Monat eingelöst werden, sonst erhält das Rezept den Status ABGELAUFEN.
 * Ein Privatrezept muss innerhalb von 1 Monat eingelöst werden, sonst erhält es den Status ABGELAUFEN.
 * Ein Substitutionsrezept ist im Status ABGELAUFEN, wenn das „bis Datum“ erreicht ist.
-* Die Anzahl der Einlösungen bei Privatrezepten werden auf Verordnungsebene geprüft. Sobald die maximale Anzahl der Einlösungen für jede einzelne Verordnung erreicht ist, erhält das Rezept den Status=EINGELÖST. Solange die Anzahl der Einlösungen (Abgaben) nicht erreicht wurde, hat die Verordnung und das Rezept den Status=OFFEN.
+* Die Anzahl der Einlösungen bei Privatrezepten werden auf Verordnungsebene geprüft. Sobald die maximale Anzahl der Einlösungen für jede einzelne Verordnung erreicht ist, erhält das Rezept den Status EINGELÖST. Solange die Anzahl der Einlösungen (Abgaben) nicht erreicht wurde, hat die Verordnung und das Rezept den Status OFFEN.
-* Die Rezeptart beeinflusst die Regeln, die bei der Einlösung der Verordnung zur Anwendung kommen. ist für die Regeln der Einlösung notwendig. Siehe dazu Use Cases „Abgabe mittels eMED-ID durchführen“ und „Abgabe über e-card durchführen“.
+* Die Rezeptart beeinflusst die Regeln, die bei der Einlösung der Verordnung zur Anwendung kommen. Siehe dazu Use Cases „Abgabe mittels eMED-ID durchführen“ und „Abgabe über e-card durchführen“.
 Es können nur Arzneimittel verordnet werden, die in der Liste der Arzneimittelspezialitäten
 („ASP-Liste“) vorkommen und als gültig vermerkt sind (ELGA_Gültigkeit = true). Ohne
 Verordnungsbezug kann nur die Abgabe jener OTC-Präparate in der e-Medikation gespeichert werden, die auch wechselwirkungsrelevant (ELGA_MedikationWechselwirkungsRelevant = true) sind.
-* Bei Kassen- und Substitutionsrezepten müssen alle Verordnungen mit einer Abgabe oder Leerabgabe referenziert werden.
+* Bei Kassen- und Substitutionsrezepten müssen alle Verordnungen mit einer Abgabe oder Leerabgabe (Abgabe von 0 Packungen) referenziert werden.
 =====Ergebnis im Gutfall=====
-Die am Rezept angegebenen Verordnungen sind im Status OFFEN in e-Medikation gespeichert. Die zuvor vom Server erstellte eMED-ID wurde für die Dokumentenerstellung verwendet und dem e-Rezept Service als Parameter übergeben.
+Die im Rezept angegebenen Verordnungen sind im Status OFFEN in e-Medikation gespeichert. Die zuvor vom Server erstellte eMED-ID wurde für die Dokumentenerstellung verwendet und dem e-Rezept Service als Parameter übergeben.
 =====Ergebnis im Fehlerfall=====
-Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
+Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
 Es können die folgenden Fehlerfälle aus der Schnittstelle zur e-Medikation heraus auftreten:
 * Speichern der Verordnung in e-Medikation nicht möglich
 * eMED-ID nicht ermittelbar
-Hinweis: Die Ausstellung eines e-Rezepts bzw. eines Papierrezepts darf durch eine etwaiges „Nicht-funktionieren“ der e-Medikation nicht verhindert werden.
+Hinweis: Die Ausstellung eines e-Rezepts bzw. eines Papierrezepts darf durch ein etwaiges „Nicht-funktionieren“ der e-Medikation nicht verhindert werden.
 ===Rezept mit Verordnung(en) abrufen===
-Im Zuge der Abgabe eines Arzneimittels in einer Apotheke (nach Identifikation mittels e-card) kann der Akteur die Rezepte samt Verordnungen zu einem ELGA Teilnehmer abrufen. Alternativ zur Identifikation mit e-card kann mittels eMED-ID ein Rezept abgerufen werden
+Im Zuge der Abgabe eines Arzneimittels in zum Beispiel einer Apotheke kann der Akteur die Rezepte samt Verordnungen zu einem ELGA-Teilnehmer abrufen. Alternativ zu einer gültigen Kontaktbestätigung kann das Rezept mittels eMED-ID abgerufen werden.
 ====Vorbedingung====
-*	ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/ Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
+* ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt (z.B. durch Identifikation mittels e-card).
-*	e-Medikation Vorbedingung: Verordnungen vorhanden
+* e-Medikation Vorbedingung: Verordnungen vorhanden
 ====Akteure====
-*	Arzt im niedergelassenen Bereich
+* Arzt im niedergelassenen Bereich
-*	Krankenanstalt
+* Krankenanstalt
-*	Apotheke
+* Apotheke
-*	Einrichtung der Pflege
+* Einrichtung der Pflege
 ====Ablauf====
-Der Akteur kann die Verordnungen des ELGA-Teilnehmers  abfragen. Es stehen grundsätzlich zwei Suchvarianten zur Verfügung
+Der Akteur kann die Verordnungen des ELGA-Teilnehmers abfragen. Es stehen grundsätzlich zwei Suchvarianten zur Verfügung:
-*	Alle Verordnungen von noch nicht eingelösten und noch nicht abgelaufenen Rezepten (findPrescriptionsForDispense)
+* Alle Verordnungen von noch nicht eingelösten und noch nicht abgelaufenen Rezepten (findPrescriptionsForDispense)
-*	Alle Verordnungen in einem bestimmten Zeitraum (findPrescriptions)
+* Alle Verordnungen in einem bestimmten Zeitraum (findPrescriptions)
 Für diese beiden Abfragen gibt es zwei mögliche „Startpunkte“:
-*	Startpunkt 1: Suche mit eMED-ID Assertion
+* Startpunkt 1: Suche mit eMED-ID Assertion
-** Suche ohne einem Patientenkontakt im ELGA BeS, auf Basis der eMED-ID Assertion, welche aufgrund der Angabe einer eMED-ID ausgestellt wurde. Mit dieser Assertion können ausschließlich Dokumente gefunden werden, die mit der betreffenden eMED-ID zusammenhängen (Rezept und zugehörige Abgaben, bzw. Pharmaceutical Advices).
+** Suche ohne einem Patientenkontakt im ELGA-Berechtigungssystem, auf Basis der eMED-ID Assertion, welche aufgrund der Angabe einer eMED-ID ausgestellt wurde. Mit dieser Assertion können ausschließlich Dokumente gefunden werden, die mit der betreffenden eMED-ID zusammenhängen (Rezept und zugehörige Abgaben, bzw. Pharmaceutical Advices).
-*	Startpunkt 2: Suche mit Patientenkontakt
+* Startpunkt 2: Suche mit Patientenkontakt
-** Bei der Suche nach Rezepten mit einem Patientenkontakt im ELGA BeS (z.B. auf Basis der gesteckten e-card), können alle Rezepte des ELGA-Teilnehmers gesucht werden.
+** Bei der Suche nach Rezepten mit einem Patientenkontakt im ELGA-Berechtigungssystem (z.B. auf Basis einer vorhandenen und gültigen Kontaktbestätigung), können alle Rezepte des ELGA-Teilnehmers gesucht werden.
 Es gibt keine Einschränkung bei der Anzeige der Datenfelder (z.B. ausstellender GDA darf angezeigt werden). Es werden über die Schnittstelle alle verfügbaren Datenfelder zu einer Verordnung/Rezept geliefert (lt. Datenmodell).
 =====Ergebnis im Gutfall=====
-Im Gutfall werden dem Akteur die angeforderten Rezepte/ Verordnungen sowie die dazugehörigen Korrekturmeldungen („Pharmazeutischen Empfehlungen“) zurückgeliefert und stehen zur weiteren Verwendung zur Verfügung.
+Im Gutfall werden dem Akteur die angeforderten Rezepte/Verordnungen sowie die dazugehörigen Korrekturmeldungen (Pharmazeutischen Empfehlungen) zurückgeliefert und stehen zur weiteren Verwendung zur Verfügung.
 =====Ergebnis im Fehlerfall=====
 Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden.
-Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
+Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
 ===Verordnung stornieren===
@@ Zeile 476: / Zeile 472: @@
 ====Vorbedingung====
-* ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/ Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
+* ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
-* e-Medikation Vorbedingung: Verordnung mit dem Status=OFFEN ist vorhanden
+* e-Medikation Vorbedingung: Verordnung mit dem Status OFFEN ist vorhanden
 ====Akteure====
@@ Zeile 489: / Zeile 485: @@
 *	Ganzes Rezept stornieren:
 ** Ein Rezept gilt als storniert, wenn einer der folgenden beiden Methoden angewandt wird:
-***	Der Akteur bestimmt alle Verordnung des Rezepts und storniert jede einzelne Verordnung des Rezepts. Das Rezept erhält den Status = STORNIERT, wenn alle zugeordneten Verordnungen den Status = STORNIERT aufweisen.
+***	Der Akteur bestimmt alle Verordnung des Rezepts und storniert jede einzelne Verordnung des Rezepts. Das Rezept erhält den Status STORNIERT, wenn alle zugeordneten Verordnungen den Status STORNIERT aufweisen.
 ***	Der Akteur bestimmt das Rezept mit den Verordnungen (über eMED-ID). Es wird ein Update der Metadaten des Rezepts ausgeführt. Dies kann nur vom Ersteller des Rezepts durchgeführt werden.
 =====Ergebnis im Gutfall=====
-Die Verordnung bzw. das Rezept erhalten den Status= STORNIERT.
+Die Verordnung bzw. das Rezept erhalten den Status STORNIERT.
 =====Ergebnis im Fehlerfall=====
@@ Zeile 503: / Zeile 499: @@
 ====Vorbedingung====
-*	ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
+*	ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
-*	e-Medikation Vorbedingung: Verordnung mit dem Status=OFFEN ist vorhanden.
+*	e-Medikation Vorbedingung: Verordnung mit dem Status OFFEN ist vorhanden.
 ====Akteure====
@@ Zeile 513: / Zeile 509: @@
 ====Ablauf====
-Eine Verordnung kann mittels einer Korrekturmeldung (=Pharmazeutischen Empfehlung) geändert werden. Der Arzt kann nur die folgenden Datenfelder einer Verordnung ändern, nicht aber das verordnete Arzneimittel oder die Menge selbst:
+Eine Verordnung kann mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) geändert werden. Der Arzt kann nur die folgenden Datenfelder einer Verordnung ändern, jedoch nicht das verordnete Arzneimittel oder die Menge selbst:
 *	Art der Anwendung
 *	Zusatzinformation
@@ Zeile 526: / Zeile 522: @@
 *	Therapieart
 *	Tagesangabe
+*  Einnahmestart/-ende/-dauer
+*  Indikation
+*  Verifizierungsdatum
-Verordnungen mit dem Status ABGELAUFEN, NICHT DISPENSIERT, EINGELÖST, STORNIERT können nicht geändert werden. Die Medikation (z.B. Handelsname) einer Verordnung kann NICHT geändert werden.
+Verordnungen mit dem Status ABGELAUFEN, NICHT DISPENSIERT, EINGELÖST oder STORNIERT können nicht geändert werden. Die Medikation (z.B. Handelsname) einer Verordnung kann NICHT geändert werden.
-Ist eine Änderung der Medikation notwendig, kann der Akteur eine neue Verordnung anlegen und eine Stornierung der zu ändernden Verordnung veranlassen (Rücksprache). Das gleiche gilt für die Angabe „Menge“, dazu muss der Arzt ein weiteres Rezept mit einer entsprechenden Verordnung ausstellen. Die Verringerung der Menge kann nicht abgebildet werden.
+Ist eine Änderung der Medikation notwendig, kann der Akteur eine neue Verordnung anlegen und eine Stornierung der zu ändernden Verordnung veranlassen (Rücksprache). Das Gleiche gilt für die Angabe „Menge“, dazu muss der Arzt ein weiteres Rezept mit einer entsprechenden Verordnung ausstellen. Die Verringerung der Menge kann nicht abgebildet werden.
 Die eMED-ID am Rezept muss bei einer Änderung der Verordnung gleich bleiben. Jede Änderung ist zu protokollieren; Es muss nachvollziehbar sein,
 *	wann die Änderung der Verordnung durchgeführt wurde.
@@ Zeile 540: / Zeile 539: @@
 =====Ergebnis im Fehlerfall=====
 Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Die in e-Medikation gespeicherte Verordnung wurde nicht verändert.
-Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
+Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
 ===Abgabe mit Verordnungsbezug durchführen===
@@ Zeile 549: / Zeile 548: @@
 ====Vorbedingung====
-*	ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
+*	ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
-*	e-Medikation Vorbedingung: Verordnung mit dem Status=OFFEN ist vorhanden
+*	e-Medikation Vorbedingung: Verordnung mit dem Status OFFEN ist vorhanden
 ====Akteure====
@@ Zeile 558: / Zeile 557: @@
 ====Ablauf====
 * Rezept mit Verordnungen abrufen
-** Üblicherweise wird in einem e-Rezept-Datensatz die korrespondierende eMED-ID gespeichert und liegt daher beim Abruf des e-Rezepts elektronisch als Zusatzinformation vor. Alternativ kann die eMED-ID durch Scan des Matrix-Codes auf dem e-Rezept-Ausdruck oder durch manuelle Eingabe erfolgen. In diesem Fall ist keine ELGA-Kontaktbestätigung erforderlich. Allerdings ist hierdurch ausschließlich der Zugriff auf die Daten des durch die eMED-ID referenzierten Rezepts möglich und nicht auf andere in der e-Medikation gespeicherte Daten (z.B. komplette e-Medikationsliste des Patienten).
+** Üblicherweise wird in einem e-Rezept-Datensatz die korrespondierende eMED-ID gespeichert und liegt daher beim Abruf des e-Rezepts elektronisch als Zusatzinformation vor. Alternativ kann die eMED-ID durch Scannen des Matrix-Codes auf dem e-Rezept-Ausdruck oder durch manuelle Eingabe erfolgen. In diesem Fall ist keine ELGA-Kontaktbestätigung erforderlich. Allerdings ist hierdurch ausschließlich der Zugriff auf die Daten des durch die eMED-ID referenzierten Rezepts möglich und nicht auf andere in der e-Medikation gespeicherte Daten (z.B. komplette e-Medikationsliste des Patienten).
-** Sämtliche zu einem ELGA-Teilnehmer in der e-Medikation gespeicherten Verordnungsdaten können auf Basis einer bestehenden ELGA-Kontaktbestätigung (z.B. ausgelöst durch Einlesen der e-card) abgerufen werden.
+** Sämtliche zu einem ELGA-Teilnehmer in der e-Medikation gespeicherten Verordnungsdaten können auf Basis einer bestehenden ELGA-Kontaktbestätigung abgerufen werden.
 * Abgabe in der e-Medikation speichern
 ** Die Daten aus der Verordnung sind in der Regel vollständig für die Abgabe zu übernehmen. In Sonderfällen (z.B. Austausch eines Medikaments nach Rücksprache mit dem Arzt) können die aus der Verordnung übernommenen Daten geändert werden.
-** Für den Fall, dass bereits erfolgte Abgaben nacherfasst werden sollen (z.B. technische Probleme zum Zeitpunkt der eigentlichen Abgabe), wird als Erfassungsdatum der Zeitpunkt der Nacherfassung gesetzt, während als Abgabedatum das in der Vergangenheit liegende Datum der tatsächlichen Abgabe eingetragen wird
+** Falls bereits erfolgte Abgaben nacherfasst werden sollen (z. B. aufgrund technischer Probleme zum Zeitpunkt der eigentlichen Abgabe), wird als Erfassungsdatum der Zeitpunkt der Nacherfassung gesetzt, während als Abgabedatum das tatsächliche Abgabedatum in der Vergangenheit gesetzt wird.
 In der Fachlogik gelten folgende Prüfregeln:
 *	Damit die Verordnung eingelöst werden kann, muss diese den Status OFFEN haben.
-*	Rezepte mit der Rezeptart=Privatrezepte können von mehreren Akteuren eingelöst werden, z.B. verschiedene Apotheken.
+*	Rezepte mit der Rezeptart Privatrezepte können von mehreren Akteuren eingelöst werden, z.B. verschiedene Apotheken.
-*	Rezepte mit der Rezeptart=Kassenrezept und Substitutionsrezept können nur von einem Akteur eingelöst werden. Somit müssen alle Verordnungen zu einem Rezept abgegeben werden. Verordnungen, die nicht abgegeben werden, erhalten den Status NICHT DISPENSIERT
+*	Rezepte mit der Rezeptart Kassenrezept und Substitutionsrezept können nur von einem Akteur eingelöst werden. Somit müssen alle Verordnungen zu einem Rezept abgegeben werden. Verordnungen, die nicht abgegeben werden, erhalten den Status NICHT DISPENSIERT.
-*	Zu Rezepten mit dem Status ABGELAUFEN können keine Abgaben mehr gespeichert werden. Die (nachträgliche) Speicherung von Abgaben zu einem abgelaufenen Rezept kann im Anlassfall allerdings ohne Verordnungsbezug erfolgen (siehe Kapitel xxx).
+*	Zu Rezepten mit dem Status ABGELAUFEN können keine Abgaben mehr gespeichert werden. Die (nachträgliche) Speicherung von Abgaben zu einem abgelaufenen Rezept kann im Anlassfall allerdings ohne Verordnungsbezug erfolgen (siehe Kapitel [[#Abgabe_ohne_Verordnungsbezug_durchf.C3.BChren|„Abgabe ohne Verordnungsbezug durchführen“]].
 =====Sonderfälle=====
 Austausch:
-Wird ein Arzneimittel verordnet, welches in der Apotheke nicht vorhanden ist, so kann im Rahmen der gesetzlichen Bestimmungen, der Apotheker bzw. der hausapotheken- führende Arzt ein wirkstoffgleiches Arzneimittel bzw. nach Rücksprache mit dem Arzt ein alternatives Arzneimittel abgeben.
+Wird ein Arzneimittel verordnet, das in der Apotheke nicht vorrätig ist, kann der Apotheker bzw. der hausapothekenführende Arzt im Rahmen der gesetzlichen Bestimmungen ein wirkstoffgleiches Arzneimittel bzw. nach Rücksprache mit dem Arzt ein alternatives Arzneimittel abgeben.
-Jedenfalls ist das tatsächlich abgegebene Arzneimittel in e-Medikation zu speichern und der Verordnung/dem Rezept zuzuordnen, um die Zugrundeliegende Verordnung einzulösen.
+Jedenfalls ist das tatsächlich abgegebene Arzneimittel in e-Medikation zu speichern und der Verordnung/dem Rezept zuzuordnen, um die zugrundeliegende Verordnung einzulösen.
 Besorger:
-Der Prozess des „Besorgers“ (ein Arzneimittel ist nicht lagernd und muss bestellt werden) wird in e-Medikation abgebildet. Das Rezept wird von der Apotheke eingelöst und die Abgabe wird als „Teilabgabe“ gekennzeichnet (siehe Markierung FFP „First Fill, Part Fill“ oder RFP „Refill - Part Fill“). Es wird die Verordnung nicht in den Status EINGELÖST versetzt und es können solange weitere Abgaben dispensiert werden, bis eine Abgabe mit der Markierung RFC „Refill - Complete“ gespeichert wird. Die Kennzeichnung zeigt, dass das Arzneimittel dem Patienten noch nicht ausgehändigt wurde. Die Kennzeichnung zeigt auch, ob alle Packungen einer Verordnung bzw. teilweise Packungen einer Verordnung bestellt werden. Solange eine Abgabe mit der Kennzeichnung „Besorger“ vorhanden ist, muss die Abgabe mit der eMED-ID abrufbar sein.
+Der Prozess des „Besorgers“ (wenn ein Arzneimittel nicht lagernd ist und bestellt werden muss) wird in der e-Medikation abgebildet. Dabei wird das Rezept von der Apotheke eingelöst, und die Abgabe wird als Teilabgabe gekennzeichnet (siehe Markierung FFP „First Fill, Part Fill“ oder RFP „Refill - Part Fill“). Die Verordnung wird nicht in den Status EINGELÖST versetzt und es können solange weitere Abgaben dispensiert werden, bis eine Abgabe mit der Markierung RFC „Refill - Complete“ gespeichert wird. Die Kennzeichnung zeigt, dass das Arzneimittel dem Patienten noch nicht ausgehändigt wurde. Die Kennzeichnung zeigt auch, ob alle Packungen einer Verordnung bzw. teilweise Packungen einer Verordnung bestellt werden. Solange eine Abgabe mit der Kennzeichnung „Besorger“ vorhanden ist, muss die Abgabe mit der eMED-ID abrufbar sein.
-Der Prozess einer „Teilabgabe“ eines Rezeptes kann mit obiger Logik des „Besorgers“ auch abgebildet werden.
 OTC:
 *	Erfolgt die Abgabe eines OTC auf Basis einer Verordnung, wird die Abgabe immer in e-Medikation gespeichert, auch wenn dieses OTC nicht in der ASP-Liste als wechselwirkungsrelevante Arzneispezialität geführt ist.
-*	Erfolgt die Abgabe eines OTC ohne Verordnungsbezug (siehe Kapitel „Abgabe ohne Verordnungsbezug durchführen“), darf die Abgabe nur in e-Medikation gespeichert werden, wenn dieses OTC in der ASP-Liste als wechselwirkungsrelevante Arzneispezialität geführt ist.
+*	Erfolgt die Abgabe eines OTC ohne Verordnungsbezug (siehe Kapitel [[#Abgabe_ohne_Verordnungsbezug_durchf.C3.BChren|„Abgabe ohne Verordnungsbezug durchführen“]]), darf die Abgabe nur in e-Medikation gespeichert werden, wenn dieses OTC in der ASP-Liste als wechselwirkungsrelevante Arzneispezialität geführt ist.
 =====Ergebnis im Gutfall=====
-Die Verordnung ist eingelöst und die Medikationsabgabe ist gespeichert. Die Verknüpfung von Verordnung und Abgabe ist vorhanden. Teilabgaben sind entsprechend markiert.
+Die Verordnung ist eingelöst und die Medikationsabgabe ist gespeichert. Die Verknüpfung von Verordnung und Abgabe ist vorhanden. Teilabgaben im „Besorger“-Prozess sind entsprechend gekennzeichnet.
 =====Ergebnis im Fehlerfall=====
@@ Zeile 593: / Zeile 591: @@
 ===Abgabe ohne Verordnungsbezug durchführen===
-Der Akteur speichert die Arzneimittel in e-Medikation, welche tatsächlich abgegeben werden. Dieser Prozess wird durchgeführt
+Der Akteur speichert die tatsächlich abgegeben Arzneimittel in e-Medikation. Dieser Prozess wird durchgeführt:
-*	bei Abgabe von nicht verordneten Arzneimitteln (Abgabe von wechselwirkungsrelevanten OTC )
+*	bei Abgabe von nicht verordneten Arzneimitteln (Abgabe von wechselwirkungsrelevanten OTC)
-* wenn ein e-Rezept-Eintrag oder ein Papierrezept vorhanden ist und keine Verordnungen in e-Medikation eingetragen wurden
+*  wenn ein e-Rezept-Eintrag oder ein Papierrezept vorhanden ist und keine Verordnungen in e-Medikation eingetragen wurden
-*	Abgabe eines Arztmusters
+*	bei der Abgabe eines Arztmusters
-*	Nacherfassung von bereits abgegebenen Arzneimitteln (z.B. wenn eine Speicherung zum Zeitpunkt der Abgabe aus technischen Gründen nicht möglich war, bei Arzneimittelbezug aus dem Ausland etc.)
+*	bei der Nacherfassung bereits abgegebener Arzneimittel (z. B. wenn eine Speicherung zum Zeitpunkt der Abgabe aus technischen Gründen nicht möglich war oder bei Arzneimittelbezug aus dem Ausland)
 ====Vorbedingung====
-*	ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
+*	ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
 *	e-Medikation Vorbedingung: keine
@@ Zeile 612: / Zeile 610: @@
 ====Ablauf====
-Der Akteur erfasst die Medikationsabgabe. Die Prüfungen der Arzneimittel z.B. auf potentielle Wechselwirkungen, Kontraindikationen, Dosierungen etc. erfolgt in der Eigenverantwortung des Akteurs und ist nicht Gegenstand des Informationssystems „e-Medikation“.
+Der Akteur erfasst die Medikationsabgabe. Die Prüfungen der Arzneimittel z.B. auf Wechselwirkungen, Kontraindikationen, Dosierungen erfolgt in der Eigenverantwortung des Akteurs und ist nicht Gegenstand des Informationssystems „e-Medikation“.
-Wenn eine Medikationsabgabe (ohne Rezept/Verordnung) in e-Medikation gespeichert wird, dann gilt die Medikationsabgabe als vom Akteur geprüft. Wenn ein e-Rezept-Eintrag oder ein Papierrezept ohne e-Medikations-Verordnung vorhanden ist, dann obliegt es dem abgebenden Akteur diese zu prüfen.
+Wenn eine Medikationsabgabe (ohne Rezept/Verordnung) in e-Medikation gespeichert wird, dann gilt die Medikationsabgabe als vom Akteur geprüft. Wenn ein e-Rezept-Eintrag oder ein Papierrezept ohne e-Medikations-Verordnung vorhanden ist, dann obliegt es dem abgebenden Akteur, diese zu prüfen.
-Im Rahmen der Nacherfassung von bereits erfolgten Abgaben wird als Erfassungsdatum der Zeitpunkt der Nacherfassung gesetzt, während als Abgabedatum das in der Vergangenheit liegende Datum der tatsächlichen Abgabe eingetragen wird.
+Im Rahmen der Nacherfassung bereits erfolgter Abgaben wird als Erfassungsdatum der Zeitpunkt der Nacherfassung gesetzt, während als Abgabedatum das tatsächliche Datum der Abgabe in der Vergangenheit eingetragen wird.
 =====Ergebnis im Gutfall=====
@@ Zeile 624: / Zeile 622: @@
 Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden.
-Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
+Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
 ===Abgabe abrufen===
-Im Zuge der Behandlung eines ELGA Teilnehmers kann der Akteur die Medikationsabgaben eines ELGA Teilnehmers abrufen.
+Im Zuge der Behandlung eines ELGA-Teilnehmers kann der Akteur die Medikationsabgaben eines ELGA-Teilnehmers abrufen.
 ====Vorbedingung====
-*	ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
+*	ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
 *	e-Medikation Vorbedingung: Abgaben in den letzten 18 Monaten vorhanden
@@ Zeile 644: / Zeile 642: @@
 *	eMED-ID
 *	Zeitraum
-Stornierte Abgaben können nicht abgerufen werden. Es gibt keine Einschränkung bei der Anzeige der Datenfelder (z.B. abgebender GDA darf angezeigt werden). Es werden alle Datenfelder zu einer Abgabe über die Schnittstelle zur Verfügung gestellt.
+Es gibt keine Einschränkung bei der Anzeige der Datenfelder (z.B. abgebender GDA darf angezeigt werden). Es werden alle Datenfelder zu einer Abgabe über die Schnittstelle zur Verfügung gestellt. Hinweis: Stornierte Abgaben können nicht abgerufen werden.
 =====Ergebnis im Gutfall=====
@@ Zeile 651: / Zeile 649: @@
 =====Ergebnis im Fehlerfall=====
 Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden.
-Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
+Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
 ===Abgabe stornieren===
@@ Zeile 658: / Zeile 656: @@
 ====Vorbedingung====
-*	ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
+*	ELGA-Vorbedingung: Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
-*	e-Medikation Vorbedingung: Abgabe vorhanden, Status= ABGEGEBEN
+*	e-Medikation Vorbedingung: Abgabe vorhanden, Status ABGEGEBEN
 ====Akteure====
@@ Zeile 668: / Zeile 666: @@
 ====Ablauf====
-Der Akteur wählt die Medikationsabgabe, welche storniert werden soll. Die Stornierung  von Abgaben ist jederzeit möglich. Die Abgabe erhält den Status=STORNIERT und kann nicht mehr abgerufen werden. Handelt es sich bei der Abgabe um eine Medikation mit Verordnungsbezug, dann wechselt der Status der Verordnung auf OFFEN oder – falls der Gültigkeitszeitraum des zugrunde liegenden Rezepts überschritten wurde – auf ABGELAUFEN
+Der Akteur wählt die Medikationsabgabe, die storniert werden soll. Die Stornierung  von Abgaben ist jederzeit möglich. Die Abgabe erhält den Status STORNIERT und kann nicht mehr abgerufen werden. Handelt es sich bei der Abgabe um eine Medikation mit Verordnungsbezug, bleibt die Verordnung OFFEN, wenn sie weiterhin gültig ist. Ist der Gültigkeitszeitraum des zugrunde liegenden Rezepts jedoch bereits überschritten, erhält sie den Status ABGELAUFEN.
 =====Ergebnis im Gutfall=====
-Im Gutfall wird die Stornierung der Medikationsabgabe durchgeführt. Die Abgabe erhält den Status STORNIERT, eine der Abgabe zugrunde liegende Verordnung den Status OFFEN oder ABGELAUFEN.
+Im Gutfall wird die Stornierung der Medikationsabgabe durchgeführt. Die Abgabe erhält den Status STORNIERT, und die zugrunde liegende Verordnung erhält den Status OFFEN oder ABGELAUFEN.
 =====Ergebnis im Fehlerfall=====
 Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden.
-Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
+Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
 ===Abgabe absetzen===
-Im Patientengespräch erfährt der Akteur, dass eine erfolgte Medikationsabgabe vom ELGA Teilnehmer nicht eingenommen wird. In diesem Fall wurde ein Arzneimittel zwar in der Apotheke abgegeben, es wird bzw. wurde aber nicht mehr (z.B. aufgrund von Unverträglichkeiten) eingenommen. Ein Absetzen einer Medikationsabgabe kann von jedem Akteur (außer ELGA-Teilnehmer selbst) durchgeführt werden.
+Im Patientengespräch erfährt der Akteur, dass eine erfolgte Medikationsabgabe vom ELGA-Teilnehmer nicht eingenommen wird. In diesem Fall wurde ein Arzneimittel zwar in der Apotheke abgegeben, es wird bzw. wurde aber nicht mehr (z.B. aufgrund von Unverträglichkeiten) eingenommen. Ein Absetzen einer Medikationsabgabe kann von jedem Akteur (außer ELGA-Teilnehmer selbst) durchgeführt werden.
 ====Vorbedingung====
-*	GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
+*	Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
-*	e-Medikation Vorbedingung: Abgabe vorhanden, Status= ABGEGEBEN
+*	e-Medikation Vorbedingung: Abgabe vorhanden, Status ABGEGEBEN
 ====Akteure====
@@ Zeile 696: / Zeile 694: @@
 ====Ablauf====
-Eine Abgabe kann mittels einer Korrekturmeldung (=Pharmazeutischen Empfehlung) abgesetzt werden. Der Akteur bestimmt die abzusetzende Medikationsabgabe durch Übergabe der AbgabeID.
+Eine Abgabe kann mittels einer Korrekturmeldung (Pharmazeutischen Empfehlung) abgesetzt werden. Der Akteur bestimmt die abzusetzende Medikationsabgabe durch Übergabe der AbgabeID.
 Der Akteur muss das Datum der Absetzung angeben.
@@ Zeile 705: / Zeile 703: @@
 =====Ergebnis im Gutfall=====
-Im Gutfall wird das Absetzen der Medikationsabgabe durchgeführt und in e-Medikation gespeichert (Status=ABGESETZT). Das Absetzdatum ist in den Abgabedatenfeldern vorhanden.
+Im Gutfall wird das Absetzen der Medikationsabgabe durchgeführt und in e-Medikation gespeichert (Status ABGESETZT). Das Absetzdatum ist in den Abgabedatenfeldern vorhanden.
 =====Ergebnis im Fehlerfall=====
 Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Status der Abgabe ist ABGEGEBEN.
-Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden.
+Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden.
 ===Abgabe ändern===
 Der Akteur muss die Daten einer Medikationsabgabe ändern können (z.B. bei Einstellungen der Dosierung eines Arzneimittels). Es dürfen nur definierte Datenfelder geändert werden.
 ====Vorbedingung====
-*	GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
+*	Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
-*	e-Medikation Vorbedingung: Abgabe vorhanden, Status=ABGEGEBEN
+*	e-Medikation Vorbedingung: Abgabe vorhanden, Status ABGEGEBEN
 ====Akteure====
@@ Zeile 723: / Zeile 720: @@
 *	Krankenanstalt
 *	Apotheke
-*   Einrichtungen der Pflege
+*  Einrichtung der Pflege
 ====Ablauf====
 Der Akteur bestimmt die zu ändernde Medikationsabgabe durch Übergabe der AbgabeID. Der Akteur kann nur bestimmte Datenfelder einer Medikationsabgabe ändern, nicht aber das Arzneimittel oder die Menge selbst. Folgende Datenfelder können verändert werden:
 *	Art der Anwendung
@@ Zeile 747: / Zeile 743: @@
 =====Ergebnis im Fehlerfall=====
-Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
+Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
 ===Medikationsliste abrufen===
-Im Zuge der Behandlung eines ELGA Teilnehmers möchte der Akteur die Medikationsliste des ELGA Teilnehmers abrufen. Die Medikationsliste fasst offene Verordnungen und Abgaben zusammen.
+Im Zuge der Behandlung eines ELGA-Teilnehmers möchte der Akteur die Medikationsliste des ELGA-Teilnehmers abrufen. Die Medikationsliste fasst offene Verordnungen und Abgaben zusammen.
 ====Vorbedingung====
-*	GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
+*	Der GDA ist autorisiert, der ELGA-Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung wurde vom ELGA-Berechtigungssystem ausgestellt.
 *	e-Medikation Vorbedingung: keine
@@ Zeile 772: / Zeile 768: @@
 =====Ergebnis im Fehlerfall=====
-Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
+Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übermittelt werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
 ====Alternativer Ablauf====
-Bei der Ermittlung der aktuellen Medikation eines Patienten ist die Verwendung der konsolidierten Medikationsliste optional. Alternativ können die verfügbaren (Quell)Daten Rezept (Prescription), Abgabe (Dispense) und die entsprechenden Korrekturmeldungen  bzw.  Pharmazeutische  Empfehlungen (Pharmaceutical  Advice) separat entsprechend dem im IHE Pharmacy Profil definierten Abfragen („Queries“) abgerufen und in der lokalen Software weiterverarbeitet werden.
+Bei der Ermittlung der aktuellen Medikation eines Patienten ist die Verwendung der konsolidierten Medikationsliste optional. Alternativ können die verfügbaren (Quell-)Daten Rezept (Prescription), Abgabe (Dispense) und die entsprechenden Korrekturmeldungen bzw. Pharmazeutische Empfehlungen (Pharmaceutical  Advice) separat entsprechend dem im IHE Pharmacy Profil definierten Abfragen („Queries“) abgerufen und in der lokalen Software weiterverarbeitet werden. Dies hat den Vorteil, dass die Änderungen der Medikationsliste nachvollziehbar sind.
-Dies hat den Vorteil, dass man auch die Historie der Änderungen sehen kann, welche in der Implementierung der Medikationsliste bereits eingearbeitet sind.
 =Konformitätsprüfung=
@@ Zeile 788: / Zeile 782: @@
 {{EndYellowBox}}
 {{BeginILFBox}}
-Die Kapitel zu den technischen Konformitätsprüfungen von CDA-Dokumenten, gemäß diesem Dokumentleitfadens mittels Schema und Schematron, sind im allgemeinen Leitfaden unter den folgenden Links zu finden:
+Die Kapitel zu den technischen Konformitätsprüfungen von CDA-Dokumenten, gemäß diesem Dokumentleitfaden mittels Schema und Schematron, sind im allgemeinen Leitfaden unter den folgenden Links zu finden:
 *[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schema-Pr.C3.BCfung|Schema-Prüfung]]
 *[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schematron-Pr.C3.BCfung|Schematron-Prüfung]]
@@ Zeile 936: / Zeile 930: @@
 |[[#Medikationsliste|Medikationsliste Dokument]]
 |- style="background:#FFFFFF"
-|&nbsp;&nbsp;Abgabe - kodiert
+|&nbsp;&nbsp;Medikationsliste - kodiert
 |1..1 M||[[#Medikationsliste_-_kodiert|Medikationsliste Sektion]]
 |- style="background:#FFFFFF"
@@ Zeile 969: / Zeile 963: @@
 {{BeginILFBox}}Die Header Level Templates wurden großteils aus dem bestehenden "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente" übernommen. Diese sind unter [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Dokumentenstruktur|Allgemeiner Leitfaden - Kapitel Administrative Daten (CDA Header) - Dokumentenstruktur]] zu finden.{{EndILFBox}}
-Die Header-Element welche spezifisch für die e-Medikation angepasst wurden sind folgende:
+Die Header-Element welche spezifisch für die e-Medikation v3 angepasst wurden sind folgende:
 ====Record Target v2====
 {{:1.2.40.0.34.6.0.11.1.3.2/dynamic}}
@@ Zeile 980: / Zeile 974: @@
 ====Legal Authenticator v2====
 {{:1.2.40.0.34.6.0.11.1.5.2/dynamic}}
+Die Header-Element welche in der e-Medikation direkt aus dem Allgemeinen Leitfaden verwendet worden sind, sind folgende:
+====Document Confidentiality Code====
+{{:1.2.40.0.34.6.0.11.1.12/dynamic}}
+====Document Effective Time====
+{{:1.2.40.0.34.6.0.11.1.11/dynamic}}
+====Document Id====
+{{:1.2.40.0.34.6.0.11.1.1/dynamic}}
+====Document Language====
+{{:1.2.40.0.34.6.0.11.1.13/dynamic}}
+====Document Realm====
+{{:1.2.40.0.34.6.0.11.1.10/dynamic}}
+====Document Replacement - Related Document====
+{{:1.2.40.0.34.6.0.11.1.14/dynamic}}
+====Document Set Id and Version Number====
+{{:1.2.40.0.34.6.0.11.1.15/dynamic}}
+====Document TerminologyDate====
+{{:1.2.40.0.34.6.0.11.1.46/dynamic}}
+====Document TypeId====
+{{:1.2.40.0.34.6.0.11.1.30/dynamic}}
 ===Section Level Templates===
@@ Zeile 1.000: / Zeile 1.014: @@
 ====Medikation Pharmazeutische Empfehlung Entry eMedikation v3====
 {{:1.2.40.0.34.6.0.11.3.188/dynamic}}
+===Weitere CDA Fragmente===
+{{BeginILFBox}} Die weiteren CDA Fragmente, oder auch Compilation Templates genannt, wurden großteils aus dem bestehenden Art-Decor Repository vom "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente" übernommen. Diese sind unter [[https://art-decor.org/art-decor/decor-templates--at-cda-bbr-?section=templates|at-cda-bbr]] zu finden.{{EndILFBox}}
+Die weiteren CDA Fragmente welche spezifisch für die e-Medikation v3 angepasst wurden sind folgende:
+====Address Compilation v2====
+{{:1.2.40.0.34.6.0.11.9.25.2/dynamic}}
+====Medikation AssignedEntityElements V3====
+{{:1.2.40.0.34.6.0.11.9.68/dynamic}}
+====Organization Compilation with id, name, addr and telecom v2====
+{{:1.2.40.0.34.6.0.11.9.5.2/dynamic}}
+Die weiteren CDA Fragmente  welche in der e-Medikation direkt aus dem bestehenden Art-Decor Repository vom "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente" verwendet worden sind, sind folgende:
+====Medikation Altered Dosage Instructions====
+{{:1.2.40.0.34.6.0.11.9.67/dynamic}}
+====Medikation AuthorElements====
+{{:1.2.40.0.34.6.0.11.9.66/dynamic}}
+====Medikation Dosierungsvariante 1: Tagesdosierung doseQuantity====
+{{:1.2.40.0.34.6.0.11.9.54/dynamic}}
+====Medikation Dosierungsvariante 1: Tagesdosierung effectiveTime====
+{{:1.2.40.0.34.6.0.11.9.50/dynamic}}
+====Medikation Dosierungsvariante 2: Einzeldosierung====
+{{:1.2.40.0.34.6.0.11.9.51/dynamic}}
+====Medikation Dosierungsvariante 2: Einzeldosierung doseQuantity====
+{{:1.2.40.0.34.6.0.11.9.55/dynamic}}
+====Medikation Dosierungsvariante 2: Einzeldosierung entryRelationship====
+{{:1.2.40.0.34.6.0.11.9.58/dynamic}}
+====Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause====
+{{:1.2.40.0.34.6.0.11.9.52/dynamic}}
+====Medikation Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity====
+{{:1.2.40.0.34.6.0.11.9.56/dynamic}}
+====Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause====
+{{:1.2.40.0.34.6.0.11.9.53/dynamic}}
+====Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity====
+{{:1.2.40.0.34.6.0.11.9.57/dynamic}}
+====Medikation Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship====
+{{:1.2.40.0.34.6.0.11.9.60/dynamic}}
+====Medikation Einnahmedauer====
+{{:1.2.40.0.34.6.0.11.9.49/dynamic}}
+====Medikation ID des Containers====
+{{:1.2.40.0.34.6.0.11.9.65/dynamic}}
+====Medikation Patient Instructions====
+{{:1.2.40.0.34.6.0.11.9.62/dynamic}}
+====Medikation Pharmacist Instructions====
+{{:1.2.40.0.34.6.0.11.9.63/dynamic}}
+====Medikation Sbadm TemplateId Options====
+{{:1.2.40.0.34.6.0.11.9.48/dynamic}}
+====Medikation Splitdose-Einnahmezeitpunkte 1====
+{{:1.2.40.0.34.6.0.11.9.59/dynamic}}
+====Medikation Splitdose-Einnahmezeitpunkte 2====
+{{:1.2.40.0.34.6.0.11.9.61/dynamic}}
+====Medikation Therapieart====
+{{:1.2.40.0.34.6.0.11.9.64/dynamic}}
+====Person Name Compilation G2 M====
+{{:1.2.40.0.34.6.0.11.9.11/dynamic}}
 </div>