ILF:E-Medikation (Version 3)

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+20250228-ballot

Normativ

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

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.

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!

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: www.elga.gv.at Email: cda@elga.gv.at

Abbildungen: © ELGA GmbH

Nutzung: Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria, Franckstrasse 41/5/14, 8010 Graz; www.hl7.at.
Die Nutzung ist 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 www.gesundheit.gv.at und www.elga.gv.at/cda

2.2 Haftungsausschluss

Die Arbeiten für den vorliegenden Leitfaden wurden von den Autoren gemäß dem Stand der Technik und mit größtmöglicher Sorgfalt erbracht 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 sich die Standards auf andere urheberrechtlich oder lizenzrechtlich geschützte Werke beziehen.

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

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 in und an den Materialien besitzt und dass die Materialien geistiges Eigentum von Dritten 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 allein ist für die Identifizierung und den Erhalt von notwendigen Lizenzen oder Genehmigungen zur Nutzung von Third Party IP im Zusammenhang mit den Materialien oder anderweitig verantwortlich.
Jegliche Handlungen, Ansprüche oder Klagen eines Dritten, die sich aus einer Verletzung eines Third Party IP-Rechts durch den Lizenznehmer ergeben, bleiben die Haftung 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)	Regenstrief Institute, Inc.
Unified Code for Units of Measure (UCUM)	Regenstrief Institute, Inc.
International Classification of Diseases (ICD)	World Health Organization (WHO)
ICD-10 BMASGK 2020	Bundesministerium für Soziales, Gesundheit, Pflege und Konsumentenschutz www.sozialministerium.at
Anatomical Therapeutic Chemical Classification System (ATC)	World Health Organization (WHO)
Pharmazentralnummer (PZN)	ARGE Pharma im Fachverband der chemischen Industrie Österreichs (FCIO) der Wirtschaftskammern Österreichs (WKO)
EDQM-Codes	Europäisches Direktorat für die Qualität von Arzneimitteln
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 Termserver bereitgestellt. ,

Die Terminologien werden am österreichischen Terminologieserver zur Verfügung gestellt.

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

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 gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert.

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 folgen dem Basisstandard HL7 Version 3 mit seinem Referenz-Informationsmodell (RIM). Dieser Leitfaden verwendet das HL7-Template-Austauschformat zur Definition der "Bausteine" (Templates) und ART-DECOR® als Spezifikationsplattform.

• HL7 Clinical Document Architecture (CDA)
• HL7 Referenz-Informationsmodell (RIM)
• HL7 V3 Datentypen
• HL7 Template-Austauschformat Specification and Use of Reusable Information Constraint Templates, Release 1

Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria), die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden (www.HL7.at). 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 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 e-Prescrition Spezifikation valide ist und jede e-Medikation Abgabe CDA nach eHDSI e-Dispensation 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 ePrescritions 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!

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 e-Medikation 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 cda@elga.gv.at 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:…

Themenbezogenes CDA Beispiel-Fragment im XML Format:

<BEISPIEL>
<languageCode code="de-AT" />

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 Retour: Alt + Pfeil rechts
• Seitenweise blättern: "Bild" Tasten
• Scrollen: Pfeil nach oben bzw. unten
• Zoomen: Strg + Mouserad 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 einheitliche Dokumentation und Codierung der Information. 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 Telemonitoring-Episodenbericht 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 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.

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.

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 1&2

3.2.1.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.1.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)

3.2.2 Version 3 (aktuell)

3.2.2.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.2.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 (Fach­verband der Elektro- und Elektronik­industrie), 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

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 ist in ELGA angemeldet, berechtigt und besitzt eine gültige Kontaktbestätigung für den Patienten. Der Patient ist ELGA-Teilnehmer und hat keinen generellen, partiellen oder situativen Widerspruch hinsichtlich ELGA oder der e-Medikation eingelegt.

4.3 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 ELGA GmbH). Die wesentlichen Anwendungsfälle sind

• Schreiben und Einbringen von Dokumenten
• Versionierung von Dokumenten
• Stornierung von Dokumenten
• Filtern und Suchen von Dokumenten
• Lesen von Dokumenten

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

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
    • Wahlarzt
    • Facharzt
    • 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.
• Akteure in der Apotheke
  • Pharmazeut/In
  • Pharmazeutisch-kaufmännisch(er/e) AssistentIn
• Einrichtung der Pflege
  • Die Umsetzung der Berechtigungen (z.B. darf nur ein Arzt eine Verordnung in e- Medikation speichern), obliegt der GDA-Software.
  • Pflegeperson (siehe Vertreter, Vollmachtnehmer)
• ELGA-Teilnehmer
  • 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. 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
  • EINGELOEST
  • 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 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!

4.4.1.1 Vorbedingung

• ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/ Berechtigung („Ticket“) 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 Katalog6 mit allen ELGA-relevanten Arzneimittelspezialitäten übernommen werden können.
• 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 Terminologieserver frei bezogen werden: https://termgit.elga.gv.at/

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 – 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.
  • 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.
• 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).
• 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/Verordnung 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. 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“.

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.

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

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

4.4.2 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

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.
• 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 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).
• 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.

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 übergeben 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: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/ Berechtigung („Ticket“) 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: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) 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, nicht aber 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

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. 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 übergeben 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: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) 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 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).
  • 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.
• 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

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 xxx).

4.4.5.3.2 =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. Jedenfalls ist das tatsächlich abgegebene Arzneimittel in e-Medikation zu speichern und der Verordnung/dem Rezept zuzuordnen, um die Zugrundeliegende Verordnung einzulösen.

4.4.5.3.3 =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 „EINGELOEST“ 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.

4.4.5.3.4 =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 Verordnungsbrzug 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.5 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.

4.4.5.3.6 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 Arzneimittel in e-Medikation, welche tatsächlich abgegeben werden. 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
• 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.)

4.4.6.1 Vorbedingung

• ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) 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 potentielle Wechselwirkungen, Kontraindikationen, Dosierungen etc. 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 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.

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 übergeben 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: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) 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

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.

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 übergeben 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: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) 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, 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“

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

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

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

• GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) 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 übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.

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

• GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
• e-Medikation Vorbedingung: Abgabe vorhanden, Status=ABGEGEBEN

4.4.10.2 Akteure

• Arzt im niedergelassenen Bereich
• Krankenanstalt
• Apotheke
• Einrichtungen 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 übergeben 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

• GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/Berechtigung („Ticket“) 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 übergeben 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 alle verfügbaren (Quell)Daten der e-Medikation (das sind die Dokumenten- klassen Rezept (Prescription), Abgabe (Dispense), und die entsprechenden Korrektur- meldungen 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 man auch die Historie der Änderungen sehen kann, welche in der Implementierung der Medikationsliste bereits eingearbeitet 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 Dokumentleitfadens mittels Schema und Schematron, sind im allgemeinen Leitfaden unter den folgenden Links zu finden:

• Schema-Prüfung
• Schematron-Prüfung
• Online-Validation von CDA-Dokumenten
• Hinweise zur Konformitätsprüfung
• Abnahmeprüfung für ELGA e-Befunde
• Zertifizierung

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 bisherigen ELGA CDA-Leitfäden ("Allgemeiner 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

:Ü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
Abgabe - kodiert	1..1 M	Medikationsliste Sektion
Verordnung	0..* M	Verordnungs Entry
Abgabe	0..* M	Abgabe Entry
Pharmazeutische Empfehlung	0..* M	Pharmazeutische Empfehlung Entry

:Ü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
Klassifikation	CDA Document Level Template
Offen/Geschlossen	Geschlossen (nur definierte Elemente sind erlaubt)
Benutzt	Benutzt 16 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.45 Inklusion Document StatusCode (1.0.1+20210624) 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.44 Inklusion Document PracticeSettingCode (1.1.0+20210303) 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
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 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. Eingefügt NP von 1.2.40.0.34.6.0.11.1.45 Document StatusCode (DYNAMIC)   Constraint e-Medikations Dokumente sind immer abgeschlossene bzw. "fertige" Dokumente - in diesem Fall erübrigt sich die Angabe eines Status. sdtc:statusCode CS NP Status eines Dokuments. e-Befunde sind grundsätzlich abgeschlossene bzw. "fertige" ("completed") Dokumente, daher entfällt die Angabe eines Status. In folgenden Ausnahmen SOLL der Status eines Dokuments wie folgt angegeben werden: “active”: z.B. wenn bekannt ist, dass Updates folgen werden: Etwa für "vorläufige ärztliche Entlassungsbriefe" oder Laborbefunde, für die noch Ergebnisse einzelner Analysen ausständig sind “nullified”: z.B. für Dokumente, die gemäß Anwendungsfall "Storno von ELGA-Dokumenten" storniert werden, wobei zusätzlich ein letztes Dokument mit Storniert-Status in der Versionskette registriert wird. ↔ Hinweis zum XDS-Mapping: Der Status wird nicht in die XDS-Metadaten übernommen!   Constraint Zulässige Werte für sdtc:statusCode/@code sind "active" und "nullified"   CONF @code muss "nullified" sein oder @code muss "active" sein 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+202407## @codeSystem 1 … 1 F 1.2.40.0.34.5.37 @displayName 1 … 1 F HL7 Austria e-Medikation 3.0.0+202407## Eingefügt NP von 1.2.40.0.34.6.0.11.1.44 Document PracticeSettingCode (DYNAMIC) hl7at:practiceSettingCode CD NP Die fachliche Zuordnung des Dokumentes @displayName 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.75 ELGA_PracticeSetting (DYNAMIC) 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-data​element-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-data​element-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:language​Code CS.LANG 1 … 1 M Sprachcode des Dokuments.   at-cda-bbr-data​element-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-data​element-64  Patient  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F RCT @context​Control​Code 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-data​element-193  EKVK  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-65  LokaleID  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-66  SVNr  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-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 3 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.34.4.21 (1..1 M)    - @extension: Datenfelder der EKVK nach folgender Bildungsvorschrift: concat(Feld 6,"^",Feld 7,"^",Feld 8,"^",Feld 9) wobei Feld 6 "Persönliche Kennummer" 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 EKVK Beispiel-Max <id root="1.2.40.0.34.4.21" extension="123456789^1100-OEGK^800400010016^20251231"/>   Beispiel EKVK Beispiel-Min <id root="1.2.40.0.34.4.21" extension="123456789"/> 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-data​element-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-data​element-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-data​element-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 @determiner​Code 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:administrative​Gender​Code[not(@nullFlavor)] hl7:administrative​Gender​Code[@nullFlavor='UNK'] hl7:administrative​Gender​Code CE 0 … 1 wo [not(@nullFlavor)]   at-cda-bbr-data​element-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 <translation code="772004004" codeSystem="2.16.840.1.113883.6.96" displayName="Non-binary gender"/> hl7:administrative​Gender​Code 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-data​element-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-data​element-192  Verstorben-Kennzeichen  Dataset A Allgemeiner Leitfaden sdtc:deceasedTime TS.AT.TZ 0 … 1 R Todesdatum der Person.   at-cda-bbr-data​element-191  Todesdatum  Dataset A Allgemeiner Leitfaden hl7:marital​Status​Code CE 0 … 1 R Codierung des Familienstands des Patienten. Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“   at-cda-bbr-data​element-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:religious​Affiliation​Code CE 0 … 1 R Codierung des Religionsbekenntnisses des Patienten. Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“   at-cda-bbr-data​element-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:ethnic​Group​Code 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-data​element-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 epSOSPersonalRelationship (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 Address Compilation (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:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) hl7:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:guardian​Organization welches enthält Template 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) hl7:guardian​Person 0 … 1 Name des gesetzlichen Vertreters: Angabe in  Granularitätsstufe 1 Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) hl7:guardian​Person 0 … 1 Name des gesetzlichen Vertreters: Angabe in  Granularitätsstufe 2 Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:guardian​Organization 0 … 1 R Name des gesetzlichen Vertreters (Organisation) Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) hl7:birthplace 0 … 1 R Geburtsort des Patienten.   at-cda-bbr-data​element-76  Geburtsort  Dataset A Allgemeiner Leitfaden @classCode cs 0 … 1 F BIRTHPL hl7:place 1 … 1 M @classCode cs 0 … 1 F PLC @determiner​Code cs 0 … 1 F INSTANCE Auswahl 1 … 1 Elemente in der Auswahl: hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional. Beinhaltet 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts, struktuiert. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:language​Communication 0 … * R Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten.   at-cda-bbr-data​element-100  Sprachfähigkeit  Dataset A Allgemeiner Leitfaden hl7:language​Code 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-data​element-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:proficiency​Level​Code CE 0 … 1 R Grad der Sprachkenntnis in der Sprache. Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“   at-cda-bbr-data​element-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:preference​Ind BL 0 … 1 R Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.   at-cda-bbr-data​element-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 @context​Control​Code 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 epSOSHealthcareProfessionalRoles (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 („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. 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:assigned​Person 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:represented​Organization 1 … 1 M Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. ↔ Hinweis zum XDS-Mapping: Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element 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.7 Organization Compilation with id, name, tel, addr (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-data​element-24  Verwahrer  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F CST hl7:assignedCustodian 1 … 1 M @classCode cs 0 … 1 F ASSIGNED hl7:represented​Custodian​Organization 1 … 1 M @classCode cs 0 … 1 F ORG @determiner​Code 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-data​element-1  Rechtlicher Unterzeichner  Dataset A Allgemeiner Leitfaden @context​Control​Code 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-data​element-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-data​element-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   Beispiel <documentationOf>   <serviceEvent>     <code code="KASSEN" displayName="Kassenrezept" codeSystem="1.2.40.0.10.1.4.3.4.3.3" codeSystemName="ELGA_MedikationRezeptart"/>    <effectiveTime>       <low value="{Beginn des Gültigkeitszeitraums des Rezepts}"/>      <high value="{Ende des Gültigkeitszeitraums des Rezepts}"/>    </effectiveTime>  </serviceEvent></documentationOf> 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äß Rezeptpflichgesetz: 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äß Rezeptpflichgesetz: 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 Verpflichtendes erstes relatedDocument. Im eHDSI Kontext wird hier der Identifikator der nationalen Version des Dokuments gespeichert. Liegen keine solche Informationen vor, hat mindestens das Attribut nullFlavor im id Element des parentDocument Elements den Wert „NA“ zu beinhalten. @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 … * R Im eHDSI Kontext der Identifikator der nationalen Version des Dokuments. Liegen keine Informationen vor, hat das Attribut nullFlavor den Wert „NA“ und alle weiteren Attribute entfallen. @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) Mögliches zweites relatedDocument mit den Informationen zum vorhergehenden Dokument. hl7:relatedDocument 0 … 1 R   at-cda-bbr-data​element-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 @context​Conduction​Ind 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 @context​Conduction​Ind 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
Klassifikation	CDA Document Level Template
Offen/Geschlossen	Geschlossen (nur definierte Elemente sind erlaubt)
Benutzt	Benutzt 15 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.45 Inklusion Document StatusCode (1.0.1+20210624) 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.44 Inklusion Document PracticeSettingCode (1.1.0+20210303) 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
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. Eingefügt NP von 1.2.40.0.34.6.0.11.1.45 Document StatusCode (DYNAMIC)   Constraint e-Medikations Dokumente sind immer abgeschlossene bzw. "fertige" Dokumente - in diesem Fall erübrigt sich die Angabe eines Status. sdtc:statusCode CS NP Status eines Dokuments. e-Befunde sind grundsätzlich abgeschlossene bzw. "fertige" ("completed") Dokumente, daher entfällt die Angabe eines Status. In folgenden Ausnahmen SOLL der Status eines Dokuments wie folgt angegeben werden: “active”: z.B. wenn bekannt ist, dass Updates folgen werden: Etwa für "vorläufige ärztliche Entlassungsbriefe" oder Laborbefunde, für die noch Ergebnisse einzelner Analysen ausständig sind “nullified”: z.B. für Dokumente, die gemäß Anwendungsfall "Storno von ELGA-Dokumenten" storniert werden, wobei zusätzlich ein letztes Dokument mit Storniert-Status in der Versionskette registriert wird. ↔ Hinweis zum XDS-Mapping: Der Status wird nicht in die XDS-Metadaten übernommen!   Constraint Zulässige Werte für sdtc:statusCode/@code sind "active" und "nullified"   CONF @code muss "nullified" sein oder @code muss "active" sein 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+202407## @codeSystem 1 … 1 F 1.2.40.0.34.5.37 @displayName 1 … 1 F HL7 Austria e-Medikation 3.0.0+202407## Eingefügt NP von 1.2.40.0.34.6.0.11.1.44 Document PracticeSettingCode (DYNAMIC) hl7at:practiceSettingCode CD NP Die fachliche Zuordnung des Dokumentes @displayName 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.75 ELGA_PracticeSetting (DYNAMIC) 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-data​element-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-data​element-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:language​Code CS.LANG 1 … 1 M Sprachcode des Dokuments.   at-cda-bbr-data​element-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-data​element-64  Patient  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F RCT @context​Control​Code 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-data​element-193  EKVK  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-65  LokaleID  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-66  SVNr  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-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 3 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.34.4.21 (1..1 M)    - @extension: Datenfelder der EKVK nach folgender Bildungsvorschrift: concat(Feld 6,"^",Feld 7,"^",Feld 8,"^",Feld 9) wobei Feld 6 "Persönliche Kennummer" 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 EKVK Beispiel-Max <id root="1.2.40.0.34.4.21" extension="123456789^1100-OEGK^800400010016^20251231"/>   Beispiel EKVK Beispiel-Min <id root="1.2.40.0.34.4.21" extension="123456789"/> 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-data​element-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-data​element-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-data​element-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 @determiner​Code 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:administrative​Gender​Code[not(@nullFlavor)] hl7:administrative​Gender​Code[@nullFlavor='UNK'] hl7:administrative​Gender​Code CE 0 … 1 wo [not(@nullFlavor)]   at-cda-bbr-data​element-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 <translation code="772004004" codeSystem="2.16.840.1.113883.6.96" displayName="Non-binary gender"/> hl7:administrative​Gender​Code 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-data​element-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-data​element-192  Verstorben-Kennzeichen  Dataset A Allgemeiner Leitfaden sdtc:deceasedTime TS.AT.TZ 0 … 1 R Todesdatum der Person.   at-cda-bbr-data​element-191  Todesdatum  Dataset A Allgemeiner Leitfaden hl7:marital​Status​Code CE 0 … 1 R Codierung des Familienstands des Patienten. Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“   at-cda-bbr-data​element-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:religious​Affiliation​Code CE 0 … 1 R Codierung des Religionsbekenntnisses des Patienten. Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“   at-cda-bbr-data​element-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:ethnic​Group​Code 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-data​element-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 epSOSPersonalRelationship (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 Address Compilation (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:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) hl7:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:guardian​Organization welches enthält Template 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) hl7:guardian​Person 0 … 1 Name des gesetzlichen Vertreters: Angabe in  Granularitätsstufe 1 Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) hl7:guardian​Person 0 … 1 Name des gesetzlichen Vertreters: Angabe in  Granularitätsstufe 2 Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:guardian​Organization 0 … 1 R Name des gesetzlichen Vertreters (Organisation) Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) hl7:birthplace 0 … 1 R Geburtsort des Patienten.   at-cda-bbr-data​element-76  Geburtsort  Dataset A Allgemeiner Leitfaden @classCode cs 0 … 1 F BIRTHPL hl7:place 1 … 1 M @classCode cs 0 … 1 F PLC @determiner​Code cs 0 … 1 F INSTANCE Auswahl 1 … 1 Elemente in der Auswahl: hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional. Beinhaltet 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts, struktuiert. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:language​Communication 0 … * R Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten.   at-cda-bbr-data​element-100  Sprachfähigkeit  Dataset A Allgemeiner Leitfaden hl7:language​Code 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-data​element-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:proficiency​Level​Code CE 0 … 1 R Grad der Sprachkenntnis in der Sprache. Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“   at-cda-bbr-data​element-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:preference​Ind BL 0 … 1 R Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.   at-cda-bbr-data​element-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 @context​Control​Code 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 epSOSHealthcareProfessionalRoles (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 („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. 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:assigned​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:assigned​Authoring​Device welches enthält Template 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC) hl7:assigned​Person 0 … 1 Personendaten des Verfassers des Dokuments. Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen, name-Element ist hier Mandatory. Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:assigned​Authoring​Device 0 … 1 Datenerstellende/s Software/Gerät Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC) hl7:represented​Organization 1 … 1 M Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. ↔ Hinweis zum XDS-Mapping: Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element 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.7 Organization Compilation with id, name, tel, addr (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-data​element-24  Verwahrer  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F CST hl7:assignedCustodian 1 … 1 M @classCode cs 0 … 1 F ASSIGNED hl7:represented​Custodian​Organization 1 … 1 M @classCode cs 0 … 1 F ORG @determiner​Code 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-data​element-1  Rechtlicher Unterzeichner  Dataset A Allgemeiner Leitfaden @context​Control​Code 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-data​element-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-data​element-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 Die Beziehung zwischen der Abgabe und der ursprünglichen Verschreibung im Rezept wird über die Struktur inFulfillmentOf aufrechterhalten. In inFulfillmentOf/order/id befindet sich die ID des Verordnungs-Entries aus dem Rezept. Wird speziell im eHDSI Kontext so genutzt. @typeCode cs 0 … 1 F FLFS hl7:order 1 … 1 R Liegen keine Angaben vor, muss das Attribut nullFlavor den Wert „NI“ haben und es dürfen keine weiteren Attribute oder Elemente vorhanden sein. Andernfalls darf kein nullFlavor vorhanden sein, wenn andere Attribute oder Elemente vorhanden sind. @nullFlavor cs 0 … 1 F NI @classCode cs 0 … 1 F ACT @moodCode cs 1 … 1 F RQO hl7:id II 1 … * R Die verpflichtende ID des Verordnungs-Entries aus dem Rezept hl7:code CE 0 … 1 Der optionale Code wenn man mehr über die verknüfte Verordnung aussagen möchte. @codeSystem CONF 0 … 1 F 2.16.840.1.113883.5.4 (Act Code) hl7:priorityCode CE 0 … 1 Der optionale Prioritäts-Code wenn man mehr über die Priorität der verknüfte Verordnung aussagen möchte.   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 Im eHDSI Kontext wird hier der Identifikator der nationalen Version des Dokuments gespeichert. @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 Im eHDSI Kontext der Identifikator der nationalen Version des Dokuments. 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-data​element-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 @context​Conduction​Ind bl 0 … 1 F true hl7:structuredBody @classCode cs 0 … 1 F DOCBODY @moodCode cs 0 … 1 F EVN hl7:component 1 … 1 R @typeCode cs 0 … 1 F COMP @context​Conduction​Ind 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
Klassifikation	CDA Document Level Template
Offen/Geschlossen	Geschlossen (nur definierte Elemente sind erlaubt)
Benutzt	Benutzt 15 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.45 Inklusion Document StatusCode (1.0.1+20210624) 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.44 Inklusion Document PracticeSettingCode (1.1.0+20210303) 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
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 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.   CONF Elementinhalt muss "Rezept" sein Eingefügt NP von 1.2.40.0.34.6.0.11.1.45 Document StatusCode (DYNAMIC)   Constraint e-Medikations Dokumente sind immer abgeschlossene bzw. "fertige" Dokumente - in diesem Fall erübrigt sich die Angabe eines Status. sdtc:statusCode CS NP Status eines Dokuments. e-Befunde sind grundsätzlich abgeschlossene bzw. "fertige" ("completed") Dokumente, daher entfällt die Angabe eines Status. In folgenden Ausnahmen SOLL der Status eines Dokuments wie folgt angegeben werden: “active”: z.B. wenn bekannt ist, dass Updates folgen werden: Etwa für "vorläufige ärztliche Entlassungsbriefe" oder Laborbefunde, für die noch Ergebnisse einzelner Analysen ausständig sind “nullified”: z.B. für Dokumente, die gemäß Anwendungsfall "Storno von ELGA-Dokumenten" storniert werden, wobei zusätzlich ein letztes Dokument mit Storniert-Status in der Versionskette registriert wird. ↔ Hinweis zum XDS-Mapping: Der Status wird nicht in die XDS-Metadaten übernommen!   Constraint Zulässige Werte für sdtc:statusCode/@code sind "active" und "nullified"   CONF @code muss "nullified" sein oder @code muss "active" sein 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+202407## @codeSystem 1 … 1 F 1.2.40.0.34.5.37 @displayName 1 … 1 F HL7 Austria e-Medikation 3.0.0+202407## Eingefügt NP von 1.2.40.0.34.6.0.11.1.44 Document PracticeSettingCode (DYNAMIC) hl7at:practiceSettingCode CD NP Die fachliche Zuordnung des Dokumentes @displayName 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.75 ELGA_PracticeSetting (DYNAMIC) 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-data​element-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-data​element-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:language​Code CS.LANG 1 … 1 M Sprachcode des Dokuments.   at-cda-bbr-data​element-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-data​element-64  Patient  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F RCT @context​Control​Code 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-data​element-193  EKVK  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-65  LokaleID  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-66  SVNr  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-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 3 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.34.4.21 (1..1 M)    - @extension: Datenfelder der EKVK nach folgender Bildungsvorschrift: concat(Feld 6,"^",Feld 7,"^",Feld 8,"^",Feld 9) wobei Feld 6 "Persönliche Kennummer" 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 EKVK Beispiel-Max <id root="1.2.40.0.34.4.21" extension="123456789^1100-OEGK^800400010016^20251231"/>   Beispiel EKVK Beispiel-Min <id root="1.2.40.0.34.4.21" extension="123456789"/> 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-data​element-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-data​element-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-data​element-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 @determiner​Code 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:administrative​Gender​Code[not(@nullFlavor)] hl7:administrative​Gender​Code[@nullFlavor='UNK'] hl7:administrative​Gender​Code CE 0 … 1 wo [not(@nullFlavor)]   at-cda-bbr-data​element-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 <translation code="772004004" codeSystem="2.16.840.1.113883.6.96" displayName="Non-binary gender"/> hl7:administrative​Gender​Code 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-data​element-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-data​element-192  Verstorben-Kennzeichen  Dataset A Allgemeiner Leitfaden sdtc:deceasedTime TS.AT.TZ 0 … 1 R Todesdatum der Person.   at-cda-bbr-data​element-191  Todesdatum  Dataset A Allgemeiner Leitfaden hl7:marital​Status​Code CE 0 … 1 R Codierung des Familienstands des Patienten. Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“   at-cda-bbr-data​element-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:religious​Affiliation​Code CE 0 … 1 R Codierung des Religionsbekenntnisses des Patienten. Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“   at-cda-bbr-data​element-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:ethnic​Group​Code 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-data​element-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 epSOSPersonalRelationship (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 Address Compilation (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:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) hl7:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:guardian​Organization welches enthält Template 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) hl7:guardian​Person 0 … 1 Name des gesetzlichen Vertreters: Angabe in  Granularitätsstufe 1 Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) hl7:guardian​Person 0 … 1 Name des gesetzlichen Vertreters: Angabe in  Granularitätsstufe 2 Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:guardian​Organization 0 … 1 R Name des gesetzlichen Vertreters (Organisation) Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) hl7:birthplace 0 … 1 R Geburtsort des Patienten.   at-cda-bbr-data​element-76  Geburtsort  Dataset A Allgemeiner Leitfaden @classCode cs 0 … 1 F BIRTHPL hl7:place 1 … 1 M @classCode cs 0 … 1 F PLC @determiner​Code cs 0 … 1 F INSTANCE Auswahl 1 … 1 Elemente in der Auswahl: hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional. Beinhaltet 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts, struktuiert. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:language​Communication 0 … * R Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten.   at-cda-bbr-data​element-100  Sprachfähigkeit  Dataset A Allgemeiner Leitfaden hl7:language​Code 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-data​element-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:proficiency​Level​Code CE 0 … 1 R Grad der Sprachkenntnis in der Sprache. Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“   at-cda-bbr-data​element-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:preference​Ind BL 0 … 1 R Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.   at-cda-bbr-data​element-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 @context​Control​Code 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 epSOSHealthcareProfessionalRoles (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 („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. 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:assigned​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:assigned​Authoring​Device welches enthält Template 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC) hl7:assigned​Person 0 … 1 Personendaten des Verfassers des Dokuments. Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen, name-Element ist hier Mandatory. Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:assigned​Authoring​Device 0 … 1 Datenerstellende/s Software/Gerät Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC) hl7:represented​Organization 1 … 1 M Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. ↔ Hinweis zum XDS-Mapping: Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element 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.7 Organization Compilation with id, name, tel, addr (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-data​element-24  Verwahrer  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F CST hl7:assignedCustodian 1 … 1 M @classCode cs 0 … 1 F ASSIGNED hl7:represented​Custodian​Organization 1 … 1 M @classCode cs 0 … 1 F ORG @determiner​Code 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-data​element-1  Rechtlicher Unterzeichner  Dataset A Allgemeiner Leitfaden @context​Control​Code 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-data​element-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-data​element-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-data​element-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 @context​Conduction​Ind bl 0 … 1 F true hl7:structuredBody @classCode cs 0 … 1 F DOCBODY @moodCode cs 0 … 1 F EVN hl7:component 1 … 1 R @typeCode cs 0 … 1 F COMP @context​Conduction​Ind 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
Klassifikation	CDA Document Level Template
Offen/Geschlossen	Geschlossen (nur definierte Elemente sind erlaubt)
Benutzt	Benutzt 15 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.45 Inklusion Document StatusCode (1.0.1+20210624) 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.44 Inklusion Document PracticeSettingCode (1.1.0+20210303) 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
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 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.   CONF Elementinhalt muss "Medikationsliste" sein Eingefügt NP von 1.2.40.0.34.6.0.11.1.45 Document StatusCode (DYNAMIC)   Constraint e-Medikations Dokumente sind immer abgeschlossene bzw. "fertige" Dokumente - in diesem Fall erübrigt sich die Angabe eines Status. sdtc:statusCode CS NP Status eines Dokuments. e-Befunde sind grundsätzlich abgeschlossene bzw. "fertige" ("completed") Dokumente, daher entfällt die Angabe eines Status. In folgenden Ausnahmen SOLL der Status eines Dokuments wie folgt angegeben werden: “active”: z.B. wenn bekannt ist, dass Updates folgen werden: Etwa für "vorläufige ärztliche Entlassungsbriefe" oder Laborbefunde, für die noch Ergebnisse einzelner Analysen ausständig sind “nullified”: z.B. für Dokumente, die gemäß Anwendungsfall "Storno von ELGA-Dokumenten" storniert werden, wobei zusätzlich ein letztes Dokument mit Storniert-Status in der Versionskette registriert wird. ↔ Hinweis zum XDS-Mapping: Der Status wird nicht in die XDS-Metadaten übernommen!   Constraint Zulässige Werte für sdtc:statusCode/@code sind "active" und "nullified"   CONF @code muss "nullified" sein oder @code muss "active" sein 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+202407## @codeSystem 1 … 1 F 1.2.40.0.34.5.37 @displayName 1 … 1 F HL7 Austria e-Medikation 3.0.0+202407## Eingefügt NP von 1.2.40.0.34.6.0.11.1.44 Document PracticeSettingCode (DYNAMIC) hl7at:practiceSettingCode CD NP Die fachliche Zuordnung des Dokumentes @displayName 1 … 1 R   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.75 ELGA_PracticeSetting (DYNAMIC) 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-data​element-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-data​element-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:language​Code CS.LANG 1 … 1 M Sprachcode des Dokuments.   at-cda-bbr-data​element-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-data​element-64  Patient  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F RCT @context​Control​Code 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-data​element-193  EKVK  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-65  LokaleID  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-66  SVNr  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-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 3 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.34.4.21 (1..1 M)    - @extension: Datenfelder der EKVK nach folgender Bildungsvorschrift: concat(Feld 6,"^",Feld 7,"^",Feld 8,"^",Feld 9) wobei Feld 6 "Persönliche Kennummer" 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 EKVK Beispiel-Max <id root="1.2.40.0.34.4.21" extension="123456789^1100-OEGK^800400010016^20251231"/>   Beispiel EKVK Beispiel-Min <id root="1.2.40.0.34.4.21" extension="123456789"/> 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-data​element-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-data​element-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-data​element-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 @determiner​Code 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:administrative​Gender​Code[not(@nullFlavor)] hl7:administrative​Gender​Code[@nullFlavor='UNK'] hl7:administrative​Gender​Code CE 0 … 1 wo [not(@nullFlavor)]   at-cda-bbr-data​element-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 <translation code="772004004" codeSystem="2.16.840.1.113883.6.96" displayName="Non-binary gender"/> hl7:administrative​Gender​Code 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-data​element-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-data​element-192  Verstorben-Kennzeichen  Dataset A Allgemeiner Leitfaden sdtc:deceasedTime TS.AT.TZ 0 … 1 R Todesdatum der Person.   at-cda-bbr-data​element-191  Todesdatum  Dataset A Allgemeiner Leitfaden hl7:marital​Status​Code CE 0 … 1 R Codierung des Familienstands des Patienten. Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“   at-cda-bbr-data​element-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:religious​Affiliation​Code CE 0 … 1 R Codierung des Religionsbekenntnisses des Patienten. Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“   at-cda-bbr-data​element-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:ethnic​Group​Code 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-data​element-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 epSOSPersonalRelationship (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 Address Compilation (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:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) hl7:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:guardian​Organization welches enthält Template 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) hl7:guardian​Person 0 … 1 Name des gesetzlichen Vertreters: Angabe in  Granularitätsstufe 1 Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) hl7:guardian​Person 0 … 1 Name des gesetzlichen Vertreters: Angabe in  Granularitätsstufe 2 Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:guardian​Organization 0 … 1 R Name des gesetzlichen Vertreters (Organisation) Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) hl7:birthplace 0 … 1 R Geburtsort des Patienten.   at-cda-bbr-data​element-76  Geburtsort  Dataset A Allgemeiner Leitfaden @classCode cs 0 … 1 F BIRTHPL hl7:place 1 … 1 M @classCode cs 0 … 1 F PLC @determiner​Code cs 0 … 1 F INSTANCE Auswahl 1 … 1 Elemente in der Auswahl: hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional. Beinhaltet 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts, struktuiert. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:language​Communication 0 … * R Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten.   at-cda-bbr-data​element-100  Sprachfähigkeit  Dataset A Allgemeiner Leitfaden hl7:language​Code 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-data​element-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:proficiency​Level​Code CE 0 … 1 R Grad der Sprachkenntnis in der Sprache. Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“   at-cda-bbr-data​element-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:preference​Ind BL 0 … 1 R Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.   at-cda-bbr-data​element-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 @context​Control​Code 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 epSOSHealthcareProfessionalRoles (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 („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. 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:assigned​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:assigned​Authoring​Device welches enthält Template 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC) hl7:assigned​Person 0 … 1 Personendaten des Verfassers des Dokuments. Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen, name-Element ist hier Mandatory. Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:assigned​Authoring​Device 0 … 1 Datenerstellende/s Software/Gerät Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC) hl7:represented​Organization 1 … 1 M Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. ↔ Hinweis zum XDS-Mapping: Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element 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.7 Organization Compilation with id, name, tel, addr (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-data​element-24  Verwahrer  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F CST hl7:assignedCustodian 1 … 1 M @classCode cs 0 … 1 F ASSIGNED hl7:represented​Custodian​Organization 1 … 1 M @classCode cs 0 … 1 F ORG @determiner​Code 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 NP von 1.2.40.0.34.6.0.11.1.5.2 Legal Authenticator v2 (DYNAMIC) Im Gegensatz zu den anderen Dokumententypen der e-Medikation kann die Medikationsliste als Zusammenstellung der anderen Dokumente keinen Unterzeichner haben! hl7:legalAuthenticator NP Hauptunterzeichner, Rechtlicher Unterzeichner   at-cda-bbr-data​element-1  Rechtlicher Unterzeichner  Dataset A Allgemeiner Leitfaden @context​Control​Code 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-data​element-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-data​element-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 NP 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-data​element-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 @context​Conduction​Ind bl 0 … 1 F true hl7:structuredBody @classCode cs 0 … 1 F DOCBODY @moodCode cs 0 … 1 F EVN hl7:component 1 … 1 R @typeCode cs 0 … 1 F COMP @context​Conduction​Ind 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 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 EHDS 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-data​element-100  Sprachfähigkeit  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-101  Sprache  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-102  Grad der Sprachkenntnis  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-103  Sprachpräferenz  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-191  Todesdatum  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-192  Verstorben-Kennzeichen  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-193  EKVK  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-64  Patient  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-65  LokaleID  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-66  SVNr  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-67  bPK-GH  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-68  Adresse  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-70  Name  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-72  Kontaktdaten  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-74  Geschlecht  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-75  Geburtsdatum  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-76  Geburtsort  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-88  Gesetzlicher Vertreter  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-98  Familienstand  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-99  Religionsbekenntnis  Dataset A Allgemeiner Leitfaden
Benutzt	Benutzt 6 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.25 Containment Address Compilation (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 Containment Address Compilation Minimal (1.0.2+20230717) DYNAMIC
Beispiel	Strukturbeispiel <recordTarget typeCode="RCT" contextControlCode="OP">   <patientRole classCode="PAT">     <!-- lokale Patienten ID vom System -->     <id root="1.2.40.0.34.99.111.1.2" extension="4711" assigningAuthorityName="Amadeus Spital"/>    <!-- Sozialversicherungsnummer des Patienten -->     <id root="1.2.40.0.10.1.4.3.1" extension="1111241261" assigningAuthorityName="Österreichische Sozialversicherung"/>    <!-- bPK-GH des Patienten -->     <id root="1.2.40.0.10.2.1.1.149" extension="GH:b64encodedbPKValue"/>    <!-- Adresse des Patienten -->     <addr>       <!-- template 1.2.40.0.34.6.0.11.9.25 'Address Compilation' (2019-02-28T14:24:14) -->     </addr>    <!-- Kontaktdaten des Patienten-->     <telecom value="tel:+43.1.40400" use="H"/>    <telecom value="tel:+43.664.1234567" use="MC"/>    <telecom value="mailto:herbert.mustermann@provider.at"/>    <patient classCode="PSN" determinerCode="INSTANCE">       <!-- Name des Patienten (Granularitätsstufe 2) -->       <name>         <!-- template 1.2.40.0.34.6.0.11.9.11 'Person Name Compilation G2 M' -->       </name>      <!-- Geschlecht des Patienten -->       <administrativeGenderCode displayName="Male" code="M" codeSystem="2.16.840.1.113883.5.1" codeSystemName="HL7:AdministrativeGender"/>      <!-- Geburtsdatum des Patienten -->       <birthTime value="19701224"/>      <!-- Optional: Verstorben-Kennzeichen -->       <deceasedInd value="true"/>      <!-- Optional: Todesdatum / Todeszeitpunkt -->       <deceasedTime value="20200101"/>      <!-- Familienstand des Patienten -->       <maritalStatusCode code="D" codeSystem="2.16.840.1.113883.5.2" codeSystemName="HL7:MaritalStatus" displayName="Divorced"/>      <!-- Religionszugehörigkeit des Patienten -->       <religiousAffiliationCode code="101" displayName="Römisch-Katholisch" codeSystem="2.16.840.1.113883.2.16.1.4.1" codeSystemName="HL7.AT:ReligionAustria"/>      <!-- Gesetzlicher Vertreter des Patienten "Organisation"-->       <guardian classCode="GUARD">         <!-- Gesetzlicher Vertreter "Person" -->         <addr>           <!-- template 1.2.40.0.34.6.0.11.9.25 'Address Compilation' (2019-02-28T14:24:14) -->         </addr>        <!-- Kontaktdaten des gesetzlichen Vertreters -->         <telecom use="H" value="tel:+43.2236.2928"/>        <telecom use="WP" value="tel:+43.2236.9000"/>        <!-- Name des gesetzlichen Vertreters (Granularitätsstufe 1) -->         <guardianPerson>           <name>             <!-- template 1.2.40.0.34.6.0.11.9.12 'Person Name Compilation G1 M' -->           </name>        </guardianPerson>      </guardian>      <birthplace classCode="BIRTHPL">         <place classCode="PLC" determinerCode="INSTANCE">           <!-- 1.2.40.0.34.6.0.11.9.10 'Address Compilation Minimal' -->         </place>      </birthplace>      <languageCommunication>         <languageCode code="de"/>        <modeCode code="ESP" displayName="Expressed spoken" codeSystem="2.16.840.1.113883.5.60" codeSystemName="HL7:LanguageAbilityMode"/>        <proficiencyLevelCode code="E" displayName="Excellent" codeSystem="2.16.840.1.113883.5.61" codeSystemName="HL7:LanguageAbilityProficiency"/>        <preferenceInd value="true"/>      </languageCommunication>      <!-- Strukturierung der Fähigkeit zur Gebärdensprache -->       <languageCommunication>         <languageCode code="de"/>        <proficiencyLevelCode code="G" displayName="Good" codeSystem="2.16.840.1.113883.5.61" codeSystemName="HL7:LanguageAbilityProficiency"/>        <preferenceInd value="false"/>      </languageCommunication>    </patient>  </patientRole></recordTarget>
Item DT Kard Konf Beschreibung Label hl7:recordTarget Komponente für die Patientendaten.   at-cda-bbr-data​element-64  Patient  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F RCT @context​Control​Code 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-data​element-193  EKVK  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-65  LokaleID  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-66  SVNr  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-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 3 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.34.4.21 (1..1 M)    - @extension: Datenfelder der EKVK nach folgender Bildungsvorschrift: concat(Feld 6,"^",Feld 7,"^",Feld 8,"^",Feld 9) wobei Feld 6 "Persönliche Kennummer" 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 EKVK Beispiel-Max <id root="1.2.40.0.34.4.21" extension="123456789^1100-OEGK^800400010016^20251231"/>   Beispiel EKVK Beispiel-Min <id root="1.2.40.0.34.4.21" extension="123456789"/> 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-data​element-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-data​element-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-data​element-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 @determiner​Code 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:administrative​Gender​Code[not(@nullFlavor)] hl7:administrative​Gender​Code[@nullFlavor='UNK'] hl7:administrative​Gender​Code CE 0 … 1 wo [not(@nullFlavor)]   at-cda-bbr-data​element-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 <translation code="772004004" codeSystem="2.16.840.1.113883.6.96" displayName="Non-binary gender"/> hl7:administrative​Gender​Code 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-data​element-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-data​element-192  Verstorben-Kennzeichen  Dataset A Allgemeiner Leitfaden sdtc:deceasedTime TS.AT.TZ 0 … 1 R Todesdatum der Person.   at-cda-bbr-data​element-191  Todesdatum  Dataset A Allgemeiner Leitfaden hl7:marital​Status​Code CE 0 … 1 R Codierung des Familienstands des Patienten. Zulässige Werte gemäß Value-Set „ELGA_MaritalStatus“   at-cda-bbr-data​element-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:religious​Affiliation​Code CE 0 … 1 R Codierung des Religionsbekenntnisses des Patienten. Zulässige Werte gemäß Value-Set „ELGA_ReligiousAffiliation“   at-cda-bbr-data​element-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:ethnic​Group​Code 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-data​element-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 epSOSPersonalRelationship (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 Address Compilation (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:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) hl7:guardian​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:guardian​Organization welches enthält Template 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) hl7:guardian​Person 0 … 1 Name des gesetzlichen Vertreters: Angabe in  Granularitätsstufe 1 Beinhaltet 1.2.40.0.34.6.0.11.9.12 Person Name Compilation G1 M (DYNAMIC) hl7:guardian​Person 0 … 1 Name des gesetzlichen Vertreters: Angabe in  Granularitätsstufe 2 Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:guardian​Organization 0 … 1 R Name des gesetzlichen Vertreters (Organisation) Beinhaltet 1.2.40.0.34.6.0.11.9.27 Organization Name Compilation (DYNAMIC) hl7:birthplace 0 … 1 R Geburtsort des Patienten.   at-cda-bbr-data​element-76  Geburtsort  Dataset A Allgemeiner Leitfaden @classCode cs 0 … 1 F BIRTHPL hl7:place 1 … 1 M @classCode cs 0 … 1 F PLC @determiner​Code cs 0 … 1 F INSTANCE Auswahl 1 … 1 Elemente in der Auswahl: hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) hl7:addr welches enthält Template 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts. Minimalangabe. Alle Elemente optional. Beinhaltet 1.2.40.0.34.6.0.11.9.10 Address Compilation Minimal (DYNAMIC) hl7:addr AD 0 … 1 Die Adresse des Geburtsorts, struktuiert. Beinhaltet 1.2.40.0.34.6.0.11.9.25 Address Compilation (DYNAMIC) hl7:language​Communication 0 … * R Informationen bezüglich der Sprachfähigkeiten und Ausdrucksform des Patienten.   at-cda-bbr-data​element-100  Sprachfähigkeit  Dataset A Allgemeiner Leitfaden hl7:language​Code 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-data​element-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:proficiency​Level​Code CE 0 … 1 R Grad der Sprachkenntnis in der Sprache. Zulässige Werte gemäß Value-Set „ELGA_ProficiencyLevelCode“   at-cda-bbr-data​element-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:preference​Ind BL 0 … 1 R Kennzeichnung, ob die Sprache in der angegebenen Ausdrucksform vom Patienten bevorzugt wird.   at-cda-bbr-data​element-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 3 Templates Benutzt als Name Version 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.7 Containment Organization Compilation with id, name, tel, addr (1.0.0+20210219) 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 <author typeCode="AUT" contextControlCode="OP">   <!-- Funktionscode -->   <functionCode code="2211" displayName="Generalist medical practitioners" codeSystem="2.16.840.1.113883.2.9.6.2.7" codeSystemName="ISCO-08"/>  <!-- Zeitpunkt der Erstellung -->   <time value="20190605133410+0200"/>  <assignedAuthor classCode="ASSIGNED">     <!-- Identifikation des Verfassers des Dokuments -->     <id root="1.2.40.0.34.99.111.1.3" extension="1111" assigningAuthorityName="Amadeus Spital"/>    <!-- Fachrichtung des Verfassers des Dokuments -->     <code code="107" displayName="Fachärztin/Facharzt für Chirurgie" codeSystem="1.2.40.0.34.5.160" codeSystemName="ELGA_Fachaerzte"/>    <!-- Kontaktdaten des Verfassers des Dokuments -->     <telecom value="tel:+43.1.40400"/>    <telecom value="mailto:Isabella.Stern@organization.at"/>    <!-- Person als Author -->     <assignedPerson classCode="PSN" determinerCode="INSTANCE">       <!-- template 1.2.40.0.34.6.0.11.9.11 'Person Name Compilation G2 M' (2019-04-02T10:09:43) -->     </assignedPerson>    <representedOrganization>       <!-- template 1.2.40.0.34.6.0.11.9.5 'Organization Compilation with id, name' (2019-03-25T13:43:57) -->     </representedOrganization>  </assignedAuthor></author>
Beispiel	Gerät als Author <author typeCode="AUT" contextControlCode="OP">   <!-- Zeitpunkt der Erstellung -->   <time value="20190605133410+0200"/>  <assignedAuthor classCode="ASSIGNED">     <!-- Geräte Identifikation (oder nullFlavor) -->     <id root="86562fe5-b509-4ce9-b976-176fd376e477" assigningAuthorityName="KH Eisenstadt"/>    <!-- Gerät als Author -->     <assignedAuthoringDevice classCode="DEV" determinerCode="INSTANCE">       <!-- template 1.2.40.0.34.6.0.11.9.18 'Device Compilation' (2019-02-13T10:11:00) -->     </assignedAuthoringDevice>    <representedOrganization>       <!-- template 1.2.40.0.34.6.0.11.9.5 'Organization Compilation with id, name' (2019-03-25T13:43:57) -->     </representedOrganization>  </assignedAuthor></author>
Item DT Kard Konf Beschreibung Label hl7:author Verfasser des Dokuments. @typeCode cs 0 … 1 F AUT @context​Control​Code 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 epSOSHealthcareProfessionalRoles (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 („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. 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:assigned​Person welches enthält Template 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:assigned​Authoring​Device welches enthält Template 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC) hl7:assigned​Person 0 … 1 Personendaten des Verfassers des Dokuments. Grundsätzlich sind die Vorgaben für „Personen-Element“ zu befolgen, name-Element ist hier Mandatory. Beinhaltet 1.2.40.0.34.6.0.11.9.11 Person Name Compilation G2 M (DYNAMIC) hl7:assigned​Authoring​Device 0 … 1 Datenerstellende/s Software/Gerät Beinhaltet 1.2.40.0.34.6.0.11.9.18 Device Compilation (DYNAMIC) hl7:represented​Organization 1 … 1 M Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. ↔ Hinweis zum XDS-Mapping: Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element 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.7 Organization Compilation with id, name, tel, addr (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 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 2 Templates Benutzt als Name Version 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.7 Containment Organization Compilation with id, name, tel, addr (1.0.0+20210219) DYNAMIC
Beziehung	Adaptation: Template 1.2.40.0.34.777.7.10.5 (2025‑02‑23 09:50:28) ref at-cda-bbr- 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 <author typeCode="AUT" contextControlCode="OP">   <!-- Funktionscode -->   <functionCode code="2211" displayName="Generalist medical practitioners" codeSystem="2.16.840.1.113883.2.9.6.2.7" codeSystemName="ISCO-08"/>  <!-- Zeitpunkt der Erstellung -->   <time value="20190605133410+0200"/>  <assignedAuthor classCode="ASSIGNED">     <!-- Identifikation des Verfassers des Dokuments -->     <id root="1.2.40.0.34.99.111.1.3" extension="1111" assigningAuthorityName="Amadeus Spital"/>    <!-- Fachrichtung des Verfassers des Dokuments -->     <code code="107" displayName="Fachärztin/Facharzt für Chirurgie" codeSystem="1.2.40.0.34.5.160" codeSystemName="ELGA_Fachaerzte"/>    <!-- Kontaktdaten des Verfassers des Dokuments -->     <telecom value="tel:+43.1.40400"/>    <telecom value="mailto:Isabella.Stern@organization.at"/>    <!-- Person als Author -->     <assignedPerson classCode="PSN" determinerCode="INSTANCE">       <!-- template 1.2.40.0.34.6.0.11.9.11 'Person Name Compilation G2 M' (2019-04-02T10:09:43) -->     </assignedPerson>    <representedOrganization>       <!-- template 1.2.40.0.34.6.0.11.9.5 'Organization Compilation with id, name' (2019-03-25T13:43:57) -->     </representedOrganization>  </assignedAuthor></author>
Item DT Kard Konf Beschreibung Label hl7:author Verfasser des Dokuments. @typeCode cs 0 … 1 F AUT @context​Control​Code 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 epSOSHealthcareProfessionalRoles (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 („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. 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:assigned​Person 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:represented​Organization 1 … 1 M Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. ↔ Hinweis zum XDS-Mapping: Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element 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.7 Organization Compilation with id, name, tel, addr (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.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. Da CDA ein Austauschformat für Dokumente ist und ein CDA-Dokument möglicherweise nicht die ursprüngliche Form der authentifizierten Dokumente darstellt, repräsentiert der Custodian den Verwalter der ursprünglichen Quelldokumente.
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-data​element-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	Beispiel <!-- Verwahrer des Dokuments --> <custodian typeCode="CST">   <assignedCustodian classCode="ASSIGNED">     <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">       <!-- Identifikation des Verwahrers -->       <id root="1.2.3.999" extension="7601234567890"/>      <name>Amadeus Spital</name>      <telecom use="WP" value="tel:+43.(0)50.55460-0"/>      <telecom use="MC" value="tel:+43.(0)676.55461"/>      <addr>         <!-- template 1.2.40.0.34.6.0.11.9.25 'Address Compilation' (2019-02-28T14:24:14) -->       </addr>    </representedCustodianOrganization>  </assignedCustodian></custodian>
Item DT Kard Konf Beschreibung Label hl7:custodian Verwahrer des Dokuments.   at-cda-bbr-data​element-24  Verwahrer  Dataset A Allgemeiner Leitfaden @typeCode cs 0 … 1 F CST hl7:assignedCustodian 1 … 1 M @classCode cs 0 … 1 F ASSIGNED hl7:represented​Custodian​Organization 1 … 1 M @classCode cs 0 … 1 F ORG @determiner​Code 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: Dieses Element wird ins XDS-Metadatenelement DocumentEntry.legalAuthenticator gemappt. ACHTUNG: Nach DocumentEntry.legalAuthenticator kann jeweils nur das erste Element (ClinicalDocument/LegalAuthenticator[1]) übernommen werden.
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-data​element-1  Rechtlicher Unterzeichner  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-5  Zeitpunkt der Unterzeichnung  Dataset A Allgemeiner Leitfaden at-cda-bbr-data​element-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 <legalAuthenticator contextControlCode="OP" typeCode="LA">   <!-- Zeitpunkt der Unterzeichnung -->   <time value="20190324082015+0100"/>  <!-- Signaturcode -->   <signatureCode code="S"/>  <!-- Personen- und Organisationsdaten des Rechtlichen Unterzeichners des Dokuments -->   <assignedEntity>     <!-- include template 1.2.40.0.34.6.0.11.9.22 'Assigned Entity' (dynamic) .. O -->   </assignedEntity></legalAuthenticator>
Item DT Kard Konf Beschreibung Label hl7:legalAuthenticator Hauptunterzeichner, Rechtlicher Unterzeichner   at-cda-bbr-data​element-1  Rechtlicher Unterzeichner  Dataset A Allgemeiner Leitfaden @context​Control​Code 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-data​element-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-data​element-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)

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
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-
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 Verpflichtende Abgabe-Sektion ID. Es gelten die Vorgaben der Identifikations-Elemente des allgemeinen Leitfadens. Es wird empfohlen, die Methode 3 der Identifikationselement mit den UUID zu verwenden. @root uid 1 … 1 R @extension st 0 … 1   @assigningAuthorityName st 0 … 1     Beispiel Methode 1: Angabe einer OID als direkten Identifikator <id root="1.2.40.0.34.99.111.0.1" assigningAuthorityName="KH Eisenstadt"/>   Beispiel Methode 2: Angabe der OID der ID-Liste in @root sowie der eigentlichen ID in @extension <id root="1.2.40.0.34.99.111.1.1" extension="134F989" assigningAuthorityName="KH Eisenstadt"/>   Beispiel Methode 3: Angabe einer UUID als extension zur OID '2.25' <id root="2.25" extension="urn:uuid:19FEE6C3-6B35-4C5B-B1CC-2B5B4001AB2" assigningAuthorityName="KH Eisenstadt"/> 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 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
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>   <!-- ELGA -->   <templateId root="1.2.40.0.34.11.8.2.2.1"/>  <!-- IHE PHARM -->   <templateId root="1.3.6.1.4.1.19376.1.9.1.2.3"/>  <!-- HL7 CCD -->   <templateId root="2.16.840.1.113883.10.20.1.8"/>  <!-- Code der Sektion -->   <code code="60590-7" displayName="Medication Dispensed.Brief" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->   <title>Abgabe</title>  <!-- Textbereich der Sektion -->   <text> ... Lesbarer Textbereich ... </text>  <!-- Maschinenlesbare Elemente -->   <entry>     <!-- ELGA MedikationAbgabe-Entry -->     <templateId root="1.2.40.0.10.1.4.3.4.1.3.2"/>  </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 Verpflichtende Abgabe-Sektion ID. Es gelten die Vorgaben der Identifikations-Elemente des allgemeinen Leitfadens. Es wird empfohlen, die Methode 3 der Identifikationselement mit den UUID zu verwenden. @root uid 1 … 1 R @extension st 0 … 1   @assigningAuthorityName st 0 … 1     Beispiel Methode 1: Angabe einer OID als direkten Identifikator <id root="1.2.40.0.34.99.111.0.1" assigningAuthorityName="KH Eisenstadt"/>   Beispiel Methode 2: Angabe der OID der ID-Liste in @root sowie der eigentlichen ID in @extension <id root="1.2.40.0.34.99.111.1.1" extension="134F989" assigningAuthorityName="KH Eisenstadt"/>   Beispiel Methode 3: Angabe einer UUID als extension zur OID '2.25' <id root="2.25" extension="urn:uuid:19FEE6C3-6B35-4C5B-B1CC-2B5B4001AB2" assigningAuthorityName="KH Eisenstadt"/> 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 Für die e-Medikation soll die Sektion immer "Abgabe" heißen, im eHDSI Kontext hingegen immer "Dispensation". Bei allen anderen Fällen ist der jeweilige Leitfaden zu beachten! hl7:text SD.TEXT 1 … 1 M Information für den menschlichen Leser. 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
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>   <templateId root="1.2.40.0.34.11.8.4.2.1"/>  <!-- ELGA -->   <templateId root="1.3.6.1.4.1.19376.1.9.1.2.2"/>  <!-- IHE PHARM -->   <!-- Code der Sektion -->   <code code="61357-0" displayName="Medication Pharmaceutical Advice.Brief" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  <!-- Titel der Sektion -->   <title>Pharmazeutische Empfehlung</title>  <!-- Textbereich der Sektion -->   <text> ... Lesbarer Textbereich ... </text>  <!-- Maschinenlesbare Elemente -->   <entry typeCode="DRIV">      :     <!-- ELGA MedikationPharmazeutischeEmpfehlung-Entry -->     <templateId root="1.2.40.0.34.11.8.4.3.1"/>     :   </entry></section>
Item DT Kard Konf Beschreibung Label hl7:section @classCode cs 0 … 1 F DOCSECT hl7:templateId II 1 … 1 M e-Medikation v3 Sektion - Pharmazeutische Empfehlung - kodiert @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 Verpflichtende Abgabe-Sektion ID. Es gelten die Vorgaben der Identifikations-Elemente des allgemeinen Leitfadens. Es wird empfohlen, die Methode 3 der Identifikationselement mit den UUID zu verwenden. @root uid 1 … 1 R @extension st 0 … 1   @assigningAuthorityName st 0 … 1     Beispiel Methode 1: Angabe einer OID als direkten Identifikator <id root="1.2.40.0.34.99.111.0.1" assigningAuthorityName="KH Eisenstadt"/>   Beispiel Methode 2: Angabe der OID der ID-Liste in @root sowie der eigentlichen ID in @extension <id root="1.2.40.0.34.99.111.1.1" extension="134F989" assigningAuthorityName="KH Eisenstadt"/>   Beispiel Methode 3: Angabe einer UUID als extension zur OID '2.25' <id root="2.25" extension="urn:uuid:19FEE6C3-6B35-4C5B-B1CC-2B5B4001AB2" assigningAuthorityName="KH Eisenstadt"/> 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 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 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
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
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 Verpflichtende Medikationsliste-Sektion ID. Es gelten die Vorgaben der Identifikations-Elemente des allgemeinen Leitfadens. Es wird empfohlen, die Methode 3 der Identifikationselement mit den UUID zu verwenden. @root uid 1 … 1 R @extension st 0 … 1   @assigningAuthorityName st 0 … 1     Beispiel Methode 1: Angabe einer OID als direkten Identifikator <id root="1.2.40.0.34.99.111.0.1" assigningAuthorityName="KH Eisenstadt"/>   Beispiel Methode 2: Angabe der OID der ID-Liste in @root sowie der eigentlichen ID in @extension <id root="1.2.40.0.34.99.111.1.1" extension="134F989" assigningAuthorityName="KH Eisenstadt"/>   Beispiel Methode 3: Angabe einer UUID als extension zur OID '2.25' <id root="2.25" extension="urn:uuid:19FEE6C3-6B35-4C5B-B1CC-2B5B4001AB2" assigningAuthorityName="KH Eisenstadt"/> 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 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	ArzneiEntryv3	Bezeichnung	Arznei Entry v3
Klassifikation	CDA Entry Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Item DT Kard Konf Beschreibung Label hl7:manufacturedProduct @classCode cs 1 … 1 F MANU hl7:templateId II 1 … 1 R Arznei Entry v3 @root uid 1 … 1 F 1.2.40.0.34.6.0.11.3.172 hl7:templateId II 1 … 1 R eHDSI eP/eD Medication Information @root uid 1 … 1 F 1.3.6.1.4.1.12559.11.10.1.3.1.3.29 hl7:manufactured​Material 1 … 1 M @classCode cs 1 … 1 F MMAT @determiner​Code cs 1 … 1 F KIND   Constraint Konditionale Konformität: Card Conf Prädikat 0..1 O PZN oder Zulassungsnummer vorhanden NP PZN oder Zulassungsnummer nicht vorhanden hl7:templateId II 1 … 1 R eHDSI eP/eD Medication Information @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) <code code="981417" displayName="CIPROXIN FTBL 500MG" codeSystem="1.2.40.0.34.4.16" codeSystemName="Pharmazentralnummer"/>   Beispiel Code der Arznei (PRN) <code code="123456789" displayName="CIPROXIN FTBL 500MG" codeSystem="1.2.40.0.34.4.26" codeSystemName="Package Reference Number"/>   Beispiel Code der Arznei (Zulassungsnummer) <code code="1-18296" displayName="CIPROXIN FTBL 500MG" codeSystem="1.2.40.0.34.4.17" codeSystemName="Zulassungsnummer"/>   Beispiel Code der Arznei (PZN) mit Zulassungsnummer <code code="981417" displayName="CIPROXIN FTBL 500MG" codeSystem="1.2.40.0.34.4.16" codeSystemName="Pharmazentralnummer">   <translation code="1-18296" displayName="CIPROXIN FTBL 500MG" codeSystem="1.2.40.0.34.4.17" codeSystemName="Zulassungsnummer"/></code>   Beispiel Magistrale Zubereitung oder Infusionen ohne PZN oder sonstigem erlaubten Code <code nullFlavor="NA"/> hl7:originalText ED 0 … 1 Verweist auf die Stelle im narrativen Text-bereich, in dem die Pharmazentralnummer beschrieben ist. Gemäß Vorgaben im „Allgemeinen Implementierungsleitfaden“, Kapitel „Codierungs-Elemente“. 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. Die Bezeichnung der magistralen Zubereitung oder Infusion 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 <name nullFlavor="NA"/> pharm:formCode CE 1 … 1 R Darreichungsform. Kann bei codierten Arzneien aus der ASP-Liste entnommen werden. @nullFlavor 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 <formCode code="100000073665" displayName="Filmtablette" codeSystem="1.2.40.0.10.1.4.3.4.3.5" codeSystemName="ELGA_MedikationDarreichungsform"/>   Beispiel Darreichungsform bei eHDSI ePrescription/eDispensation <formCode code="10211000" displayName="Capsule, soft" codeSystem="0.4.0.127.0.16.1.1.2.1" codeSystemName="EDQM"/>   Beispiel Darreichungsform unbekannt bei codierter Arznei <formCode nullFlavor="NI"/>   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 Dieses Element beschreibt die Menge der Arznei in der Packung. @unit cs 0 … 1   Optionale beschreibung der verwendeten Einheit. Wird dieses Attribut @unit nicht angegeben, so gilt der Standardwert „1“. Falls das ValueSet keine passenden Einheiten liefert, kann bei zählbaren Einheiten das Attribut „unit“ auch auf „1“ gesetzt werden und das translation-Element verwendet werden, um die genaue Art der Einheit anzugeben.   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 Verpflichtende Anzahl der Einheiten. Falls unbekannt soll der Wert „1“ hier eingetragen werden. hl7:translation PQR 0 … 1 hl7:originalText ED 1 … 1 M pharm:container​Packaged​Medicine 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 1 … 1 F CONT @determiner​Code 1 … 1 F KIND pharm:formCode 1 … 1 R @nullFlavor 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 entspricht 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 @determiner​Code 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. hl7:originalText ED 0 … 1 Textinhalt, der codiert wurde. Gemäß Vorgaben im „Allgemeinen Implementierungsleitfaden“, Kapitel „Codierungs-Elemente“. Bei Magistralen Zubereitungen kann hier auf die Rezeptur im Text verwiesen werden! hl7:reference TEL 0 … 1 @value 1 … 1 R hl7:translation CE 0 … * 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	MedikationVerordnungEntryemedv3	Bezeichnung	Medikation Verordnung Entry eMedikation v3
Klassifikation	CDA Entry Level Template
Offen/Geschlossen	Offen (auch andere als die definierten 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
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äß Projekt e-Medikation: Das erste ID Element enthält eine von Zentralkomponenten 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 Befundklassen 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 <id root="1.2.40.0.10.1.4.3.4.2.2" extension="WYE82A2G8EEW_4711" assigningAuthorityName="Ordination Dr. Muster"/>   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: Das zweite ID Element enthält die ID des ursprünglich im Rezept-Dokument angegebenen Verordnungs-Entry, welcher der Ausgangspunkt des vorliegenden Verordnungs-Entry darstellt. Konditionale Konformität Verordnungs-Entry liegt in Medikationsliste oder Pharmazeutischen Empfehlung vor: Card 1..1 Conf M Verordnungs-Entry in einem Rezept: NP 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 <text>   <reference value="#vpos-1"/></text> 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>   <!-- Einnahme von 27.05.2011, Ende unbekannt -->   <cda:effectiveTime xsi:type="IVL_TS">     <cda:low value="20110527000000+0200"/>    <cda:high nullFlavor="UNK"/>  </cda:effectiveTime></cda:ClinicalDocument>   Beispiel Strukturbeispiel <cda:ClinicalDocument>   <!-- Einnahmestart unbekannt, Dauer 2 Wochen lang -->   <cda:effectiveTime xsi:type="IVL_TS">     <cda:width value="2" unit="wk"/>  </cda:effectiveTime></cda:ClinicalDocument>   Beispiel Strukturbeispiel <cda:ClinicalDocument>   <!-- Dosierungsinformationen sind angegeben, aber Einnahmedauer unbekannt -->   <cda:effectiveTime xsi:type="IVL_TS">     <cda:low nullFlavor="UNK"/>    <cda:high nullFlavor="UNK"/>  </cda:effectiveTime></cda:ClinicalDocument> Auswahl 0 … 1 Elemente in der Auswahl: hl7:effectiveTime[1][hl7:low] hl7:effectiveTime[1][hl7:width] hl7:effectiveTime[1][@nullFlavor] hl7:effectiveTime IVL_TS 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 Dauer der Einnahme, wenn Einnahmestart unbekannt wo [1] [hl7:width] hl7:width PQ 1 … 1 R 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 wo [1] [@nullFlavor] @nullFlavor cs 1 … 1 F NA   Constraint Konditionale Konformität Card Conf Prädikat 1..1 M Es wird in einer Verordnung (1.2.40.0.34.11.8.1.3.1) die Dosierungsvariante "Split" mit templateId 1.3.6.1.4.1.19376.1.5.3.1.4.9 verwendet wird. 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: MSKWird 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 <repeatNumber value="0"/> 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 <routeCode code="100000073633" displayName="Subkutane Anwendung" codeSystem="1.2.40.0.10.1.4.3.4.3.4" codeSystemName="ELGA_MedikationArtAnwendung"/>   Beispiel eHDSI ePrescription/eDispensation <routeCode code="20066000" displayName="Subcutaneous use" codeSystem="0.4.0.127.0.16.1.1.2.1" codeSystemName="EDQM"/> 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 <consumable typeCode="CSM">   <!-- ELGA Arznei Element (1.2.40.0.34.6.0.11.3.186) -->   <manufacturedProduct classCode="MANU">     <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>    <!-- IHE PCC -->     <templateId root="2.16.840.1.113883.10.20.1.53"/>    <!-- HL7 CCD -->     <manufacturedMaterial classCode="MMAT" determinerCode="KIND">       <!-- ELGA Arznei-Entry -->       <templateId root="1.2.40.0.34.6.0.11.3.186"/>      <!-- ELGA -->        :     </manufacturedMaterial>  </manufacturedProduct></consumable> Eingefügt 0 … 1 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 0 … 1 C Verfasser des Dokuments. @typeCode cs 0 … 1 F AUT @context​Control​Code 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 epSOSHealthcareProfessionalRoles (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 („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. 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:assigned​Person 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:represented​Organization 1 … 1 M Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. ↔ Hinweis zum XDS-Mapping: Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element 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.7 Organization Compilation with id, name, tel, addr (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 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.11.30046 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:manufactured​Material 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.11.30047 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:manufactured​Material 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 <entryRelationship typeCode="COMP">   <supply classCode="SPLY" moodCode="RQO">     <independentInd value="false"/>    <quantity value="1"/>  </supply></entryRelationship> 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 <supply classCode="SPLY" moodCode="RQO">   <independentInd value="false"/>  <quantity value="1"/></supply> 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:manufactured​Material/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 (IHEActCode Vocabulary) 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 Verifikation, eine Überprüfung ob das Medikament wirkt wie für diese Behandlung geplant, mit "veri" im code Element bzw. mit "#veri-{generierteID}" im reference Element gesetzt ist, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime Element gesetzt werden. hl7:entryRelationship 0 … 1 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 (IHEActCode Vocabulary) 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 <entryRelationship typeCode="COMP">   <act classCode="ACT" moodCode="INT">     <templateId root="1.2.40.0.34.11.8.1.3.4"/>    <code code="EINZEL" displayName="Einzelverordnung" codeSystem="1.2.40.0.10.1.4.3.4.3.6" codeSystemName="MedikationTherapieArt"/>  </act></entryRelationship> 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 Code Element mit Werten aus dem vorgegeben ValueSet um zwischen Einzelverordnungen und Nicht-Einzelverordnungen wie Dauermedikation unterscheiden zu können.   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.30 ELGA_MedikationTherapieArt (DYNAMIC) hl7:originalText ED 0 … 1 Textinhalt, der codiert wurde. Gemäß Vorgaben im „Allgemeinen Implementierungsleitfaden“, Kapitel „Codierungs-Elemente“. 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-10, 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-10 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 - ICD-10 BMASGK   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 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 <value xsi:type="CD" nullFlavor="NA">   <originalText>     <reference value="#diag4_diagNotCoded"/>  </originalText></value> 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:target​Site​Code 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 @context​Conduction​Ind 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 @context​Conduction​Ind 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 @context​Conduction​Ind 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 @context​Conduction​Ind 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 @context​Conduction​Ind 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	MedikationAbgabeEntryemedv3	Bezeichnung	Medikation Abgabe Entry eMedikation v3
Klassifikation	CDA Entry Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt	Benutzt 8 Templates Benutzt als Name Version 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
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 0 … 1 C ID des MedikationAbgabe-Entry. wo [1] @root uid 1 … 1 R Wurzel OID der ID eines MedikationAbgabe-Entry gemäß Projekt e-Medikation @extension st 1 … 1 R AbgabeID = {eMedID}_{lokal vergebene ID}   Constraint Für e-Medikation: ID eines MedikationAbgabe-Entry gemäß Projekt 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 Befundklassen 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 <id root="1.2.40.0.10.1.4.3.4.2.3" extension="2b4x6qA2p40La53i4dyt_081511" ssigningAuthorityName="Apothekexyz"/> hl7:id II 0 … 1 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äß Projekt e-Medikation @extension st 1 … 1 R AbgabeID = {eMedID}_{lokal vergebene ID}   Constraint Für e-Medikation: Das zweite ID Element enthält die ID des ursprünglich im Abgabe-Dokument angegebenen Abgabe-Entry, welcher der Ausgangspunkt des vorliegenden Abgabe-Entry darstellt. Konditionale Konformität Abgabe-Entry liegt in Medikationsliste oder Pharmazeutischen Empfehlung vor: Card 1..1 Conf M Abgabe-Entry in einer Abgabe: NP   Beispiel <id root="1.2.40.0.10.1.4.3.4.2.3" extension="2b4x6qA2p40La53i4dyt_081511" assigningAuthorityName="Ordination Dr. Meier"/> 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 <code code="FFC" displayName="First Fill - Complete" codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7:ActCode"/> hl7:originalText ED 0 … 1 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:reference TEL 1 … 1 M 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 <text>   <reference value="#apos-1"/></text> 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:manufactured​Material/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   Beispiel Strukturbeispiel <!-- Abgegebene Arznei --> <product>   <!-- ELGA Arznei Element (1.2.40.0.34.6.0.11.3.186) -->   <manufacturedProduct classCode="MANU">     <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>    <!-- IHE PCC -->     <templateId root="2.16.840.1.113883.10.20.1.53"/>    <!-- HL7 CCD -->     <manufacturedMaterial classCode="MMAT" determinerCode="KIND">       <!-- ELGA Arznei-Entry -->       <templateId root="1.2.40.0.34.6.0.11.3.186"/>      <!-- ELGA -->        :     </manufacturedMaterial>  </manufacturedProduct></product> 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:assigned​Person 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 @determiner​Code 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:represented​Organization 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 @determiner​Code 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 <author nullFlavor="NA">   <time nullFlavor="NA"/>  <assignedAuthor nullFlavor="NA">     <id nullFlavor="NA"/>  </assignedAuthor></author>   Beispiel Verfasser einer Abgabe (2. Author-Element) <author>   <functionCode code="P" displayName="Pharmazeut" codeSystem="1.2.40.0.34.99.111.2.1" codeSystemName="Heilsapotheke Funktionscodes"/>  <time value="20130327082015+0100"/>  <assignedAuthor>     <id root="1.2.40.0.34.99.111.1.4" extension="1111" assigningAuthorityName="Heilsapotheke"/>    <telecom use="WP" value="tel:+43.6138.3453446.1111"/>    <assignedPerson>       <!-- .. -->     </assignedPerson>    <representedOrganization>       <!-- .. -->     </representedOrganization>  </assignedAuthor></author> 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 @context​Control​Code 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 <assignedAuthor classCode="ASSIGNED">   <id extension="ied8984938" root="1.2.276.0.76.3.1.139.933"/>  <assignedPerson classCode="PSN" determinerCode="INSTANCE">     <!-- ... -->   </assignedPerson></assignedAuthor> 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:assigned​Person hl7:assigned​Authoring​Device hl7:assigned​Person  … 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 @determiner​Code 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:assigned​Authoring​Device  … 1 @classCode cs 0 … 1 F DEV @determiner​Code cs 0 … 1 F INSTANCE hl7:manufacturer​Model​Name SC 0 … 1 Hersteller und Modellbezeichnung des datenerstellenden Gerätes. hl7:softwareName SC 0 … 1 Bezeichnung (und ggf Version) der datenerstellenden Software. hl7:represented​Organization 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 @determiner​Code 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 <author nullFlavor="NA">   <time nullFlavor="NA"/>  <assignedAuthor nullFlavor="NA">     <id nullFlavor="NA"/>  </assignedAuthor></author> 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 <!-- Verordnung dieser Abgabe (falls vorhanden) --> <entryRelationship typeCode="REFR">   <!-- ELGA MedikationVerordnung-Entry -->   <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äß Projekt 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 (IHEActCode Vocabulary) 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 Verifikation, eine Überprüfung ob das Medikament wirkt wie für diese Behandlung geplant, mit "veri" im code Element bzw. mit "#veri-{generierteID}" im reference Element gesetzt ist, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime Element gesetzt 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 (IHEActCode Vocabulary) 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 (IHEActCode Vocabulary) 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 Verifikation, eine Überprüfung ob das Medikament wirkt wie für diese Behandlung geplant, mit "veri" im code Element bzw. mit "#veri-{generierteID}" im reference Element gesetzt ist, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime Element gesetzt 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 (IHEActCode Vocabulary) 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 <entryRelationship typeCode="COMP">   <act classCode="ACT" moodCode="INT">     <templateId root="1.2.40.0.34.11.8.1.3.4"/>    <code code="EINZEL" displayName="Einzelverordnung" codeSystem="1.2.40.0.10.1.4.3.4.3.6" codeSystemName="MedikationTherapieArt"/>  </act></entryRelationship> 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 Code Element mit Werten aus dem vorgegeben ValueSet um zwischen Einzelverordnungen und Nicht-Einzelverordnungen wie Dauermedikation unterscheiden zu können.   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.30 ELGA_MedikationTherapieArt (DYNAMIC) hl7:originalText ED 0 … 1 Textinhalt, der codiert wurde. Gemäß Vorgaben im „Allgemeinen Implementierungsleitfaden“, Kapitel „Codierungs-Elemente“. 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 <reference typeCode="XCRPT">   <externalDocument>     <id root="1.2.40.0.10.1.4.3.4.2.1" extension="C8688SC242CY"/>  </externalDocument></reference> 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	MedikationPharmazeutischeEmpfehlungEntryV3	Bezeichnung	Medikation Pharmazeutische Empfehlung Entry eMedikation v3
Klassifikation	CDA Entry Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt	Benutzt 2 Templates Benutzt als Name Version 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
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 <id root="1.2.40.0.10.1.4.3.4.2.4" extension="2b4x6qA2p40La53i4dyt_aaa11" ssigningAuthorityName="Ordination Dr. Meier"/> 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.71 ELGA_MedikationPharmazeutischeEmpfehlungStatus (DYNAMIC)   Beispiel Änderung der Verordnung/Abgabe <code code="CHANGE" displayName="Änderung" codeSystem="1.3.6.1.4.1.19376.1.9.2.1" codeSystemName="IHE Pharmaceutical Advice Status List"/>   Beispiel Änderung der Verordnung/Abgabe mit Details <code code="CHANGE" displayName="Änderung" codeSystem="1.3.6.1.4.1.19376.1.9.2.1" codeSystemName="IHE Pharmaceutical Advice Status List">   <translation code="281647001" displayName="Adverse Reaction" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/></code>   Beispiel Absetzen der Verordnung/Abgabe <code code="CANCEL" displayName="Absetzen" codeSystem="1.3.6.1.4.1.19376.1.9.2.1" codeSystemName="IHE Pharmaceutical Advice Status List"/>   Beispiel Absetzen der Verordnung/Abgabe mit Details <code code="CANCEL" displayName="Absetzen" codeSystem="1.3.6.1.4.1.19376.1.9.2.1" codeSystemName="IHE Pharmaceutical Advice Status List">   <translation code="281647001" displayName="Adverse Reaction" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/></code> hl7:originalText ED 0 … 1 Textinhalt, der codiert wurde, gemäß Vorgaben im „Allgemeinen Implementierungsleitfaden“, Kapitel „Codierungs-Elemente“. 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.10.213 ala_AdministrativeVermerkeDringlichkeit_VS (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 <text>   <reference value="#pepos-1"/></text> 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 <statusCode code="completed"/> 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) Alle Felder außer das Arzneimittel oder die Menge dürfen sich von der originalen Verordnung unterscheiden! 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äß Projekt e-Medikation: Das erste ID Element enthält eine von Zentralkomponenten 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 Befundklassen 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 <id root="1.2.40.0.10.1.4.3.4.2.2" extension="WYE82A2G8EEW_4711" assigningAuthorityName="Ordination Dr. Muster"/>   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: Das zweite ID Element enthält die ID des ursprünglich im Rezept-Dokument angegebenen Verordnungs-Entry, welcher der Ausgangspunkt des vorliegenden Verordnungs-Entry darstellt. Konditionale Konformität Verordnungs-Entry liegt in Medikationsliste oder Pharmazeutischen Empfehlung vor: Card 1..1 Conf M Verordnungs-Entry in einem Rezept: NP 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 <text>   <reference value="#vpos-1"/></text> 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>   <!-- Einnahme von 27.05.2011, Ende unbekannt -->   <cda:effectiveTime xsi:type="IVL_TS">     <cda:low value="20110527000000+0200"/>    <cda:high nullFlavor="UNK"/>  </cda:effectiveTime></cda:ClinicalDocument>   Beispiel Strukturbeispiel <cda:ClinicalDocument>   <!-- Einnahmestart unbekannt, Dauer 2 Wochen lang -->   <cda:effectiveTime xsi:type="IVL_TS">     <cda:width value="2" unit="wk"/>  </cda:effectiveTime></cda:ClinicalDocument>   Beispiel Strukturbeispiel <cda:ClinicalDocument>   <!-- Dosierungsinformationen sind angegeben, aber Einnahmedauer unbekannt -->   <cda:effectiveTime xsi:type="IVL_TS">     <cda:low nullFlavor="UNK"/>    <cda:high nullFlavor="UNK"/>  </cda:effectiveTime></cda:ClinicalDocument> Auswahl 0 … 1 Elemente in der Auswahl: hl7:effectiveTime[1][hl7:low] hl7:effectiveTime[1][hl7:width] hl7:effectiveTime[1][@nullFlavor] hl7:effectiveTime IVL_TS 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 Dauer der Einnahme, wenn Einnahmestart unbekannt wo [1] [hl7:width] hl7:width PQ 1 … 1 R 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 wo [1] [@nullFlavor] @nullFlavor cs 1 … 1 F NA   Constraint Konditionale Konformität Card Conf Prädikat 1..1 M Es wird in einer Verordnung (1.2.40.0.34.11.8.1.3.1) die Dosierungsvariante "Split" mit templateId 1.3.6.1.4.1.19376.1.5.3.1.4.9 verwendet wird. 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: MSKWird 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 <repeatNumber value="0"/> 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 <routeCode code="100000073633" displayName="Subkutane Anwendung" codeSystem="1.2.40.0.10.1.4.3.4.3.4" codeSystemName="ELGA_MedikationArtAnwendung"/>   Beispiel eHDSI ePrescription/eDispensation <routeCode code="20066000" displayName="Subcutaneous use" codeSystem="0.4.0.127.0.16.1.1.2.1" codeSystemName="EDQM"/> 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 <consumable typeCode="CSM">   <!-- ELGA Arznei Element (1.2.40.0.34.6.0.11.3.186) -->   <manufacturedProduct classCode="MANU">     <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>    <!-- IHE PCC -->     <templateId root="2.16.840.1.113883.10.20.1.53"/>    <!-- HL7 CCD -->     <manufacturedMaterial classCode="MMAT" determinerCode="KIND">       <!-- ELGA Arznei-Entry -->       <templateId root="1.2.40.0.34.6.0.11.3.186"/>      <!-- ELGA -->        :     </manufacturedMaterial>  </manufacturedProduct></consumable> Eingefügt 0 … 1 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 0 … 1 C Verfasser des Dokuments. @typeCode cs 0 … 1 F AUT @context​Control​Code 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 epSOSHealthcareProfessionalRoles (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 („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. 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:assigned​Person 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:represented​Organization 1 … 1 M Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat. ↔ Hinweis zum XDS-Mapping: Da manche offiziellen Bezeichnungen von GDA sehr lang werden können, SOLL das name Element 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.7 Organization Compilation with id, name, tel, addr (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 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.11.30046 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:manufactured​Material 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.11.30047 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:manufactured​Material 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 <entryRelationship typeCode="COMP">   <supply classCode="SPLY" moodCode="RQO">     <independentInd value="false"/>    <quantity value="1"/>  </supply></entryRelationship> 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 <supply classCode="SPLY" moodCode="RQO">   <independentInd value="false"/>  <quantity value="1"/></supply> 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:manufactured​Material/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 (IHEActCode Vocabulary) 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 Verifikation, eine Überprüfung ob das Medikament wirkt wie für diese Behandlung geplant, mit "veri" im code Element bzw. mit "#veri-{generierteID}" im reference Element gesetzt ist, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime Element gesetzt werden. hl7:entryRelationship 0 … 1 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 (IHEActCode Vocabulary) 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 <entryRelationship typeCode="COMP">   <act classCode="ACT" moodCode="INT">     <templateId root="1.2.40.0.34.11.8.1.3.4"/>    <code code="EINZEL" displayName="Einzelverordnung" codeSystem="1.2.40.0.10.1.4.3.4.3.6" codeSystemName="MedikationTherapieArt"/>  </act></entryRelationship> 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 Code Element mit Werten aus dem vorgegeben ValueSet um zwischen Einzelverordnungen und Nicht-Einzelverordnungen wie Dauermedikation unterscheiden zu können.   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.30 ELGA_MedikationTherapieArt (DYNAMIC) hl7:originalText ED 0 … 1 Textinhalt, der codiert wurde. Gemäß Vorgaben im „Allgemeinen Implementierungsleitfaden“, Kapitel „Codierungs-Elemente“. 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-10, 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-10 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 - ICD-10 BMASGK   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 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 <value xsi:type="CD" nullFlavor="NA">   <originalText>     <reference value="#diag4_diagNotCoded"/>  </originalText></value> 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:target​Site​Code 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 @context​Conduction​Ind 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 @context​Conduction​Ind 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 @context​Conduction​Ind 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 @context​Conduction​Ind 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 @context​Conduction​Ind 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) Alle Felder außer das Arzneimittel oder die Menge dürfen sich von der originalen Verordnung unterscheiden! 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 0 … 1 C ID des MedikationAbgabe-Entry. wo [1] @root uid 1 … 1 R Wurzel OID der ID eines MedikationAbgabe-Entry gemäß Projekt e-Medikation @extension st 1 … 1 R AbgabeID = {eMedID}_{lokal vergebene ID}   Constraint Für e-Medikation: ID eines MedikationAbgabe-Entry gemäß Projekt 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 Befundklassen 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 <id root="1.2.40.0.10.1.4.3.4.2.3" extension="2b4x6qA2p40La53i4dyt_081511" ssigningAuthorityName="Apothekexyz"/> hl7:id II 0 … 1 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äß Projekt e-Medikation @extension st 1 … 1 R AbgabeID = {eMedID}_{lokal vergebene ID}   Constraint Für e-Medikation: Das zweite ID Element enthält die ID des ursprünglich im Abgabe-Dokument angegebenen Abgabe-Entry, welcher der Ausgangspunkt des vorliegenden Abgabe-Entry darstellt. Konditionale Konformität Abgabe-Entry liegt in Medikationsliste oder Pharmazeutischen Empfehlung vor: Card 1..1 Conf M Abgabe-Entry in einer Abgabe: NP   Beispiel <id root="1.2.40.0.10.1.4.3.4.2.3" extension="2b4x6qA2p40La53i4dyt_081511" assigningAuthorityName="Ordination Dr. Meier"/> 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 <code code="FFC" displayName="First Fill - Complete" codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7:ActCode"/> hl7:originalText ED 0 … 1 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:reference TEL 1 … 1 M 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 <text>   <reference value="#apos-1"/></text> 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:manufactured​Material/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   Beispiel Strukturbeispiel <!-- Abgegebene Arznei --> <product>   <!-- ELGA Arznei Element (1.2.40.0.34.6.0.11.3.186) -->   <manufacturedProduct classCode="MANU">     <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>    <!-- IHE PCC -->     <templateId root="2.16.840.1.113883.10.20.1.53"/>    <!-- HL7 CCD -->     <manufacturedMaterial classCode="MMAT" determinerCode="KIND">       <!-- ELGA Arznei-Entry -->       <templateId root="1.2.40.0.34.6.0.11.3.186"/>      <!-- ELGA -->        :     </manufacturedMaterial>  </manufacturedProduct></product> 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:assigned​Person 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 @determiner​Code 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:represented​Organization 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 @determiner​Code 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 <author nullFlavor="NA">   <time nullFlavor="NA"/>  <assignedAuthor nullFlavor="NA">     <id nullFlavor="NA"/>  </assignedAuthor></author>   Beispiel Verfasser einer Abgabe (2. Author-Element) <author>   <functionCode code="P" displayName="Pharmazeut" codeSystem="1.2.40.0.34.99.111.2.1" codeSystemName="Heilsapotheke Funktionscodes"/>  <time value="20130327082015+0100"/>  <assignedAuthor>     <id root="1.2.40.0.34.99.111.1.4" extension="1111" assigningAuthorityName="Heilsapotheke"/>    <telecom use="WP" value="tel:+43.6138.3453446.1111"/>    <assignedPerson>       <!-- .. -->     </assignedPerson>    <representedOrganization>       <!-- .. -->     </representedOrganization>  </assignedAuthor></author> 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 @context​Control​Code 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 <assignedAuthor classCode="ASSIGNED">   <id extension="ied8984938" root="1.2.276.0.76.3.1.139.933"/>  <assignedPerson classCode="PSN" determinerCode="INSTANCE">     <!-- ... -->   </assignedPerson></assignedAuthor> 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:assigned​Person hl7:assigned​Authoring​Device hl7:assigned​Person  … 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 @determiner​Code 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:assigned​Authoring​Device  … 1 @classCode cs 0 … 1 F DEV @determiner​Code cs 0 … 1 F INSTANCE hl7:manufacturer​Model​Name SC 0 … 1 Hersteller und Modellbezeichnung des datenerstellenden Gerätes. hl7:softwareName SC 0 … 1 Bezeichnung (und ggf Version) der datenerstellenden Software. hl7:represented​Organization 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 @determiner​Code 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 <author nullFlavor="NA">   <time nullFlavor="NA"/>  <assignedAuthor nullFlavor="NA">     <id nullFlavor="NA"/>  </assignedAuthor></author> 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 <!-- Verordnung dieser Abgabe (falls vorhanden) --> <entryRelationship typeCode="REFR">   <!-- ELGA MedikationVerordnung-Entry -->   <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äß Projekt 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 (IHEActCode Vocabulary) 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 Verifikation, eine Überprüfung ob das Medikament wirkt wie für diese Behandlung geplant, mit "veri" im code Element bzw. mit "#veri-{generierteID}" im reference Element gesetzt ist, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime Element gesetzt 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 (IHEActCode Vocabulary) 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 (IHEActCode Vocabulary) 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 Verifikation, eine Überprüfung ob das Medikament wirkt wie für diese Behandlung geplant, mit "veri" im code Element bzw. mit "#veri-{generierteID}" im reference Element gesetzt ist, muss ein Zeitpunkt oder Zeitbereich für die Verifizierung in diesem effectiveTime Element gesetzt 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 (IHEActCode Vocabulary) 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 <entryRelationship typeCode="COMP">   <act classCode="ACT" moodCode="INT">     <templateId root="1.2.40.0.34.11.8.1.3.4"/>    <code code="EINZEL" displayName="Einzelverordnung" codeSystem="1.2.40.0.10.1.4.3.4.3.6" codeSystemName="MedikationTherapieArt"/>  </act></entryRelationship> 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 Code Element mit Werten aus dem vorgegeben ValueSet um zwischen Einzelverordnungen und Nicht-Einzelverordnungen wie Dauermedikation unterscheiden zu können.   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.30 ELGA_MedikationTherapieArt (DYNAMIC) hl7:originalText ED 0 … 1 Textinhalt, der codiert wurde. Gemäß Vorgaben im „Allgemeinen Implementierungsleitfaden“, Kapitel „Codierungs-Elemente“. 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 <reference typeCode="XCRPT">   <externalDocument>     <id root="1.2.40.0.10.1.4.3.4.2.1" extension="C8688SC242CY"/>  </externalDocument></reference> 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

8 Anhang

8.1 Tabellenverzeichnis

8.2 Einzelnachweise

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.