	Dieses Dokument gibt wieder: Implementierungsleitfaden e-Medikation (2.06.3), OID: n.n., Datum: 15. Juli 2021, Status: Entwurf. Die Teilmaterialien gehören der Kategorie elga-cdaem-2.06.2 an.

ELGA CDA
Implementierungsleitfäden

HL7 Implementation Guide for CDA^® R2:
e-Medikation

Zur Anwendung im österreichischen
Gesundheitswesen [1.2.40.0.34.7.8.6.2]

15. Juli 2021

2.06.3

Entwurf

Inhaltsverzeichnis

1 Informationen über dieses Dokument
2 Harmonisierung
3 Einleitung
4 Anwendungsfälle
5 Administrative Daten (CDA Header)
6 Fachlicher Inhalt (CDA Body)
7 Technische Konformitätsprüfung
8 Technische Konformitätsprüfung
9 Anhang
- 9.1 Referenzen
- 9.2 Revisionsliste

1 Informationen über dieses Dokument

1.1 Allgemeines

Ziel dieses Implementierungsleitfadens ist die Beschreibung von Struktur, Format und Standards von medizinischen Dokumenten der Elektronischen Gesundheitsakte "ELGA" gemäß Gesundheitstelematikgesetz 2012 (GTelG 2012), aber auch für medizinische Dokumente im österreichischen Gesundheitswesen.

Die Anwendung dieses Implementierungsleitfadens hat im Einklang mit der Rechtsordnung der Republik Österreich und insbesondere mit den relevanten Materiengesetzen (z.B. Ärztegesetz 1998, Apothekenbetriebsordnung 2005, Krankenanstalten- und Kuranstaltengesetz, Gesundheits- und Krankenpflegegesetz, Rezeptpflichtgesetz, Datenschutzgesetz 2000, Gesundheitstelematikgesetz 2012) 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.

1.2 Sprachliche Gleichbehandlung

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

1.3 Verbindlichkeit

Mit der ELGA-Verordnung 2015 (in der Fassung der ELGA-VO-Nov-2015) macht die Bundesministerin für Gesundheit und Frauen die Festlegungen für Inhalt, Struktur, Format und Codierung verbindlich, die in den Implementierungsleitfäden Entlassungsbrief Ärztlich, Entlassungsbrief Pflege, Pflegesituationsbericht, Laborbefunde, Befund bildgebender Diagnostik, e-Medikation sowie XDS Metadaten (jeweils in der Version 2.06) getroffen wurden. Die anzuwendende ELGA-Interoperabilitätsstufen ergeben sich aus §21 Abs.6 ELGA-VO. Die Leitfäden in ihrer jeweils aktuell gültigen Fassung sowie die aktualisierten Terminologien sind von der Gesundheitsministerin auf www.gesundheit.gv.at zu veröffentlichen. Der Zeitplan zur Bereitstellung der Dokumente für ELGA wird durch das Gesundheitstelematikgesetz 2012 (GTelG 2012) und darauf basierenden Durchführungsverordnungen durch die Bundesministerin für Gesundheit und Frauen vorgegeben.

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

Neue Hauptversionen der Implementierungsleitfäden KÖNNEN ab dem Tag ihrer Veröffentlichung durch die Bundesministerin für Gesundheit und Frauen (www.gesundheit.gv.at) verwendet werden, spätestens 18 Monate nach ihrer Veröffentlichung MÜSSEN sie verwendet werden. Andere Aktualisierungen (Nebenversionen) dürfen auch ohne Änderung dieser Verordnung unter www.gesundheit.gv.at veröffentlicht werden.

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

1.4 Zielgruppe

Anwender dieses Dokuments sind Softwareentwickler und Berater, die allgemein mit Implementierungen und Integrationen im Umfeld der ELGA, insbesondere der ELGA-Gesundheitsdaten, betraut sind. Eine weitere Zielgruppe sind alle an der Erstellung von CDA-Dokumenten beteiligten Personen, einschließlich der Endbenutzer der medizinischen Softwaresysteme und der Angehörigen von Gesundheitsberufen.

1.5 Hinweis auf verwendete Grundlagen

Der vorliegende Leitfaden wurde unter Verwendung der nachstehend beschriebenen Dokumente erstellt. Das Urheberrecht an allen genannten Dokumenten wird im vollen Umfang respektiert.

Dieser Standard beruht auf der Spezifikation "HL7 Clinical Document Architecture, Release 2.0", für die das Copyright © von Health Level Seven International gilt. HL7 Standards können über die HL7 Anwendergruppe Österreich (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.

Dieser Leitfaden beruht auf Inhalten des LOINC® (Logical Observation Identifiers Names and Codes, siehe http://loinc.org). Die LOINC-Codes, Tabellen, Panels und Formulare unterliegen dem Copyright © 1995-2014, Regenstrief Institute, Inc. und dem LOINC Committee, sie sind unentgeltlich erhältlich. Lizenzinformationen sind unter http://loinc.org/terms-of-use abrufbar. Weiters werden Inhalte des UCUM® verwendet, UCUM-Codes, Tabellen und UCUM Spezifikationen beruhen auf dem Copyright © 1998-2013 des Regenstrief Institute, Inc. und der Unified Codes for Units of Measures (UCUM) Organization. Lizenzinformationen sind unter http://unitsofmeasure.org/trac/wiki/TermsOfUse abrufbar.

1.6 Danksagung

Die ELGA GmbH weist auf das Dokument „Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2.0 für das deutsche Gesundheitswesen“ hin, welches vom Verband der Hersteller von IT-Lösungen für das Gesundheitswesen (VHitG) herausgegeben wurde. Einige Ausführungen in dem genannten Dokument wurden in das vorliegende Dokument übernommen. Das Urheberrecht an dem Dokument „Arztbrief auf Basis der HL7 Clinical Document Architecture Release 2.0 für das deutsche Gesundheitswesen“, wird im vollen Umfang respektiert.

1.7 Revisionsliste

Diese Version ist eine Nebenversion zur Hauptversion 2.06 und ersetzt diese. Die durchgeführten Änderungen ersehen Sie der Revisionsliste.

1.8 Weitere unterstützende Materialien

Gemeinsam mit diesem Leitfaden werden auf der Website der ELGA GmbH [1] weitere Dateien und Dokumente zur Unterstützung bereitgestellt: Beispieldokumente, zu verwendende Codes, Vorgaben zur Registrierung von CDA-Dokumenten, das Referenz-Stylesheet zur Darstellung von CDA-Dokumenten, Algorithmen zur Prüfung der Konformität von CDA-Dokumenten etc.

Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an cda@elga.gv.at[2] gesendet werden. Weitere Informationen finden Sie unter http://www.elga.gv.at/CDA.

1.9 Bedienungshinweise für die PDF-Version

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

1.10 Impressum

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

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

Abbildungen: © ELGA GmbH

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

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

2 Harmonisierung

Erarbeitung des Implementierungsleitfadens
Dieser Implementierungsleitfaden entstand im Projekt e-Medikation auf Basis diverser Konsultationen unter Einbeziehung von Vertretern aller Stakeholder. Da die medizinischen Inhalte bereits gesetzlich bzw. durch Verordnung des Bundesministers festgelegt sind, wurde keine Harmonisierungsgruppe eingesetzt. Darüber hinaus wurde dieser Implementierungs-leitfaden für die Abstimmung und Diskussion im Zuge der Entwicklung der Usability-Style-guides herangezogen und entsprechend weiterentwickelt.

Das Dokument durchlief eine öffentliche Kommentierungsphase und ein nationales Standardisierungsverfahren ("Ballot") durch die HL7 Anwendergruppe Österreich (HL7 Austria). Folgende Personen waren an der Erstellung des Leitfadens beteiligt:

Autoren
Kürzel	Organisation	Person¹
Herausgeber, Projektleiter, CDA Koordinator
SSA	ELGA GmbH	Stefan Sabutsch
Autor, Fachkoordinator
JBR	CodeWerk Software Services and Development GmbH	Jürgen Brandstätter

Organisation	Person¹
SVC	Michael Bauer
SVC	Michael Deimel
SVC	Michael Bauer
SVC	Tanja Krammer
SVC	Martin Asenbaum
ELGA GmbH	Alexander Kollmann
ELGA GmbH	Oliver Kuttin
ELGA GmbH	Carina Seerainer

Die Revisionierung des Leitfadens wird durch die ELGA GmbH koordiniert. Kontaktadresse: cda@elga.gv.at .

¹ Personen sind ohne Titel angegeben

3 Einleitung

3.1 Ausgangssituation

Die Elektronische Gesundheitsakte (ELGA) umfasst die relevanten multimedialen und gesundheitsbezogenen Daten und Informationen zu einer eindeutig identifizierten Person. Die Daten sind in einem oder mehreren computergestützten Informationssystemen gespeichert. Sie stehen allen berechtigten Personen entsprechend ihren Rollen und den datenschutzrechtlichen Bedingungen in einer bedarfsgerecht aufbereiteten elektronischen Form online zur Verfügung.

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

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“). Für den Austausch der Medikationsdaten wird der internationale Standard „Clinical Document Architecture, Release 2.0“ (CDA) von HL7 eingesetzt.

Der CDA-Standard wird für die Verwendung in der ELGA Anwendung e-Medikation im Detail ausspezifiziert, Vorgaben für einheitliche Dokumentation und Codierung der Information festgelegt und in implementierbaren Leitfäden veröffentlicht.

3.1.1 e-Medikation

Die e-Medikation ist als Service zu verstehen, welches im Zuge des Verordnungs-, des Abgabe-, bzw. des Verabreichungsprozesses Informationen zur Medikation eines Patienten zur Verfügung stellt. Zentrale Elemente sind dabei die Medikationsdatenbank, sowie deren Schnittstellen zu bestehender IT-Infrastruktur (wie Arztpraxissoftware, Apothekensoftware und Krankenhausinformationssysteme. Zur Vernetzung wird die ELGA-Infrastruktur genutzt.

Die e-Medikation stellt ausschließlich Informationen über in den letzten 365 Tagen erfolgte Verordnungen oder Abgaben zur Verfügung. Prüfungen auf potentielle Wechselwirkungen, Kontraindikationen, Über- oder Unterdosierungen, Reichweiten etc. erfolgen in Eigenverantwortung der ELGA Gesundheitsdiensteanbieter und sind nicht Gegenstand des Informationssystems „e-Medikation“.

3.2 Zweck

Das Ziel dieses Dokuments ist die Beschreibung der Struktur von e-Medikations-Dokumenten der Elektronischen Gesundheitsakte ELGA. Insbesondere behandelt das Dokument jegliche Strukturen, welche auf der Basis des Implementierungsleitfadens

„HL7 Implementation Guide for CDA® R2: Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente“ [OID Root 1.2.40.0.34.7.1]

speziell für die Dokumentenklassen²

Rezept
Abgabe
Medikationsliste³
Pharmazeutische Empfehlung (Korrekturmeldung)⁴

gültig sind. Die Beschreibung enthält Festlegungen, Einschränkungen und Bedingungen auf Grundlage von HL7 CDA-Elementen.

² Es handelt sich bei den „Dokumentenklassen“ der e-Medikation nicht um Dokumentenklassen im engeren Sinn (wie etwa Befunde), sondern um Arten von Nachrichten, die zwischen den IT-Systemen ausgetauscht werden. Diese Nachrichten haben die technische Form von CDA-Dokumenten, die entsprechend einer „Dokumentenklasse“ zugeordnet werden.
³Die „Medikationsliste“ ist ein automatisch generiertes Dokument, das alle relevanten Informationen aus „Verordnungen“, „Abgaben“ und „pharmazeutischen Empfehlungen“ zusammenfasst.
⁴Der Begriff „Pharmazeutische Empfehlung“ wird hier im Sinne des IHE Pharmacy Technical Frameworks verwendet und wird aus zur Beibehaltung der Konsistenz mit diesem Standard beibehalten. Die „Pharmazeutische Empfehlung“ kann als Korrekturmeldung verstanden werden und bezeichnet die Änderung einer Verordnung oder Abgabe - unabhängig von Rollen und tatsächlichen Berechtigungen.

3.3 Hierarchie der Implementierungsleitfäden

Der vorliegende Implementierungsleitfaden basiert auf der grundlegenden Implementierungsvorschrift für alle CDA Dokumente im österreichischen Gesundheitswesen.

Die CDA Dokumente der e-Medikation haben grundsätzlich den beiden aufeinander aufbauenden Implementierungsleitfäden zu folgen.

Abbildung 1: Zusammenspiel der Implementierungsleitfäden.

Die administrativen Daten im Dokumentheader und grundsätzliche Vorgaben für den medizinischen Inhalt werden vom „Allgemeinen Implementierungsleitfaden“ definiert. Der jeweilige „Spezielle Implementierungsleitfaden“ enthält die Vorgaben für die medizinischen Inhalte und ergänzt gegebenenfalls die Header-Vorgaben.

Für die Verwendung dieses Implementierungsleitfadens sind zusätzlich die Vorgaben aus
„HL7 Implementation Guide for CDA® R2: Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente“ OID Root [1.2.40.0.34.7.1]
in der Hauptversion 2 vorausgesetzt.

4 Anwendungsfälle

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, Hausapotheker⁵, Wahlarzt, Facharzt, etc.
- ArztpraxisassistentIn
Krankenanstalt
- In der e-Medikation erfolgt keine Unterscheidung in stationären und ambulanten Bereich. Die Umsetzung der Berechtigungen (z.B. darf nur ein Arzt eine Verordnung in e-Medikation speichern), obliegt der GDA-Software.
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 (z.B. Ombudsstelle oder Vollmachtnehmer, gesetzlicher Vertreter)

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/ Verordnung (PRESCRIPTION)
- OFFEN, EINGELÖST, STORNIERT, ABGELAUFEN, NICHT_ABGEGEBEN
Abgabe (DISPENSE)
- ABGEGEBEN, ABGESETZT, STORNIERT
Korrekturmeldung (Pharmazeutische Empfehlung, Pharmaceutical Advice)
- STORNIERT (deprecated)
Medikationsliste
- ERSETZT (deprecated)

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

4.1 eMED-ID-Assertion anfordern

4.1.1 Beschreibung

Für den Zugriff auf die e-Medikationsdokuments ist neben einem Patientenkontakt im ELGA-Berechtigungssystem auch die Verwendung einer eMED-ID-Assertion zulässig. Diese ermöglicht den Zugriff auf die zugehörigen Dokumente zur eMED-ID. Eine eMED-ID-Assertion wird immer für ein Rezept (Prescription-Dokument) ausgestellt und ermöglicht den Zugriff auf alle zu diesem Prescription-Dokument zugehörigen Dokumente und das Speichern einer zugehörigen Abgabe.

4.1.2 Vorbedingung

Alle Zugriffe auf die ELGA-Applikation e-Medikation erfolgen ausschließlich durch das ELGA-Berechtigungssystem. Es müssen somit alle Vorbedingungen des ELGA-Berechtigungssystem erfüllt sein um Funktionen der e-Medikation nutzen zu können. Keiner der in den Anwendungsfällen angeführten Akteure hat eine direkte Zugriffsmöglichkeit auf die e-Medikation. Der Zugriff passiert ausschließlich über das ELGA-Berechtigungssystem. Es gelten die Vorbedingungen des ELGA-Berechtigungssystem analog e-Befunde mit Ausnahme

der eingeschränkten Zugriffsmöglichkeit auf ein konkretes Rezept mit seinen Verordnungen per eMED-ID und
den Funktionen zum Anfordern der eMED-ID (GenerateDocumentId) und Anfordern der eMED-ID-Assertion (RequestSecurityToken).

Der Zugriff per eMED-ID-Assertion ist alternativ zum Zugriff mit einem Patientenkontakt im ELGA-Berechtigungssystem zu sehen. Beim Zugriff mit eMED-ID-Assertion ermöglicht die e-Medikation nur eine eingeschränkte Sicht auf die Daten des ELGA-Teilnehmers.

Die Transaktionen haben keinen direkten Bezug zu einem ELGA-Teilnehmer und können über das ELGA-Berechtigungssystem nur mit einer gültigen Assertion aufgerufen werden.

4.1.3 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Einrichtung der Pflege
Apotheke

4.1.4 Ablauf

Der Akteur möchte die Rezeptdaten (Prescription Dokument) ohne vorhandener Kontakbestätigung bzw. ohne Stecken der e-card mit einer eMED-ID abrufen und eine zugehörige Abgabe speichern. Dazu muss eine eMED-ID Assertion angefordert werden. Dazu wird die eMED-ID über das ELGA-Berechtigungssystem an die e-Medikation übermittelt. Diese validiert die eMED-ID und stellt nach positiver Prüfung eine Assertion aus. Diese ermöglicht den Zugriff auf die der eMED-ID zugeordneten Rezeptdaten innerhalb einer konfigurierbaren Gültigkeitsdauer (Default: 2 Stunden).

4.2 eMED-ID (Dokumenten-ID) anfordern

4.2.1 Beschreibung

Zur Speicherung eines e-Medikations-Dokuments muss als Dokumenten-ID eine eMED-ID verwendet werden. Diese ID wird von der e-Medikation generiert. eMED-IDs können auf Vorrat angefordert werden.

4.2.2 Vorbedingung

Siehe Vorbedingung im Anwendungsfall „eMED-ID-Assertion anfordern“.

4.2.3 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Einrichtung der Pflege
Apotheke

4.2.4 Ablauf

Der Akteur möchte ein e-Medikations-Dokument speichern und fordert dazu eine eMED-ID an.

Die eMED-ID kann als Data-Matrix-Code im JPG-Format und als Zeichenkette zur Verfügung gestellt werden.

Der Data-Matrix-Code beinhaltet zusätzliche Daten zum Rezept und ermöglicht eine Vereinfachung des Prozesses bei der Abgabe.

Beispiele (1. mit und 2. ohne Versicherungsnummer):

eMED^12^XST3KU892344^20131025^1234010170
eMED^11^XST3KU892344^20131025

Die erstellten e-Medikation-Dokumente werden zu der angeforderten eMED-ID gespeichert und sind in weiterer Folge über diese abrufbar.

4.3 Verordnung(en) mit Rezept anlegen

4.3.1 Allgemein

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.

Die Prüfungen der Arzneimittel z.B. auf potentielle Wechselwirkungen, Kontraindikationen, Dosierungen, etc. erfolgt in der Eigenverantwortung des Arztes und ist nicht Gegenstand der e-Medikation.

Eine Speicherung von Verordnungen ohne Zuordnung eines Rezeptes ist nicht gültig. Die Verordnung wird als geprüft angesehen, wenn die zugeordnete Verordnung in e-Medikation gespeichert ist.

4.3.2 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: Anfordern einer eMED-ID (Dokumenten-ID)

4.3.3 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Einrichtung der Pflege

4.3.4 Ablauf

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

Arzneimittel auswählen: Der Arzt wählt eine oder mehrere Arzneimittelspezialitäten aus einem Katalog („ASP-Liste“, die Liste der humanen Arzneispezialitäten gelistet nach PZN) aus, wobei Handelsname, Pharmazentralnummer (PZN) sowie andere Daten zur Beschreibung des Arzneimittels (Stärke, Darreichungsform, Packungsgröße, Zulassungsnummer etc.) automatisch aus einem Katalog⁶ mit allen ELGA-relevanten Arzneimittelspezialitäten übernommen werden können.
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, siehe ELGA Usability-Styleguide & Situatives Opt-Out [2],[3],[4])
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 Papierrezept aufgedruckt werden (§18 Abs. 4 Z. 4 GTelG 2012) um die Versorgungskontinuität (verbesserte Arbeitsabläufe) als auch die anwenderfreundliche Umsetzung der e-Medikation zu unterstützen. Wird die eMED-ID nicht aufgedruckt, ist die Usability in den Apotheken stark eingeschränkt, da immer die e-card für den Zugriff auf die e-Medikation gesteckt werden muss. Darüber hinaus ist die Prüfhoheit für Verordnungen, die bei ÄrztInnen liegt, aufgelöst, da der Apotheker die e-card stecken muss, und bei jeder Abgabe die vollständige Medikationsliste zur Prüfung vorgelegt bekommt. Folglich kann eine Abgabe nicht in der eMedikation registriert werden, falls ein Patient das Rezept nicht persönlich einlösen kann (z.B. weil er bettlägrig ist), denn die e-card darf nicht weitergegeben werden.

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.

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; eine Einlösung möglich;
Privatrezept - 1 Monat gültig
- Das 1 Monat bezieht sich auf die erste Einlösung. Der Akteur kann eine erweiterte Gültigkeitsdauer mit maximal einem Jahr festlegen.
- bis zu 365 Tage bzw. 6 Einlösungen, sofern nicht durch den Arzt eine verringerte Gültigkeitsdauer oder Einlösungsanzahl vermerkt wurde. Dabei muss das Privatrezept innerhalb des ersten Monats erstmalig eingelöst werden (§ 4 Abs. 1 RezeptpflichtG).
Substitutionsrezept – Angabe eines „von Datums“ und „bis Datums“

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, gibt an wie viele Einlösungen auf ein Rezept durchgeführt werden dürfen bis die Verordnung auf dem Rezept und das Rezept den Status=EINGELÖST erhält. Anzahl der Einlösungen bezieht sich immer auf ein Rezept. Solange die Anzahl der Einlösungen (Abgaben) nicht erreicht wurde, haben die Verordnung und Rezept den Status=OFFEN.
Die Rezeptart ist für die Regeln der Einlösung notwendig. Siehe dazu Use Case “Medikationsabgabe über Verordnung einlösen“ und „Medikationsabgabe mit eMED-ID“

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

⁶ 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://termpub.gesundheit.gv.at/.

4.3.4.1 Ergebnis im Gutfall

Die am Rezept angegebenen Verordnungen sind im Status OFFEN in e-Medikation gespeichert. Die eMED-ID wurde vergeben (und ist am Rezept aufgedruckt).

4.3.4.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Information über den Fehler.
Hinweis: Die Ausstellung eines Papierrezeptes darf durch eine etwaiges „Nicht-funktionieren“ der e-Medikation nicht verhindert werden.

4.4 Rezept mit Verordnung(en) abrufen

4.4.1 Beschreibung

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 Vorbedingung

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

Alternativ zu einem Patientenkontakt kann dieser Anwendungsfall auch mit einer eMED-ID-Assertion erfolgen.

e-Medikation Vorbedingung: Verordnungen vorhanden

4.4.3 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Apotheke
Einrichtung der Pflege

4.4.4 Ablauf

Der Akteur kann die Verordnungen des ELGA-Teilnehmers mit den folgenden Suchfunktionen abfragen:

Alle Verordnungen zu einer eMED-ID
Alle Verordnungen in einem bestimmten Zeitraum
Alle Verordnungen mit dem Status „OFFEN“ und „ABGELAUFEN“

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.

4.4.4.1 Ergebnis im Gutfall

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

4.4.4.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Information über den Fehler.

4.5 Verordnung/Rezept stornieren

4.5.1 Beschreibung

Der Akteur kann das Rezept oder die Verordnung stornieren. Es sind folgende Fälle möglich:

Eine einzelne Verordnung stornieren (über eine Korrekturmeldung; entspricht einer Pharmazeutischen Empfehlung). Dieser Fall ist für die Änderung des Rezeptes durch einen vom Aussteller unterschiedlichen Arzt vorgesehen. Die stornierte Verordnung kann weiterhin über die e-Medikation abgefragt, jedoch nicht mehr abgegeben werden
Ein ganzes Rezept stornieren (über ein Update der XDS-Metadaten oder alle Verordnungen über eine Korrekturmeldung stornieren). Dieser Fall ist für die Korrektur eines Irrtums durch den ausstellenden Arzt vorgesehen. Das stornierte Rezept ist in der e-Medikation nicht mehr verfügbar. Das Storno über ein Update der XDS-Metadaten entspricht dem Storno eines Dokumentes und ist deshalb technisch vom Storno einer Verordnung, welche ein Teil eines Rezepts (Dokuments) ist, zu unterscheiden.

4.5.2 Vorbedingung

ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer ist identifiziert, eine gültige Kontaktbestätigung/ Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
Vorbedingung Storno Rezept: Alle Verordnungen des Rezeptes sind im Status=OFFEN und keine Verordnung wurde durch eine Korrekturmeldung (=Pharmazeutischen Empfehlung) geändert. Nur innerhalb eines beschränkten Zeitraums (Defaultwert 2 Stunden) nach Erstellung des Rezepts durch den Ersteller selbst möglich.
Vorbedingung Storno Verordnung: Das Storno einer Verordnung via Korrekturmeldung (=Pharmazeutischen Empfehlung) ist möglich, wenn die Verordnung im Status=OFFEN ist. Dieses Storno ist durch jeden behandelnden Arzt möglich, auch wenn dieser nicht der Ersteller der Verordnung ist.

4.5.3 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Einrichtung der Pflege

4.5.4 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 bzw. storniert werden. Ein Storno via pharmazeutische Empfehlung kann von jedem Arzt (unabhängig ob er der Ersteller der Verordnung ist) vorgenommen werden.
- Da das Storno einer Verordnung über eine pharmazeutische Empfehlung getätigt wird und diese selbst wiederum ein Dokument ist, kann die pharmazeutische Empfehlung storniert werden (nur vom Ersteller innerhalb eines definierten Zeitraums) und somit die Verordnung wieder in den Status = OFFEN gesetzt werden. Das Storno eines Dokuments (z.B. von einem Rezept) kann aber nicht rückgängig gemacht 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, innerhalb eines beschränkten Zeitraums (Defaultwert 2 Stunden) durchgeführt werden.

Ein Storno des ganzen Rezepts (Dokuments) kann nicht mehr rückgängig gemacht werden

4.5.4.1 Ergebnis im Gutfall

Die Verordnung bzw. das Rezept erhalten den Status= STORNIERT.

4.5.4.2 Ergebnis im Fehlerfall

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

4.6 Verordnung/Rezept ändern

4.6.1 Beschreibung

Der Arzt ändert eine bereits in e-Medikation gespeicherte Verordnung. Die Änderung darf von jedem Arzt vorgenommen werden, unabhängig davon, ob der Arzt die Verordnung erstellt hat oder nicht.

4.6.2 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.6.3 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Einrichtung der Pflege

4.6.4 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
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 bleibt bei einer Änderung der Verordnung gleich.

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

Der Arzt kann folgende Datenfelder von Verordnungen eines Rezepts ändern:

Zusatzinformation (im narrativen Teil des CDA)
Alternative Einnahme
Dosierung
Frequenz (Einnahmedauer)
Therapieart

Rezeptart und Gültigkeitsdauer können nicht geändert werden.

4.6.4.1 Ergebnis im Gutfall

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

4.6.4.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. Der Akteur erhält eine Information über den Fehler.

4.7 Abgabe mittels eMED-ID durchführen

4.7.1 Beschreibung

Der ELGA Teilnehmer will ein Rezept einlösen und übergibt hierzu in der Apotheke das Rezept. Die Verordnungen am Rezept sind in e-Medikation gespeichert.

Um eine Vereinfachung des Prozessablaufes der Einlösung eines Rezepts in der Apotheke zu ermöglichen, kann über einen maschinenlesbaren Code (eMED-ID) das Rezept samt den zugeordneten Verordnungen ohne Übergabe der e-card abgerufen werden.

Es dürfen dem Apotheker bzw. hausapothekenführenden Arzt nur die dem Rezept zugeordneten Verordnungen angezeigt werden. Die Apotheke bzw. der hausapothekenführende Arzt kann eine Abgabe nur zu den abgerufenen Verordnungen in e-Medikation speichern.

4.7.2 Vorbedingung

ELGA-Vorbedingung: GDA ist autorisiert
e-Medikation Vorbedingung: Rezept mit aufgedruckter, lesbarer eMED-ID ist vorhanden

4.7.3 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Einrichtung der Pflege
Apotheke

4.7.4 Ablauf

Die Erfassung einer Abgabe stellt folgende Prozessschritte in der GDA-Software dar:

eMED-ID anfordern: Die Vergabe der eMED-ID erfolgt zentral durch die e-Medikation und kann über eine entsprechende Schnittstelle angefordert werden.
Rezept mit Verordnung über die eMED-ID abrufen
Abgabe mit der eMED-ID in e-Medikation speichern: Prüfung der Eingabedaten

Bei der automatischen Übernahme scannt der Apotheker bzw. hausapothekenführende Arzt den Datamatrixcode (eMED-ID) des Rezepts ein. Somit wird das Rezept identifiziert und die angeführten Verordnungen aus e-Medikation abgerufen.

Der Apotheker bzw. hausapothekenführende Arzt kann die Daten aus der Verordnung für die Speicherung der Abgabe übernehmen bzw. kann diese neu erfassen oder ändern.

Anmerkungen zur Fachlogik: Folgende Regeln werden durchgeführt:

Damit die Verordnung eingelöst werden kann (Verordnung zu einer Medikationsabgabe), muss die Verordnung 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 kann nur von einem Akteur eingelöst werden – somit müssen alle Verordnungen zu einem Rezept abgegeben werden. Verordnungen, die nicht abgegeben werden, erhalten den Status NICHT DISPENSIERT
Rezepte mit dem Status ABGELAUFEN können organisatorisch weiterhin eingelöst werden, zur Speicherung der Abgaben in e-Medikation ist dann jedoch die Identifikation der ELGA-TeilnehmerInnen mittels e-card erforderlich (die Einlösung über eMED-ID ist in diesem Fall nicht möglich, die Abgabe erfolgt im Sinne einer „Abgabe ohne Verordnung“).

4.7.4.1 Sonderfall

Austausch: Wird ein Arzneimittel verordnet, welches in der Apotheke nicht vorhanden ist, so kann im Rahmen der gesetzlichen Bestimmungen, der Apotheker bzw. hausapotheken-führender 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 trotzdem der Verordnung oder dem Rezept zuzuordnen, um die zugrunde liegende Verordnung einzulösen. Etwaige weitere nicht eingelöste Verordnungen eines Rezeptes können dann nicht mehr abgegeben werden, da sie in den Status „abgegeben“ gesetzt werden.

Die Zuordnung erfolgt durch die Übergabe der VerordnungsID in den Abgabedaten. Es wird nicht geprüft, ob das Arzneimittel in der Abgabe mit dem verordneten Arzneimittel übereinstimmt bzw. wirkungsgleich ist. Das Ergebnis der Rücksprache kann als „ergänzende Informationen zur Abgabe“ miterfasst werden.

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, ist die Abgabe mit der eMED-ID abrufbar.

Der Prozess einer „Teilabgabe“ eines Rezeptes kann mit obiger Logik des „Besorgers“ auch abgebildet werden.

4.7.4.2 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.7.4.3 Ergebnis im Schlechtfall

Der Akteur erhält eine Fehlermeldung.

4.8 Abgabe über e-card durchführen

4.8.1 Beschreibung

Der ELGA Teilnehmer will ein Rezept einlösen und übergibt hierzu die e-card und das Rezept. Die Verordnungen am Rezept sind in e-Medikation gespeichert.

Der Apotheker bzw. hausapothekenführende Arzt ruft die offenen Verordnungen des ELGA-Teilnehmers ab. Der Apotheker wählt die entsprechende(n) Verordnung(en) und erfasst die Medikationsabgabe.

4.8.2 Vorbedingung

ELGA-Vorbedingung: GDA ist autorisiert, ELGA Teilnehmer wurde mittels e-card identifiziert, eine gültige Kontaktbestätigung/ Berechtigung („Ticket“) wurde vom ELGA-Berechtigungssystem ausgestellt.
e-Medikation Vorbedingung: Verordnungen sind in e-Medikation gespeichert

4.8.3 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Einrichtung der Pflege
Apotheke

4.8.4 Ablauf

Es werden 3 Prozessschritte durchlaufen:

Die Erfassung einer Abgabe stellt folgende Prozessschritte in der GDA-Software dar:

eMED-ID anfordern: Die Vergabe der eMED-ID erfolgt durch die „e-Medikation“ und kann über eine entsprechende Schnittstelle angefordert werden.
Rezept mit Verordnung abrufen: Der Apotheker bzw. hausapothekenführende Arzt kann die Daten aus der Verordnung übernehmen bzw. kann er diese neu erfassen oder ändern.
Abgabe mit der eMED-ID in e-Medikation speichern: Prüfung der Eingabedaten. Das Übermitteln von mehreren Abgaben kann innerhalb einer Transaktion erfolgen, sofern sich alle Abgaben auf dasselbe Rezept beziehen. Bei der Abgabe eines Kassenrezeptes ist es erforderlich alle Abgaben innerhalb einer Transaktion zu speichern, wird eine Verordnung nicht abgegeben so muss als Leerabgabe übermittelt werden.

Das Einlösen eines Rezepts nach Ablauf der Gültigkeit wird durch e-Medikation nicht verhindert. Die Abgabe wird in diesem Fall ohne Verordnungsbezug in e-Medikation gespeichert.

Anmerkung zur Fachlogik:
Die Abgabe mittels e-card unterliegt den folgenden Regeln:

Damit die Verordnung eingelöst werden kann (Verordnung zu einer Medikationsabgabe) muss die Verordnung 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 abgebgeben werden, müssen als „Nichtabgabe“ dokumentiert werden und erhalten demnach den Status=NICHT DISPENSIERT. Der Apotheker kann in einem Freitextfeld Anmerkungen zur Nichtabgabe erfassen.

4.8.4.1 Sonderfall

Austausch: siehe Anwendungsfall „Abgabe mittels eMED-ID durchführen“
Besorger: siehe Anwendungsfall „Abgabe mittels eMED-ID durchführen“
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 AGES Liste als wechselwirkungsrelevanten Arzneispezialitäten geführt ist.
- Erfolgt die Abgabe eines OTC ohne Verordnung bzw. Verordnungsbezug, darf die Abgabe nur in e-Medikation gespeichert werden, wenn dieses OTC in der ASP-Liste als wechselwirkungsrelevante Arzneispezialität geführt ist

4.8.4.2 Ergebnis im Gutfall

Die Verordnung ist eingelöst und die Medikationsabgabe ist gespeichert. Die Verknüpfung von Verordnung und Abgabe ist vorhanden.

4.8.4.3 Ergebnis im Schlechtfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Fehlermeldung.

4.9 Abgabe ohne Verordnung durchführen

4.9.1 Beschreibung

Der Akteur speichert die abgegebenen Arzneimittel in e-Medikation, welche tatsächliche abgegeben werden. Dieser Prozess wird durchgeführt bei

Abgabe von nicht verordneten Arzneimitteln (Abgabe von OTC)
wenn ein Papierrezept vorhanden ist und keine Verordnung(en) in e-Medikation eingetragen wurde(n)
Abgabe eines Arztmusters
Nacherfassung von bereits abgegebenen Arzneimitteln

4.9.2 Vorbedingung

ELGA-Vorbedingung: ELGA Teilnehmer wurde mittels e-card identifiziert bzw. gültige Kontaktbestätigung von Akteur und ELGA Teilnehmer ist vorhanden.
e-Medikation Vorbedingung: keine

4.9.3 Akteure

Arzt im niedergelassenen Bereich
Apotheke
Krankenanstalt
Einrichtung der Pflege

4.9.4 Ablauf

Die Erfassung einer Abgabe stellt folgende Prozessschritte in der GDA-Software dar:

eMED-ID anfordern: Die Vergabe der eMED-ID erfolgt zentral durch die e-Medikation und kann über eine entsprechende Schnittstelle angefordert werden.
Abgabe mit der eMED-ID in e-Medikation speichern: Prüfung der Eingabedaten

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

Die Nacherfassung von bereits erfolgten Abgaben wird über „Einnahmestart“ und „Einnahmeende“ abgebildet. Einnahmestart und Einnahmeende können somit auch in der Vergangenheit liegen. Das Abgabedatum ist in diesem Fall das Erfassungsdatum.

Beispiele für Nacherfassungsgründe:

Arzneimittel im Ausland bezogen
Medikationsdaten aus der GDA-Software vor Start der e-Medikation

4.9.4.1 Ergebnis im Gutfall

Die Medikationsabgabe ist in e-Medikation gespeichert.

4.9.4.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Fehlermeldung.

4.10 Abgabe abrufen

4.10.1 Beschreibung

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

4.10.2 Vorbedingung

ELGA-Vorbedingung: ELGA Teilnehmer wurde mittels e-card identifiziert bzw. gültige Kontaktbestätigung von Akteur und ELGA Teilnehmer ist vorhanden.
e-Medikation Vorbedingung: Abgaben in den letzten 365 Tagen vorhanden

4.10.3 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Apotheke
Einrichtung der Pflege

4.10.4 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.10.4.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.10.4.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Fehlermeldung.

4.11 Abgabe stornieren

4.11.1 Beschreibung

Der Akteur kann die Abgabe stornieren (z.B., wenn versehentlich das „falsche“ Arzneimittel eingelesen wurde oder der ELGA Teilnehmer das Arzneimittel nicht bezahlen kann und daher nicht ausgehändigt bekommt). Das Stornieren der Abgabe ist zeitlich begrenzt⁷ und darf nur vom Ersteller der Abgabe durchgeführt werden.

⁷ Die derzeitige Regelung für den Zugriff sieht eine Begrenzung auf 2 Stunden vor.

4.11.2 Vorbedingung

ELGA-Vorbedingung: Akteur und ELGA Teilnehmer wurden identifiziert. Ein gültiges Berechtigungsticket wurde vom ELGA-Berechtigungssystem ausgestellt
e-Medikation Vorbedingung: Abgabe vorhanden, Status= ABGEGEBEN

4.11.3 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Einrichtung der Pflege
Apotheke

4.11.4 Ablauf

Der Akteur bestimmt die Medikationsabgabe, welche storniert werden soll. Das Stornieren der Abgabe ist zeitlich begrenzt auf 2 Stunden und kann nur vom Ersteller der Abgabe vorgenommen werden. Die Abgabe erhält den Status=STORNIERT und kann nicht mehr abgerufen werden. Handelt es sich bei der Abgabe um eine Medikation mit einem Verordnungsbezug, dann wechselt der Status der Verordnung auf „OFFEN“.

Bei Kassen- und Substitutionsrezepten ist die Stornierung einzelner Abgaben nicht möglich, da diese Rezepte immer als ganzes abgegeben werden müssen. Durch Storno einer einzelnen Abgabe, wäre die entsprechende Verordnung offen und die restlichen Verordnungen des Kassen- oder Substitutionsrezeptes abgegeben. Daher müssen bei diesen beiden Rezeptarten immer alle Abgaben gemeinsam storniert werden.

Handelt es sich bei der Abgabe um eine Medikation ohne Verordnungsbezug, dann wird die Abgabe aus den Medikationsabgaben des ELGA Teilnehmers storniert (Status = STORNIERT).

4.11.4.1 Ergebnis im Gutfall

Im Gutfall wird die Stornierung der Medikationsabgabe durchgeführt. Die Abgabe erhält den Status STORNIERT, die entsprechende Verordnung den Status OFFEN.

4.11.4.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Fehlermeldung.

4.12 Abgabe absetzen

4.12.1 Beschreibung

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. ELGA Teilnehmer verträgt ein abgegebenes Arzneimittel nicht) eingenommen. Ein Absetzen einer Medikationsabgabe kann von jedem Akteur (außer ELGA-Teilnehmer selbst) durchgeführt werden.

4.12.2 Vorbedingung

ELGA-Vorbedingung: Akteur und ELGA Teilnehmer wurden identifiziert. Ein gültiges Berechtigungsticket wurde vom ELGA-Berechtigungssystem ausgestellt
e-Medikation Vorbedingung: Abgabe vorhanden, Status= ABGEGEBEN

4.12.3 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Apotheke
Einrichtung der Pflege

4.12.4 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. Da es kein Aufsummieren der Medikationsabgaben gibt, müssen etwaige dazugehörige Medikationsabgaben explizit abgesetzt werden.

Das Datum der Absetzung wird beim Abruf der Medikationsabgaben zur Verfügung gestellt.

Solange eine Medikationsabgabe abgerufen werden kann, kann die Medikationsabgabe auch abgesetzt werden. Im Zuge einer Absetzung erfolgen keine weiteren Prüfungen.

Das Absetzten kann via Metadatenupdate der entsprechenden Pharmazeutischen Empfehlung wieder rückgängig gemacht werden.

4.12.4.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.12.4.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. . Der Akteur erhält eine Fehlermeldung. Der Status der Abgabe ist „ABGEGEBEN“.

4.13 Abgabe ändern

4.13.1 Beschreibung

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

4.13.2 Vorbedingung

ELGA-Vorbedingung: Akteur und ELGA Teilnehmer wurden identifiziert. Ein gültiges Berechtigungsticket wurde vom ELGA-Berechtigungssystem ausgestellt
e-Medikation Vorbedingung: Abgabe vorhanden, Status=ABGEGEBEN

4.13.3 Akteure

Arzt im niedergelassenen Bereich
Krankenanstalt
Apotheke
Einrichtung der Pflege

4.13.4 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
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.13.4.1 Ergebnis im Gutfall

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

4.13.4.2 Ergebnis im Fehlerfall

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

4.14 Medikationsliste abrufen

4.14.1 Beschreibung

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

ELGA-Vorbedingung: Akteur und ELGA Teilnehmer wurden identifiziert. Ein gültiges Berechtigungsticket wurde vom ELGA-Berechtigungssystem ausgestellt
e-Medikation Vorbedingung: keine

4.14.3 Akteure

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

4.14.4 Ablauf

Der Akteur kann die gesamte, konsolidierte Medikationsliste (sortierbare Zusammenfassung über Zulassungsnummer und Abgabe bzw. Verordnungsdatum) abrufen.

Die Medikationsliste wird beim Aufruf von der e-Medikation erstellt und enthält die aktuell gültigen Abgaben bzw. Verordnungen (z.B. bei einer Änderung wird nur die geänderte Dosierung angezeigt).

4.14.4.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.14.4.2 Ergebnis im Fehlerfall

Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Der Akteur erhält eine Information über den Fehler.

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

Andererseits fehlen aber dann die Zusatzinformationen, mit denen die Arznei-Entries in der Medikationsliste ergänzt werden (z.B. die Zulassungsnummer).

5 Administrative Daten (CDA Header)

Dieses Kapitel basiert auf dem entsprechenden Kapitel im „Allgemeinen Implementierungsleitfaden“ (Implementierungsleitfaden HL7 Implementation Guide for CDA® R2: Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente [OID Root 1.2.40.0.34.7.1]) und beschreibt die darüberhinausgehenden Spezifikationen zum Thema e-Medikation.

Zum Verständnis der Vorgaben (z.B. Schlüsselwörter, Optionalität wie „MUSS-Kriterien“ oder Kardinalität) sei auf das entsprechende Kapitel 4 im Allgemeinen Implementierungsleitfaden hingewiesen. Hier ein Auszug (die Großschreibung ist normativ):

MUSS bedeutet eine verpflichtend einzuhaltende Vorschrift (Gebot). Entspricht den Konformitätskriterien [R] und [M].
NICHT ERLAUBT formuliert ein verpflichtend einzuhaltendes Verbot. Entspricht dem Konformitätskriterium [NP].
SOLL oder EMPFOHLEN steht für eine pragmatische Empfehlung. Es ist gewünscht und empfohlen, dass die Anforderung umgesetzt wird, es kann aber Gründe geben, warum dies unterbleibt. Entspricht dem Konformitätskriterium [R2].
KANN oder OPTIONAL (engl. MAY, OPTIONAL) Die Umsetzung der Anforderung ist optional, sie kann auch ohne zwingenden Grund unterbleiben. Entspricht dem Konformitätskriterium [O].

5.1 Dokumentenstruktur

5.1.1 Elemente ohne spezielle Vorgaben

Folgende Elemente erfordern keine speziellen Vorgaben:

XML Metainformationen
Wurzelelement
Hoheitsbereich („realmCode“)
Dokumentformat („typeId“)
Erstellungsdatum des Dokuments („effectiveTime“)
Vertraulichkeitscode („confidentialityCode“)
Sprachcode des Dokuments („languageCode“)

Verweis auf den Allgemeinen Leitfaden:
Die Elemente erfordern keine speziellen Vorgaben. Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“.

Auszug aus dem Allgemeinen Implementierungsleitfaden

5.1.2 XML Metainformationen

5.1.2.1 Zeichencodierung

CDA-Dokumente MÜSSEN mit UTF-8 (8-Bit Universal Character Set Transformation Format, nach RFC 3629 / STD 63 (2003)) codiert werden.

<?xml version="1.0" encoding="UTF-8" standalone=”yes”?>
<ClinicalDocument xmlns="urn:hl7-org:v3">
:

5.1.2.2 Hinterlegung eines Stylesheets

Um ein CDA-Dokument in einem Webbrowser anzeigen zu können, muss es nach HTML tranformiert werden. Das kann durch eine XSLT-Transformation (ein so genanntes „Stylesheet“) geschehen. Ist das Stylesheet im angegebenen Pfad erreichbar, wird dieses beim Öffnen des CDA-Dokuments mit einem Browser üblicherweise automatisch auf das CDA-Dokument angewandt und die Darstellung gerendert.

ELGA stellt zur einheitlichen Darstellung von CDA-Dokumenten ein „Referenz-Stylesheet“ zur Verfügung (Download ist von der ELGA Website http://www.elga.gv.at/cda möglich). Da der Zugriff auf XSLT-Programme von den meisten Browsern eingeschränkt ist, wird kein absoluter Pfad auf eine Webressource angegeben.

<?xml version="1.0" encoding="UTF-8" standalone=”yes”?>
<?xml-stylesheet type="text/xsl" href="ELGA_Stylesheet_v1.0.xsl"?>
<ClinicalDocument xmlns="urn:hl7-org:v3">
:

Das Stylesheet „ELGA_Stylesheet_v1.0.xsl“ MUSS angegeben werden [M]. Die Angabe eines Pfades ist NICHT ERLAUBT. Ausnahmen können für automatisiert erstellte Dokumente notwendig sein, diese müssen im allgemeinen und speziellen Leitfäden beschrieben werden.

5.1.3 Wurzelelement

Der XML-Namespace für CDA Release 2.0 Dokumente ist urn:hl7-org:v3 (Default-Namespace). Dieser MUSS in geeigneter Weise in jeder CDA XML Instanz genannt werden. In speziellen Leitfäden können weitere namespace-Präfixe angegeben werden.

Für ELGA CDA-Dokumente MUSS der Zeichensatz UTF-8 verwendet werden.

CDA-Dokumente beginnen mit dem Wurzelelement ClinicalDocument, der grobe Aufbau ist im folgenden Übersichtsbeispiel gegeben.

<ClinicalDocument xmlns="urn:hl7-org:v3">
   <!-- CDA Header -->
      … siehe Beschreibung CDA R2 Header …
   <!-- CDA Body -->
   <component>
      <structuredBody>
         … siehe Beschreibung CDA R2 Body …
      </structuredBody>
   </component>
</ClinicalDocument>

5.1.4 Hoheitsbereich des Dokuments („realmCode“)

Dieses Element kennzeichnet, dass das Dokument aus dem Hoheitsbereich Österreich (bzw. Bereich der HL7 Affiliate Austria, Code „AT“) stammt.

5.1.4.1 Strukturbeispiel

5.1.4.2 Spezifikation

Element/Attribut	DT	Kard	Konf	Beschreibung
realmCode	CS CNE	1..1	M	Hoheitsbereich des Dokuments Fester Wert: @code = AT (aus ValueSet „ELGA_RealmCode“)

5.1.5 Dokumentformat („typeId“)

Dieses Element kennzeichnet, dass das Dokument im Format CDA R2 vorliegt.

5.1.5.1 Strukturbeispiel

5.1.5.2 Spezifikation

Element/Attribut	DT	Kard	Konf	Beschreibung
typeId	II	1..1	M	Dokumentformat CDA R2 Feste Werte: @root = 2.16.840.1.113883.1.3' @extension = POCD_HD000040

5.1.6 Erstellungsdatum des Dokuments („effectiveTime“)

5.1.6.1 Spezifikation

Id

1.2.40.0.34.11.90008

ref

elgabbr-

Gültigkeit

2016‑07‑21

Andere Versionen mit dieser Id:

CDeffectiveTime vom 2013‑11‑07

Status

Aktiv

Versions-Label

Name

CDeffectiveTime

Bezeichnung

CD effectiveTime

Beschreibung

Mit Erstellungsdatum ist jenes Datum gemeint, welches normalerweise im Briefkopf eines Schriftstückes angegeben wird. (z.B.: Wien, am …). Das Erstellungsdatum dokumentiert den Zeitpunkt, an dem das Dokument inhaltlich fertiggestellt wurde.

Bemerkung: Das Erstellungsdatum des Dokuments muss nicht mit dem Datum der rechtli-chen Unterzeichnung (oder „Vidierung“) übereinstimmen.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-8	Erstellungsdatum	Datensatz

Beziehung

Version: Template 1.2.40.0.34.11.90008 CD effectiveTime (2016‑07‑21)

ref

elgabbr-

Beispiel

Nur Datum: Zeitpunkt als Datum (ohne Zeit) im Format YYYYMMDD

Beispiel

Datum, Zeit und Zeitzone: Zeitpunkt als Datum mit Zeit und Zeitzone im Format YYYYMMDDhhmmss[+/-]HHMM

Item

DT

Kard

Konf

Beschreibung

Label

hl7:effectiveTime

TS.AT.TZ

1 … 1

M

Erstellungsdatum des Dokuments.

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

(CDe...ime)


	elgagab-dataelement-8	Erstellungsdatum	Datensatz

5.1.7 Vertraulichkeitscode („confidentialityCode“)

5.1.7.1 Spezifikation

Id

1.2.40.0.34.11.90009

ref

elgabbr-

Gültigkeit

2013‑11‑07

Status

Aktiv

Versions-Label

Name

CDconfidentialityCode

Bezeichnung

CD confidentialityCode

Beschreibung

“Vertraulichkeitscode” (im CDA das Element ClinicalDocument/confidentialityCode) bezeichnet die Vertraulichkeitsstufe dieses Dokuments.

Der tatsächliche Zugriff auf das Dokument muss von der übergeordneten Infrastrukturschicht geregelt werden. Die Information des Vertraulichkeitscodes im Dokument selbst, dient nur der reinen Information und hat keine technischen Konsequenzen.

Da Dokumente nach der Vidierung weder technisch noch legistisch geändert werden dürfen, kann der Vertraulichkeitscode keine konkreten Zugriffsrechte auf das Dokument regeln, sondern nur auf „Metaebenen“, wie beispielsweise „geltendes Recht XY“ oder weiterführende Verwendungen über das IHE BPPC Profil, verweisen.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-266	Vertraulichkeitscode	Datensatz

Beziehung

Version: Template 1.2.40.0.34.11.90009 CD confidentialityCode (2013‑11‑07)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:confidentialityCode

CE

1 … 1

M

(CDc...ode)


	elgagab-dataelement-266	Vertraulichkeitscode	Datensatz

@code

CONF

1 … 1

F

N

@codeSystem

1 … 1

F

2.16.840.1.113883.5.25 (Confidentialty (HL7))

@displayName

1 … 1

F

normal

5.1.8 Sprachcode des Dokuments („languageCode“)

5.1.8.1 Spezifikation

Id

1.2.40.0.34.11.90010

ref

elgabbr-

Gültigkeit

2013‑11‑07

Status

Aktiv

Versions-Label

Name

CDlanguageCode

Bezeichnung

CD languageCode

Beschreibung

Die Sprache des Dokuments wird in diesem Attribut gemäß IETF (Internet Engineering Task Force), RFC 1766: Tags for the Identification of Languages nach ISO-639-1 (zweibuchstabige Codes für Sprachen, Kleinbuchstaben) und ISO 3166 (hier: zweibuchstabige Ländercodes, Großbuchstaben) festgelegt.

Das Format ist entsprechend ss-CC, mit ss, zwei Kleinbuchstaben für den Sprachencode gemäß ISO-639-1, und CC, zwei Großbuchstaben für den Ländercode gemäß ISO 3166 (Tabelle mit zwei Buchstaben).

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-265	Sprachcode	Datensatz

Beziehung

Version: Template 1.2.40.0.34.11.90010 CD languageCode (2013‑11‑07)

ref

elgabbr-

Beispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:languageCode

CS.LANG

1 … 1

M

Sprachcode des Dokuments.

(CDl...ode)


	elgagab-dataelement-265	Sprachcode	Datensatz

@code

CONF

1 … 1

F

de-AT

5.1.9 Elemente mit speziellen Vorgaben

5.1.9.1 ELGA Implementierungsleitfaden-Kennzeichnung („templateId“)

Mit Angabe dieses Elements wird ausgesagt, dass das vorliegende CDA-Dokument zu diesem Implementierungsleitfaden konform ist. Ein Dokument, welches dem vorliegenden Implementierungsleitfaden folgt, muss auch dem übergeordneten „Allgemeinen Implementierungsleitfaden“ folgen.

5.1.9.1.1 Spezielle Vorgaben für Dokumente der e-Medikation

Die templateId-Elemente für diesen Implementierungsleitfaden sind anzugeben.

5.1.9.1.2 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
   :
  <!-- ELGA CDA Dokumente -->
  <templateId root="1.2.40.0.34.11.1"/>


  <!-- ELGA CDA Rezept -->
  <templateId root="1.2.40.0.34.11.8.1"/>
     ... oder ...
  <!-- ELGA CDA Abgabe -->
  <templateId root="1.2.40.0.34.11.8.2"/>
     ... oder ...
  <!-- ELGA CDA Medikationsliste -->
  <templateId root="1.2.40.0.34.11.8.3"/>
     ... oder ...
  <!-- ELGA CDA Pharmazeutische Empfehlung -->
  <templateId root="1.2.40.0.34.11.8.4"/>


  <!-- EIS „Full support“ -->
  <templateId root="1.2.40.0.34.11.8.0.3"/>

</ClinicalDocument>

5.1.9.1.3 Spezifikation

Element/Attribut	DT	Kard	Konf	Beschreibung
templateId	II	1..1	M	ELGA TemplateId für den Allgemeinen Implementierungsleitfaden Fester Wert: @root = 1.2.40.0.34.11.1
---zusätzlich eine der folgenden templateIds---
Im Falle von Dokumentklasse „Rezept“
templateId	II	1..1	M	ELGA CDA Rezept Fester Wert @root = 1.2.40.0.34.11.8.1
templateId	II	1..1	M	IHE PHARM Prescription Fester Wert @root = 1.3.6.1.4.1.19376.1.9.1.1.1
---oder---
Im Falle von Dokumentklasse „Abgabe“
templateId	II	1..1	M	ELGA CDA Abgabe Fester Wert @root = 1.2.40.0.34.11.8.2
templateId	II	1..1	M	IHE PHARM Dispense Fester Wert @root = 1.3.6.1.4.1.19376.1.9.1.1.3
---oder---
Im Falle von Dokumentklasse „Medikationsliste“
templateId	II	1..1	M	ELGA CDA Medikationsliste Fester Wert @root = 1.2.40.0.34.11.8.3
templateId	II	1..1	M	IHE PHARM Medication List Fester Wert @root = 1.3.6.1.4.1.19376.1.9.1.1.5
---oder---
Im Falle von Dokumentklasse „Pharmazeutische Empfehlung“
templateId	II	1..1	M	ELGA CDA Pharmazeutische Empfehlung Fester Wert @root = 1.2.40.0.34.11.8.4
templateId	II	1..1	M	IHE PHARM Pharmaceutical Advice Fester Wert @root = 1.3.6.1.4.1.19376.1.9.1.1.2
templateId	II	1..1	M	IHE PCC Medical Documents Fester Wert @root = 1.3.6.1.4.1.19376.1.5.3.1.1.1
templateId	II	1..1	M	ELGA CDA Dokument in EIS „Full support“ Fester Wert @root = 1.2.40.0.34.11.8.0.3

5.1.9.2 Dokumenten-Id („id”)

5.1.9.2.1 Spezielle Vorgaben für Dokumente der e-Medikation

Die Dokumenten-Id MUSS eine eindeutige eMED-ID enthalten.

5.1.9.2.2 Strukturbeispiel

<id
   root="1.2.40.0.10.1.4.3.4.2.1"
   extension="WYE82A2G8EEW"
   assigningAuthorityName="e-MedAT"/>

5.1.9.2.3 Spezifikation

Element/Attribut		DT	Kard	Konf	Beschreibung
id		II	1..1	M	Dokumenten-ID
	@root	uid	1..1	M	OID der Liste der eMED-IDs Fester Wert: 1.2.40.0.10.1.4.3.4.2.1
	@extension	st	1..1	M	eMED-ID
	@assigningAuthorityName	st	0..1	O	Fester Wert: e-MedAT

5.1.9.3 Dokumentenklasse (“code”)

Alle Dokumente der e-Medikation sind mit den folgenden LOINC Codes codiert.

5.1.9.3.1 Spezielle Vorgaben für Rezept

Code-Element codiert mit LOINC Code: 57833-6, Prescription for medication

5.1.9.3.2 Spezielle Vorgaben für Abgabe

Code-Element codiert mit LOINC Code: 60593-1, Medication dispensed.extended Document

5.1.9.3.3 Spezielle Vorgaben für Medikationsliste

Code-Element codiert mit LOINC Code: 56445-0, Medication summary Document

5.1.9.3.4 Spezielle Vorgaben für Pharmazeutische Empfehlung

Code-Element codiert mit LOINC Code: 61356-2, Medication pharmaceutical advice.extended Document

5.1.9.3.5 Strukturbeispiel

<ClinicalDocument xmlns="urn:hl7-org:v3">
	:
   <code code="57833-6"
       displayName="Prescription for medication"
       codeSystem="2.16.840.1.113883.6.1"
       codeSystemName="LOINC" />
	:
</ClinicalDocument>

5.1.9.3.6 Spezifikation

Element/Attribut		DT	Kard	Konf	Beschreibung
code		CE CWE	1..1	M	Code des Dokuments
	@code	cs	1..1	M	Werte aus ELGA Value Set: ELGA_Dokumentenklassen Rezept:57833-6, Prescription for medication Abgabe:60593-1, Medication dispensed.extended Document Medikationsliste:56445-0, Medication summary Document Pharmazeutische Empfehlung:61356-2, Medication pharmaceutical advice.extended Document
	@displayName	st	1..1	M
	@codeSystem	uid	1..1	M	Fester Wert: 2.16.840.1.113883.6.1
	@codeSystemName	st	1..1	M	'LOINC

5.1.9.4 Titel des Dokuments („title“)

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.

5.1.9.4.1 Spezielle Vorgaben für Rezept

Angabe des Titels in folgender Form: „Rezept“

5.1.9.4.2 Spezielle Vorgaben für Abgabe

Angabe des Titels in folgender Form: „Abgabe“

5.1.9.4.3 Spezielle Vorgaben für Medikationsliste

Angabe des Titels in folgender Form: „Medikationsliste“

5.1.9.4.4 Spezielle Vorgaben für Pharmazeutische Empfehlung

Angabe des Titels in folgender Form: „Pharmazeutische Empfehlung“⁸

⁸ Obwohl es sich fachlich hierbei um eine Korrekturmeldung handelt, wird der im IHE Pharmacy Technical Framework übliche Begriff „Pharmazeutische Empfehlung“ zur Erhaltung der Konsistenz mit diesem Standard weiterverwendet

5.1.9.4.5 Strukturbeispiel

<title>Rezept</title>

5.1.9.4.6 Spezifikation

Element/Attribut		DT	Kard	Konf	Beschreibung
title		st	1..1	M	Dokumententitel Rezept: Rezept Abgabe: Abgabe Medikationsliste: Medikationsliste Pharmazeutische Empfehlung: Pharmazeutische Empfehlung

5.2 Teilnehmende Parteien

5.2.1 Übersicht

Element	Spezielle Vorgabe	Konf
Patient („recordTarget/patientRole“)	Keine	M
Verfasser des Dokuments („author“)	Keine	M
Verwahrer des Dokuments („custodian“)	Keine	M
Rechtlicher Unterzeichner („legalAuthenticator“)	Medikationsliste: Andere Dokumente:	NP M
Personen bei der Dateneingabe („dataEnterer“)	Nicht erlaubt	NP
Beabsichtigte Empfänger des Dokuments („informationRecipient“)	Nicht erlaubt	NP
Weitere Unterzeichner („authenticator“)	Nicht erlaubt	NP
Weitere Beteiligte („participants“)	Nicht erlaubt	NP

5.2.2 Elemente ohne spezielle Vorgaben

Folgende Elemente erfordern keine speziellen Vorgaben:

Patient („recordTarget/patientRole“)
Verfasser des Dokuments („author“)
Verwahrer des Dokuments („custodian“)

Verweis auf den Allgemeinen Leitfaden:
Die Elemente erfordern keine speziellen Vorgaben. Es gelten die Vorgaben der entsprechenden Kapitel des „Allgemeinen Implementierungsleitfadens“.

Auszug aus dem Allgemeinen Implementierungsleitfaden

5.2.3 Patient („recordTarget/patientRole“)

Im CDA-Header wird mindestes eine Patientenrolle beschrieben, die zu genau einer Person zugehörig ist. Die recordTarget Beziehung weist auf die Patient-Klasse und gibt an, zu welchem Patienten dieses Dokument gehört.

Auszug aus dem R-MIM:

Abbildung 7: Klassen rund um den Patienten.

5.2.3.1 Spezifikation

Id

1.2.40.0.34.11.20001

ref

elgabbr-

Gültigkeit

2017‑07‑20

Andere Versionen mit dieser Id:

HeaderRecordTarget vom 2018‑10‑18 14:23:51
HeaderRecordTarget vom 2017‑03‑27
HeaderRecordTarget vom 2013‑10‑08
HeaderRecordTarget vom 2013‑02‑10
HeaderRecordTarget vom 2011‑12‑19

Status

Entwurf

Versions-Label

Name

HeaderRecordTarget

Bezeichnung

HeaderRecordTarget

Beschreibung

Das RecordTarget-Element enthält den Patienten: Die Person, die von einem Gesundheitsdiensteanbieter (Arzt, einer Ärztin oder einem Angehörigen anderer Heilberufe) behandelt wird und über die bzw über deren Gesundheitsdaten im Dokument berichtet wird.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-9	Patient	Datensatz

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.90017	Inklusion	Language Communication	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.20001 HeaderRecordTarget (2017‑03‑27)

ref

elgabbr-

Beispiel

Vollständiges Beispiel

<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    
    <id root="1.2.40.0.34.99.111.1.2" extension="4711" assigningAuthorityName="Amadeus Spital"/>    
    <id root="1.2.40.0.10.1.4.3.1" extension="1111241261" assigningAuthorityName="Österreichische Sozialversicherung"/>    
    <addr use="H">
      <streetName>Musterstraße</streetName>      <houseNumber>13a</houseNumber>      <postalCode>7000</postalCode>      <city>Eisenstadt</city>      <state>Burgenland</state>      <country>AUT</country>    </addr>    
    <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>
        <prefix qualifier="AC">Dipl.Ing.</prefix>        <given>Herbert</given>        <given>Hannes</given>        <family>Mustermann</family>        <family qualifier="BR">VorDerHeirat</family>        <suffix qualifier="AC">BSc</suffix>        <suffix qualifier="AC">MBA</suffix>      </name>      
      <administrativeGenderCode code="M" displayName="Male" codeSystem="2.16.840.1.113883.5.1" codeSystemName="HL7:AdministrativeGender"/>      
      <birthTime value="19701224"/>      
      <maritalStatusCode code="D" displayName="Divorced" codeSystem="2.16.840.1.113883.5.2"/>      
      <religiousAffiliationCode code="101" displayName="Römisch-Katholisch" codeSystem="2.16.840.1.113883.2.16.1.4.1" codeSystemName="HL7.AT:ReligionAustria"/>      
      <guardian>
        
        <addr>
          <streetAddressLine>Kinderdorfstraße 1</streetAddressLine>          <postalCode>2371</postalCode>          <city>Hinterbrühl</city>          <state>Niederösterreich</state>          <country>AUT</country>        </addr>        
        <telecom use="H" value="tel:+43.2236.2928"/>        <telecom use="WP" value="tel:+43.2236.9000"/>        <guardianOrganization>
          
          <name>SOS Kinderdorf Hinterbrühl</name>        </guardianOrganization>      </guardian>      
      <guardian>
        
        <addr>
          <streetAddressLine>Musterstraße 1234</streetAddressLine>          <postalCode>8011</postalCode>          <city>Graz</city>          <state>Steiermark</state>          <country>AUT</country>        </addr>        
        <telecom use="MC" value="tel:+43.676.1234567"/>        <telecom use="H" value="tel:+43.316.717.653.9939"/>        <telecom use="WP" value="tel:+43.316.608.271.9000"/>        <guardianPerson>
          
          <name>
            <given>Susi</given>            <family>Sorgenvoll</family>          </name>        </guardianPerson>      </guardian>      
      <birthplace>
        <place>
          <addr>Graz</addr>        </place>      </birthplace>    </patient>  </patientRole></recordTarget>

Beispiel

Minimalbeispiel 1

<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    
    <id root="1.2.40.0.34.99.111.1.2" extension="4711"/>    
    <patient classCode="PSN" determinerCode="INSTANCE">
      <name>
        <given>Herbert</given>        <family>Mustermann</family>      </name>      
      <administrativeGenderCode code="M" codeSystem="2.16.840.1.113883.5.1"/>      
      <birthTime value="19701224"/>    </patient>  </patientRole></recordTarget>

Beispiel

Minimalbeispiel 2

<recordTarget>
  <patientRole>
    
    <id root="1.2.40.0.34.99.111.1.2" extension="4711"/>    
    <patient>
      <name>
        <given>Herbert</given>        <family>Mustermann</family>      </name>      
      <administrativeGenderCode nullFlavor="UNK"/>      
      <birthTime nullFlavor="UNK"/>    </patient>  </patientRole></recordTarget>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:recordTarget

Komponente für die Patientendaten.

(Hea...get)


	elgagab-dataelement-9	Patient	Datensatz

@typeCode

cs

0 … 1

F

RCT

@contextControlCode

cs

0 … 1

F

OP

Beispiel

hl7:patientRole

1 … 1

R

Patientendaten.

(Hea...get)

@classCode

cs

0 … 1

F

PAT

Beispiel

Schematron assert

role

error

test

string-length(hl7:id[1]/@root)>0

Meldung

patientRole id[1] MUSS als lokale Patienten ID vom System vorhanden sein

Schematron assert

role

error

test

hl7:id[2]/@root = '1.2.40.0.10.1.4.3.1' or hl7:id[2]/@nullFlavor='NI' or hl7:id[2]/@nullFlavor='UNK'

Meldung

patientRole id[2] MUSS Sozialversicherungsnummer des Patienten sein (1.2.40.0.10.1.4.3.1) oder @nullFlavor 'NI' oder 'UNK' ist angegeben

hl7:id

II

2 … *

R

id[1] Identifikation des Patienten im lokalen System.
id[2] Sozialversicherungsnummer des Patienten
Zugelassene nullFlavor:

NI … Patient hat keine Sozialversicherungsnummer (z.B. Ausländer, …)
UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt

id[3] Bereichsspezifisches Personenkennzeichen, Bereichskennzeichen GH (Gesundheit)

(Hea...get)

Beispiel

lokale Patienten ID vom System, notwendig für XDS

Beispiel

Patienten SV Nummer

Beispiel

bPK-GH des Patienten: Bereichskürzel + bPK (Base64,28 Zeichen)

hl7:addr

AD

0 … 1

Adresse des Patienten.

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

(Hea...get)

hl7:streetAddressLine

0 … 1

(Hea...get)

hl7:streetName

0 … 1

(Hea...get)

hl7:houseNumber

0 … 1

(Hea...get)

Schematron assert

role

error

test

hl7:streetAddressLine or (hl7:streetName and hl7:houseNumber)

Meldung

Granularitätsstufen Adresse beachten: streetAddressLine oder streetName+houseNumber

hl7:postalCode

1 … 1

M

(Hea...get)

hl7:city

1 … 1

M

(Hea...get)

hl7:state

0 … 1

C

(Hea...get)

hl7:country

1 … 1

M

(Hea...get)

hl7:additionalLocator

0 … 1

(Hea...get)

hl7:telecom

TEL.AT

0 … *

Kontaktdaten des Patienten.

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

(Hea...get)

hl7:patient

0 … 1

(Hea...get)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

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 für „Namen-Elemente von Personen PN“ zu befolgen.

(Hea...get)

hl7:prefix

0 … *

(Hea...get)

hl7:given

1 … *

M

(Hea...get)

hl7:family

1 … *

M

(Hea...get)

hl7:suffix

0 … *

(Hea...get)

hl7:administrativeGenderCode

CE

1 … 1

R

Codierung des Geschlechts des Patienten.

Zugelassene nullFlavor: UNK

(Hea...get)

CONF

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

hl7:birthTime

TS.DATE.MIN

1 … 1

R

Geburtsdatum des Patienten.

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

Zugelassene nullFlavor: UNK

(Hea...get)

hl7:maritalStatusCode

CE

0 … 1

Codierung des Familienstands des Patienten.

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.11 ELGA_MaritalStatus (DYNAMIC)

hl7:religiousAffiliationCode

CE

0 … 1

Codierung des Religionsbekenntnisses des Patienten.

(Hea...get)

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!

(Hea...get)

hl7:ethnicGroupCode

NP

Ethnische Zugehörigkeit des Patienten.
Darf nicht verwendet werden!

(Hea...get)

hl7:guardian

0 … *

Gesetzlicher Vertreter: Erwachsenenvertreter, Vormund, Obsorgeberechtigter

(Hea...get)

hl7:addr

AD

0 … 1

Die Adresse des gesetzlichen Vertreters oder der Organisation.

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

(Hea...get)

hl7:telecom

TEL.AT

0 … *

Beliebig viele Kontaktdatendes gesetzlichen Vertreters oder der Organisation.

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

(Hea...get)

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:guardianPerson
hl7:guardianOrganization

hl7:guardianPerson

… 1

Name des des gesetzlichen Vertreters (Person).

(Hea...get)

hl7:name

PN

1 … 1

M

Name der Person.

(Hea...get)

hl7:guardianOrganization

… 1

Name des des gesetzlichen Vertreters (Organisation).

(Hea...get)

hl7:name

ON

1 … 1

M

Name der Organisation.

(Hea...get)

hl7:birthplace

0 … 1

Geburtsort des Patienten.

(Hea...get)

hl7:place

1 … 1

M

(Hea...get)

hl7:addr

AD

1 … 1

M

Die Adresse des Geburtsorts.

Grundsätzlich sind die Vorgaben gemäß „Adress-Elemente“ für Granularitätsstufe 1 zu befolgen.

Granularitätsstufe 2 oder 3 ist auch bei EIS Enhanced und Full Support nicht erforderlich.

(Hea...get)

Eingefügt

von 1.2.40.0.34.11.90017 Language Communication (DYNAMIC)

hl7:languageCommunication

0 … *

Komponente zur Angabe der Sprachfähigkeiten des Patienten.

(Hea...get)

hl7:languageCode

CS

0 … 1

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

(Hea...get)

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

Ausdrucksform der Sprache.
@codeSystem Fester Wert: 2.16.840.1.113883.5.60

(Hea...get)

CONF

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

hl7:proficiencyLevelCode

CE

0 … 1

Grad der Sprachkenntnis in der Sprache.
@codeSystem Fester Wert: 2.16.840.1.113883.5.61

(Hea...get)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.40.0.34.10.174 ELGA_ProficiencyLevelCode (DYNAMIC)

hl7:preferenceInd

BL

0 … 1

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

(Hea...get)

5.2.3.1.1 id

Element/Attribut		DT	Kard	Konf	Beschreibung
id[1]		II	1..1	M	Identifikation des Patienten im lokalen System Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen.
id[2]		II	1..1	R	Sozialversicherungsnummer des Patienten Zugelassene nullFlavor: NI … Patient hat keine Sozialversicherungsnummer (z.B. Ausländer, …) UNK … Patient hat eine Sozialversicherungsnummer, diese ist jedoch unbekannt
	@root	uid	1..1	M	OID der Liste aller österreichischen Sozialversicherungen Fester Wert: 1.2.40.0.10.1.4.3.1
	@extension	st	1..1	M	Vollständige Sozialversicherungsnummer des Patienten (alle 10 Stellen)
	@assigningAuthorityName	st	0..1	O	Fester Wert: Österreichische Sozialversicherung
id[3]		II	0..1	O	Bereichsspezifisches Personenkennzeichen, Bereichskennzeichen GH (Gesundheit)
	@root	uid	1..1	M	OID der österreichischen bPK Fester Wert: 1.2.40.0.10.2.1.1.149
	@extension	st	1..1	M	bPK-GH des Patienten: Bereichskürzel + bPK (Base64, 28 Zeichen) (insg. 31 Stellen) Anmerkung: Das bPK dient ausschließlich der Zuordnung der elektronischen Identität und darf daher nicht am Ausdruck erscheinen
	@assigningAuthorityName	st	0..1	O	Fester Wert: Österreichische Stammzahlenregisterbehörde

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

5.2.3.1.2 addr

Es MUSS eine mögliche Adresse unterstützt werden. Spezielle Leitfäden (z.B. Entlassungsbrief Pflege) können es erforderlich machen, dass auch mehr als eine Adresse unterstützt werden muss.

5.2.3.1.3 patient/languageCommunication

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

5.2.3.1.4 patient/guardian

In der Klasse guardian können Informationen bezüglich eines Vormunds/Sachwalters des Patienten angegeben werden. Begriffsdefinition:

Ein Vormund kann existieren, wenn die Person noch nie geschäftsfähig war
- z.B. Kinder
Ein Sachwalter kann existieren, wenn die Person schon geschäftsfähig war, die Geschäftsfähigkeit aber entzogen wurde
- z.B. Alte Personen

Vormund/Sachwalter kann entweder eine Person (guardianPerson) oder eine Organisation (guardianOrganization) sein. Beim Patient können optional ein oder mehrere Vormund/Sachwalter Element(e) angegeben werden. Wenn ein Sachwalter bekannt ist, SOLL diese Information auch angegeben werden.

5.2.4 Verfasser des Dokuments („author“)

Auszug aus dem R-MIM:

Abbildung 8: Klassen rund um den Autor.

5.2.4.1 Spezifikation

Id

1.2.40.0.34.11.20002

ref

elgabbr-

Gültigkeit

2015‑05‑09

Andere Versionen mit dieser Id:

HeaderAuthor vom 2018‑10‑18 14:32:49
HeaderAuthor vom 2013‑02‑10
HeaderAuthor vom 2011‑12‑19

Status

Aktiv

Versions-Label

Name

HeaderAuthor

Bezeichnung

HeaderAuthor

Beschreibung

Der Dokumentersteller („author“) ist in der Regel die „das Dokument verfassende Person“ oder ein „datenerstellendes Gerät“. Damit ist diejenige Person oder das Gerät gemeint, welche das Dokument „inhaltlich“ verfasst (z.B.: diktiert). Die das Dokument „schreibende“ Person (z.B. Schreibkraft, Stationsschwester, …) wird in CDA in einem eigenen Element (dataEnterer) abgebildet (siehe „Personen der Dateneingabe („dataEnterer“)“).

Es kann auch mehr als ein Dokumentersteller angegeben werden (mehrere author-Elemente).

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-48	Autor	Datensatz

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.90001	Inklusion	PersonElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.20002 HeaderAuthor (2015‑05‑09)

ref

elgabbr-

Beispiel

Strukturbeispiel für eine Person als „author“

<author typeCode="AUT" contextControlCode="OP">
  
  <functionCode code="OA" displayName="Diensthabender Oberarzt" codeSystem="1.2.40.0.34.99.111.2.1" codeSystemName="Amadeus Spital Funktionen"/>  
  <time value="20081224082015+0100"/>  <assignedAuthor classCode="ASSIGNED">
    
    <id root="1.2.40.0.34.99.111.1.3" extension="1111" assigningAuthorityName="Amadeus Spital"/>    
    <code code="107" displayName="Fachärztin/Facharzt für Chirurgie" codeSystem="1.2.40.0.34.5.160" codeSystemName="ELGA_Fachaerzte"/>    
    <telecom value="tel:+43.1.40400"/>    <telecom value="mailto:herbert.mustermann@organization.at"/>    <assignedPerson classCode="PSN" determinerCode="INSTANCE">
      
      <name>
        <prefix qualifier="AC">Univ.-Prof. Dr.</prefix>        <given>Isabella</given>        <family>Stern</family>      </name>    </assignedPerson>    
    <representedOrganization>
      <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      
      <name>Amadeus Spital, 1. Chirurgische Abteilung</name>      
      <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="mailto:chirurgie@amadeusspital.at"/>      <addr>
        <streetName>Mozartgasse</streetName>        <houseNumber>1-7</houseNumber>        <postalCode>5350</postalCode>        <city>St.Wolfgang</city>        <state>Salzburg</state>        <country>AUT</country>      </addr>    </representedOrganization>  </assignedAuthor></author>

Beispiel

Strukturbeispiel für datenerstellende Geräte als „author“

<author>
  
  <time value="20081224082015+0100"/>  <assignedAuthor>
    
    <id root="86562fe5-b509-4ce9-b976-176fd376e477"/>    
    <assignedAuthoringDevice>
      <manufacturerModelName>Good Health System</manufacturerModelName>      <softwareName>Best Health Software Application</softwareName>    </assignedAuthoringDevice>    <representedOrganization>
      <id root="1.2.40.0.34.99.3" assigningAuthorityName="GDA Index"/>      
      <name>Amadeus Spital, 1. Chirurgische Abteilung</name>      
      <telecom value="tel:+43.6138.3453446.0"/>      <telecom value="mailto:chirurgie@amadeusspital.at"/>      <addr>
        <streetName>Mozartgasse</streetName>        <houseNumber>1-7</houseNumber>        <postalCode>5350</postalCode>        <city>St.Wolfgang</city>        <state>Salzburg</state>        <country>AUT</country>      </addr>    </representedOrganization>  </assignedAuthor></author>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:author

Verfasser des Dokuments.

(Hea...hor)


	elgagab-dataelement-48	Autor	Datensatz

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

0 … 1

Funktionscode des Verfassers des Dokuments

z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“, …

Eigene Codes und Bezeichnungen können verwendet werden.

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

(Hea...hor)

hl7:time

TS.AT.TZ

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

(Hea...hor)

hl7:assignedAuthor

1 … 1

R

Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.

(Hea...hor)

@classCode

cs

0 … 1

F

ASSIGNED

Beispiel

hl7:id

II

1 … *

R

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

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

Zugelassene nullFlavor:

NI … Person hat keine ID / Gerät/Software hat keine ID
UNK … Person hat eine ID, diese ist jedoch unbekannt /Gerät/Software hat eine ID, diese ist jedoch unbekannt

(Hea...hor)

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.

(Hea...hor)

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.

(Hea...hor)

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:assignedPerson
hl7:assignedAuthoringDevice

hl7:assignedPerson

… 1

Personendaten des Verfassers des Dokuments.

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

(Hea...hor)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

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

(Hea...hor)

hl7:assignedAuthoringDevice

… 1

(Hea...hor)

@classCode

cs

0 … 1

F

DEV

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:manufacturerModelName

SC

1 … 1

R

Hersteller und Modellbezeichnung des datenerstellenden Gerätes.

(Hea...hor)

hl7:softwareName

SC

1 … 1

R

Bezeichnung (und ggf Version) der datenerstellenden Software.

(Hea...hor)

hl7:representedOrganization

1 … 1

M

Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.

(Hea...hor)

Beispiel

hl7:id

II

1 … *

M

Die OID der Organisation aus dem GDA-Index.

Hinweise:
id[1] MUSS aus dem GDA-I stammen, weitere id-Elemente können hinzugefügt werden.

Für den Namen von größere Organisationen SOLL auch die Abteilung angegeben werden., z.B.: „Amadeus Spital, Chirurgische Abteilung“

Für die Adresse MUSS mindestens Granularitätsstufe 2 angewendet werden.

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

(Hea...hor)

hl7:name

ON

1 … 1

M

(Hea...hor)

hl7:telecom

TEL.AT

0 … *

(Hea...hor)

hl7:addr

AD

0 … 1

(Hea...hor)

5.2.4.2 Spezifikation: Datenerstellende Geräte als „author“

Datenerstellende Geräte/Software (z.B.: das Service der e-Medikation, das die aktuelle Medikationsliste generiert). Siehe auch Rechtlicher Unterzeichner („legalAuthenticator“).

5.2.5 Verwahrer des Dokuments („custodian“)

Auszug aus dem R-MIM:

Abbildung 9: Klassen rund um die das Dokument verwaltende Organisation.

5.2.5.1 Spezifikation

Id

1.2.40.0.34.11.20004

ref

elgabbr-

Gültigkeit

2015‑05‑28

Andere Versionen mit dieser Id:

HeaderCustodian vom 2011‑12‑19

Status

Aktiv

Versions-Label

Name

HeaderCustodian

Bezeichnung

HeaderCustodian

Beschreibung

Der „Verwahrer des Dokuments“ ist diejenige Organisation, die „für die Verwahrung/Verwaltung des Dokuments verantwortlich ist“.

Beispiele:

Das erstellende Krankenhaus ist selbst der Verwalter des Dokuments.

Der übergeordnete Krankenhausträger ist der Verwalter des Dokuments.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-73	Verwahrer	Datensatz

Beziehung

Version: Template 1.2.40.0.34.11.20004 HeaderCustodian (2015‑05‑28)

ref

elgabbr-

Version: Template 1.2.40.0.34.11.20004 HeaderCustodian (2011‑12‑19)

ref

elgabbr-

Beispiel

Vollständiges Beispiel

<custodian typeCode="CST">
  <assignedCustodian classCode="ASSIGNED">
    <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">
      <id root="1.2.3.999" extension="--example only--" assigningAuthorityName="GDA-Index"/>      <name>Amadeus Spital</name>      <telecom value="tel:+43.(0)50.55460-0"/>      <addr>
        <streetName>Hafenstraße</streetName>        <houseNumber>47-51</houseNumber>        <postalCode>4020</postalCode>        <city>Linz</city>        <state>Oberösterreich</state>        <country>AUT</country>      </addr>    </representedCustodianOrganization>  </assignedCustodian></custodian>

Beispiel

Minimalbeispiel

<custodian>
  <assignedCustodian>
    <representedCustodianOrganization>
      <id root="1.2.3.999" extension="--example only--"/>      <name>Amadeus Spital</name>      <addr>
        <streetAddressLine>Hafenstraße 47-51</streetAddressLine>        <postalCode>4020</postalCode>        <city>Linz</city>        <country>AUT</country>      </addr>    </representedCustodianOrganization>  </assignedCustodian></custodian>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:custodian

Verwahrer des Dokuments.

(Hea...ian)


	elgagab-dataelement-73	Verwahrer	Datensatz

@typeCode

cs

0 … 1

F

CST

hl7:assignedCustodian

1 … 1

M

(Hea...ian)

@classCode

cs

0 … 1

F

ASSIGNED

hl7:representedCustodianOrganization

1 … 1

M

(Hea...ian)

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

1 … 1

R

Identifikation des Verwahrers des Dokuments, wie im GDA-Index angegeben.

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

Zugelassene nullFlavor:

NI … Organisation hat keine ID aus dem GDA-Index
UNK … Organisation hat eine ID aus dem GDA-Index, diese ist jedoch unbekannt

(Hea...ian)

hl7:name

1 … 1

M

Name des Verwahrers des Dokuments (Organisation).
Grundsätzlich sind die Vorgaben für „Namen-Elemente von Organisationen ON“ zu befolgen.

(Hea...ian)

hl7:telecom

TEL.AT

0 … 1

Kontaktdaten des Verwahrers des Dokuments (Organisation).
Grundsätzlich sind die Vorgaben für „Kontaktdaten-Elemente“ zu befolgen.

(Hea...ian)

hl7:addr

AD

1 … 1

M

Adresse des Verwahrers des Dokuments (Organisation).
Grundsätzlich sind die Vorgaben für „Adress-Elemente“ zu befolgen.

(Hea...ian)

5.2.5.1.1 id

Element/Attribut		DT	Kard	Konf	Beschreibung
id		II	1..1	R	Identifikation des Verwahrers des Dokuments aus dem GDA-Index. Grundsätzlich sind die Vorgaben gemäß Kapitel „Identifikations-Elemente“ zu befolgen.“ Zugelassene nullFlavor: NI … Organisation hat keine ID aus dem GDA-Index UNK … Organisation hat eine ID aus dem GDA-Index, diese ist jedoch unbekannt

In der nächsten Version des Leitfadens wird die Konformität entsprechend dem CDA-Standard auf [M] erhöht, Null Flavors sind dann nicht mehr erlaubt.

5.2.6 Nicht erlaubte Elemente

Folgende Elemente sind in den Dokumenten der e-Medikation NICHT ERLAUBT:

Personen bei der Dateneingabe („dataEnterer“)
Beabsichtigte Empfänger des Dokuments („informationRecipient“)
Weitere Unterzeichner („authenticator“)
Weitere Beteiligte („participants“)

5.2.7 Elemente mit speziellen Vorgaben

5.2.7.1 Rechtlicher Unterzeichner („legalAuthenticator“)

5.2.7.1.1 Spezielle Vorgaben für Rezept

Element/Attribut	DT	Kard	Konf	Beschreibung
legalAuthenticator	POCD_MT000040.LegalAuthenticator		M	Rechtlicher Unterzeichner

5.2.7.1.2 Spezielle Vorgaben für Abgabe

Element/Attribut	DT	Kard	Konf	Beschreibung
legalAuthenticator	POCD_MT000040.LegalAuthenticator		M	Rechtlicher Unterzeichner

5.2.7.1.3 Spezielle Vorgaben für Medikationsliste

Die Medikationsliste wird automatisch durch einen Algorithmus erstellt und wird nicht von einer natürlichen Person freigegeben, daher ist kein rechtlicher Unterzeichner verfügbar.

Element/Attribut	DT	Kard	Konf	Beschreibung
legalAuthenticator	POCD_MT000040.LegalAuthenticator		NP	Rechtlicher Unterzeichner

5.2.7.1.4 Spezielle Vorgaben für Pharmazeutische Empfehlung

Element/Attribut	DT	Kard	Konf	Beschreibung
legalAuthenticator	POCD_MT000040.LegalAuthenticator		M	Rechtlicher Unterzeichner

5.3 Zuweisung und Ordermanagement

Dieses Element ist in den Dokumenten der e-Medikation NICHT ERLAUBT.

5.4 Dokumentation der Gesundheitsdienstleistung

5.4.1 Service Events („documentationOf/serviceEvent“)

Für Dokumentklasse „Rezept“:
Verweis auf den Allgemeinen Leitfaden (mit Anpassungen):
Das Element ist grundsätzlich gemäß den Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“ anzugeben, es sind jedoch spezielle Vorgaben vorgeschrieben.

Für alle anderen Dokumentklassen der e-Medikation:
Dieses Element ist NICHT ERLAUBT.

Auszug aus dem Allgemeinen Implementierungsleitfaden

5.5 Dokumentation der Gesundheitsdienstleistung

5.5.1 Service Events („documentationOf/serviceEvent“)

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

In serviceEvent/effectiveTime kann der Zeitpunkt/Zeitraum der Gesundheitsdienstleistung angegeben werden. Im Gegensatz zum Encounter (siehe Kapitel „Informationen zum Patientenkontakt“), der ggf. mehrere Gesundheitsdienstleistungen „umrahmt“.

Da diese Informationen in die XDS-Metadaten übernommen werden, ergeben sich folgende Implikationen:

Die serviceEvents sind die einzigen (rein) medizinischen Informationen zum Dokument im Dokumentenregister
Können daher als Such-/Filterkriterium verwendet werden
Scheint ggf. in den Ergebnissen der Suchabfragen auf

-> Sollte eine wertvolle Information sein (für den Behandler!)

Auszug aus dem R-MIM:

Abbildung 15: Klassen rund um die Gesundheitsdienstleistung.

5.5.1.1 Spezifikation

Da dieses Element automatisch in die XDS-Metadaten übernommen wird, SOLL mindestens eine Gesundheitsdienstleistung als documentationOf/serviceEvent-Element angegeben werden [R2].

ACHTUNG: Die Zeitangaben der Gesundheitsdienstleistung (erstes documentationOf/serviceEvent-Element) werden in die Dokument-Metadaten übernommen!

Die Bedeutung der Dokument-Metadaten-Elemente lautet daher wie folgt:

serviceStartTime: Beginn des ersten documentationOf/serviceEvent-Elements
serviceStopTime: Ende des ersten documentationOf/serviceEvent-Elements

Die semantische Bedeutung dieser Zeitpunkte wird in den speziellen Implementierungs-leitfäden festgelegt.

Es können beliebig viele weitere Gesundheitsdienstleistungen als weitere documentationOf/serviceEvent-Elemente angegeben werden.

Id

1.2.40.0.34.11.20010

ref

elgabbr-

Gültigkeit

2011‑12‑19

Status

Aktiv

Versions-Label

Name

HeaderServiceEvent

Bezeichnung

HeaderServiceEvent

Beschreibung

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

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-145	Gesundheitsdienstleistung	Datensatz

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.40.0.34.11.90003	Inklusion	AssignedEntityElements	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.20010 (2017‑07‑21 11:18:58)

ref

?

Version: Template 1.2.40.0.34.11.20010 HeaderServiceEvent (2011‑12‑19)

ref

elgabbr-

Beispiel

Strukturbeispiel Koloskopie

Beispiel

Strukturbeispiel Hämatologie

Item

DT

Kard

Konf

Beschreibung

Label

hl7:documentationOf

Komponente für die Gesundheitsdienstleistung.

(Hea...ent)


	elgagab-dataelement-145	Gesundheitsdienstleistung	Datensatz

@typeCode

cs

0 … 1

F

DOC

hl7:serviceEvent

1 … 1

M

Gesundheitsdienstleistung.

(Hea...ent)

@classCode

cs

0 … 1

F

ACT

@moodCode

cs

0 … 1

F

EVN

hl7:code

CE

1 … 1

R

Code der Gesundheitsdienstleistung.
Zugelassene nullFlavor: UNK
Grundsätzlich sind die Vorgaben für „Codierungs-Elemente“ zu befolgen.

(Hea...ent)

hl7:effectiveTime

IVL_TS

1 … 1

M

Zeitraum der Gesundheitsdienstleistung.

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

(Hea...ent)

hl7:low

TS

1 … 1

M

(Hea...ent)

hl7:high

TS

1 … 1

M

(Hea...ent)

hl7:performer

0 … *

Durchführende Entität(en) der Gesundheitsdienstleistung.

(Hea...ent)

hl7:assignedEntity

1 … 1

M

(Hea...ent)

Eingefügt

von 1.2.40.0.34.11.90003 AssignedEntityElements (DYNAMIC)

hl7:id

II

1 … *

R

Mindestens eine Id der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...ent)

hl7:addr

AD

0 … 1

Ein Adress-Element der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...ent)

hl7:telecom

TEL.AT

0 … *

Mindestens ein Telecom-Element der validierenden Person.

Zugelassene nullFlavor: UNK

(Hea...ent)

hl7:assignedPerson

1 … 1

M

Persondendaten der validierenden Person.

(Hea...ent)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

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

(Hea...ent)

hl7:representedOrganization

0 … 1

Organistationsdaten der validierenden Person.

(Hea...ent)

Eingefügt

von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Hea...ent)

hl7:name

ON

1 … 1

M

(Hea...ent)

hl7:telecom

TEL.AT

0 … *

(Hea...ent)

hl7:addr

AD

0 … 1

(Hea...ent)

Verweis auf speziellen Implementierungsleitfaden:
serviceEvent Element Allgemein
Ob eine Gesundheitsdienstleistung angegeben werden muss, und welche Bedeutung dieses Element hat, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
code
Welche Codierung angewandt werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
effectiveTime
Welche Start- und Endezeiten eingetragen werden sollen, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.
performer
Ob und welche durchführende Entität eingetragen werden soll, ergibt sich aus dem jeweiligen speziellen Implementierungsleitfaden.

effectiveTime
Hinweis: Für die automatisierte Datenübernahme aus dem CDA-Dokument in die XDS-Dokumentmetadaten ist stets ein Zeitintervall anzugeben.

5.5.1.2 Spezielle Vorgaben für Dokumentklasse „Rezept“ (Prescription)

Das Element Service Event wird im Falle von Dokumentklasse „Rezept“ zur Angabe der Rezeptart und Gültigkeitsdauer verwendet.

Das Code-Element bezeichnet die Rezeptart und MUSS gemäß ELGA Value Set „ELGA_MedikationRezeptart_VS“ befüllt werden.

Als Zeitangabe MUSS die Gültigkeitsdauer des Rezepts angegeben werden.

5.5.1.3 Strukturbeispiel

<documentationOf>
  <serviceEvent>
    <code code="KASSEN"
       displayName="Kassenrezept"
       codeSystem="1.2.40.0.10.1.4.3.4.3.3"
       codeSystemName="MedikationRezeptart" />
    <effectiveTime>
       <low value="<Beginn des Gültigkeitszeitraums des Rezepts>"/>
       <high value="<Ende des Gültigkeitszeitraums des Rezepts>"/>
    </effectiveTime>
  </serviceEvent>
</documentationOf>

5.5.1.4 Spezifikation

Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“ mit folgenden Änderungen:

5.5.1.4.1 Änderung 1: serviceEvent-Element Allgemein

Konformität geändert auf [M]. Kardinalität geändert auf 1..1.

Element/Attribut		DT	Kard	Konf	Beschreibung
documentationOf		POCD_MT000040.DocumentationOf	1..1	M	Komponente für die Gesundheitsdienstleistung
	serviceEvent	POCD_MT000040.ServiceEvent	1..1	M	Gesundheitsdienstleistung

5.5.1.4.2 Änderung 2: code

Element/Attribut		DT	Kard	Konf	Beschreibung
code		CE CWE	1..1	R	Code der Gesundheitsdienstleistung Zugelassene NullFlavor: MSK⁹
	@code	cs	1..1	M	Werte aus ELGA Value Set: ELGA_MedikationRezeptart_VS
	@displayName	st	1..1	M	Werte aus ELGA Value Set: ELGA_MedikationRezeptart_VS
	@codeSystem	uid	1..1	M	Fester Wert: 1.2.40.0.10.1.4.3.4.3.3
	@codeSystemName	st	1..1	M	Fester Wert: MedikationRezeptart

⁹ Wird die Rezeptart nicht angegeben (NullFlavor = MSK, Maskiert), wird die Rezeptart mit „KASSEN“ angenommen.

5.5.1.4.3 Änderung 3: effectiveTime

Als Zeitangabe MUSS die Gültigkeitsdauer des Rezepts angegeben werden.

Element/Attribut			DT	Kard	Konf	Beschreibung
effectiveTime			IVL_TS	1..1	R	Zeitelement zur Dokumentation des Gültigkeitszeitraums. Zugelassene NullFlavor: MSK¹⁰ (bei NullFlavor sindUnterelemente NICHT ERLAUBT) Datumsangaben für Beginn- und Ende des Gültigkeitszeitraums sind immer ohne Zeitangabe vorzunehmen (z.B. „20141224“ für den 24.12.2014).
	low		TS	1..1	M
		@value	ts	1..1	M	Beginn des Gültigkeitszeitraums Bei Kassen- und Privatrezepten: MUSS immer mit dem aktuellen Datum befüllt sein. Bei Substitutionsrezepten: Datum frei wählbar.
	high		TS	1..1	M
		@value	ts	1..1	M	Ende des Gültigkeitszeitraums 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.

Bemerkung: Datumsangaben in HL7, welche keine Zeit beinhalten, implizieren immer die Zeit 00:00:00 (siehe Allgemeiner Leitfaden, Kapitel „Zeitelemente“). Das bedeutet, dass bei Angabe eines Ende-Datums (ohne Zeitangabe), der angegebene Tag nicht inkludiert ist. Dementsprechend ist beim Ende des Gültigkeitszeitraums immer ein Tag hinzuzuzählen.

¹⁰ Wird die Gültigkeitsdauer nicht angegeben (NullFlavor = MSK, Maskiert), kann die Gültigkeitsdauer vom empfangenden System nur mit 1 Monat angenommen werden, gerechnet vom Erstellungsdatum an.

5.5.1.4.4 Änderung 4: performer

Es wird keine durchführende Entität der Gesundheitsdienstleistung angegeben.

Element/Attribut	DT	Kard	Konf	Beschreibung
performer	POCD_MT000040.Performer1	0..0	NP	Durchführende Entität der Gesundheitsdienstleistung

5.6 Bezug zu vorgehenden Dokumenten

Verweis auf den Allgemeinen Leitfaden:
Das Element erfordert keine speziellen Vorgaben. Es gelten die Vorgaben des entsprechenden Kapitels des „Allgemeinen Implementierungsleitfadens“.

Auszug aus dem Allgemeinen Implementierungsleitfaden

5.7 Bezug zu vorgehenden Dokumenten

5.7.1 Allgemeines

Dieses Kapitel beschreibt die Versionsverwaltung von CDA-Dokumenten.

Der Bezug zu Vorgängerversionen von Dokumenten wird durch die relatedDocument-Beziehung und die ParentDocument-Klasse, zusammen mit setId und versionNumber aus der ClinicalDocument-Klasse (siehe Versionierung des Dokuments), spezifiziert.

Abbildung 16: Grundsätzlicher Aufbau eines CDA-Dokuments aus XML Sicht.

Der Bezug zum Vordokument wird dabei über die parentDocument Beziehung ausgedrückt, in dem der dazugehörige @typeCode einen Wert aus der Liste der gültigen @typeCodes in der relatedDocument-Beziehung erhält. Das Originaldokument, auf das sich das Dokument bezieht, bleibt dabei unverändert.

Liste der möglichen Werte der @typeCodes in der relatedDocument Beziehung:

code	displayName	Bedeutung
~~APND~~	~~append~~	Verwendung NICHT ERLAUBT Zusammenhängen von Dokumenten. Dies ist in ELGA bereits über das Einbetten von Dokumenten realisiert.
RPLC	replaces	Das Dokument ersetzt ein existierendes Dokument. Der Status des zu ersetzenden Dokumentes wird auf "überholt" gesetzt, das ursprüngliche Dokument bleibt aber noch im System als historische Referenz verfügbar.
~~XFRM~~	~~transformed~~	Verwendung NICHT ERLAUBT 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 Affiniy Domains Anwendung findet. Für ELGA ist die Transformation jedoch kein Anwendungsfall.

Tabelle 4: Vokabel-Domäne relatedDocument.typeCode

5.7.1.1 Spezifikation

Id

1.2.40.0.34.11.20011

ref

elgabbr-

Gültigkeit

2014‑12‑06

Andere Versionen mit dieser Id:

HeaderRelatedDocument vom 2011‑12‑19

Status

Aktiv

Versions-Label

Name

HeaderRelatedDocument

Bezeichnung

HeaderRelatedDocument

Beschreibung

Der Bezug zu vorgehenden Dokumenten wird durch die relatedDocument-Beziehung und die ParentDocument-Klasse, zusammen mit setId und versionNumber aus der ClinicalDocument-Klasse, spezifiziert.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
elgagab-dataelement-155	Bezug zu vorgehenden Dokumenten	Datensatz

Beziehung

Version: Template 1.2.40.0.34.11.20011 HeaderRelatedDocument (2014‑12‑06)

ref

elgabbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:relatedDocument

Komponente für das vorgehende Dokument.

(Hea...ent)


	elgagab-dataelement-155	Bezug zu vorgehenden Dokumenten	Datensatz

@typeCode

cs

1 … 1

F

RPLC

Art des Bezugs zum Vordokument.

hl7:parentDocument

1 … 1

M

Vorhergehendes Dokument.

(Hea...ent)

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

(Hea...ent)

5.8 Einverständniserklärung

Dieses Element ist in den Dokumenten der e-Medikation NICHT ERLAUBT.

5.9 Informationen zum Patientenkontakt

Dieses Element ist in den Dokumenten der e-Medikation NICHT ERLAUBT.

6 Fachlicher Inhalt (CDA Body)

6.1 Überblick

6.1.1 Allgemeine Vorschrift für strukturierten Inhalt

Wird der Inhalt strukturiert angegeben (in Form von „Sektionen“), so gelten grundsätzlich die Vorgaben des Kapitels „Sektionen“ des „Allgemeinen Implementierungsleitfadens“.

Dieser Leitfaden definiert darüber hinaus spezielle Anforderungen in der ELGA Interoperabilitätsstufe „Full support“.

Siehe Kapitel Fachlicher Inhalt in EIS „Full support“.

6.1.2 Menschen- und maschinenlesbare Daten

Ein Grundsatz des zugrunde liegenden Standards CDA Rel.2 ist, dass alle relevanten medizinischen Daten eines CDA-Dokumentes immer im „menschenlesbaren Teil“, dem narrativen Block (title und text-Elemente der Sections) enthalten sein MÜSSEN, zusätzlich können diese Daten auch in maschinenlesbarer Form (Entries) verfügbar sein. Die primäre Informationsquelle ist also der narrative Block.

Sind die narrativen Daten direkt von den maschinenlesbaren abgeleitet und daher inhaltlich gleich, wird das im Entry durch das Attribut typeCode="DRIV" angegeben, Hier kann ausschließlich der maschinenlesbare Teil ohne Informationsverlust zur Weiterverarbeitung verwendet werden.

6.1.3 Fachlicher Inhalt in EIS „Basic“ oder EIS „Enhanced“

Die Dokumente der e-Medikation DÜRFEN NICHT in den ELGA Interoperabilitätsstufen EIS „Basic“, „Structured“ oder „Enhanced“ angegeben werden. Sie werden ausschließlich in ELGA Interoperabilitätsstufe EIS „Full support“ angegeben.

6.1.4 Fachlicher Inhalt in EIS „Full support“

Dokumente der e-Medikation MÜSSEN ausschließlich in ELGA Interoperabilitätsstufe EIS „Full support“ angegeben werden.

6.2 Dokumente

6.2.1 Rezept

6.2.1.1 Struktur eines Rezept Dokuments

6.2.2 Abgabe

6.2.2.1 Struktur eines Abgabe Dokuments

6.2.3 Medikationsliste

6.2.3.1 Struktur eines Medikationslisten Dokuments

6.2.4 Pharmazeutische Empfehlung („Korrekturmeldung“)

6.2.4.1 Struktur eines Pharmazeutische Empfehlung Dokuments

6.3 Sektionen

6.3.1 Rezept Sektion

Diese Sektion wird in Dokumentklasse „Rezept“ verwendet.

6.3.1.1 Überblick

	EIS „Full Support“
Template ID	ELGA: 1.2.40.0.34.11.8.1.2.1
Parent Template ID	IHE PHARM Prescription Section: 1.3.6.1.4.1.19376.1.9.1.2.1
Titel der Sektion	Rezept
Definition	Diese Sektion beinhaltet alle Verordnungen, die auf diesem Rezept vermerkt sind in sowohl für Menschen als auch Maschinen lesbaren Formaten.
Codierung	LOINC: 57828-6, „Prescription list“
Konformität	[M]
Konformität Level 3	[M] ELGA MedikationVerordnung-Entry (1.2.40.0.34.11.8.1.3.1)

6.3.1.2 Strukturbeispiel

Id

1.2.40.0.34.11.8.2.2.1

ref

elgabbr-

Gültigkeit

2014‑01‑31

Status

Aktiv

Versions-Label

Name

AbgabeSection

Bezeichnung

Abgabe Section

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.8.2.2.1

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.11.8.2.3.1	Containment	Medikation Abgabe Entry eMedikation	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.8.2.2.1 (2017‑07‑21 11:58:04)

ref

?

Version: Template 1.2.40.0.34.11.8.2.2.1 Abgabe Section (2014‑01‑31)

ref

elgabbr-

Beispiel

Strukturbeispiel

<section>
  
  <templateId root="1.2.40.0.34.11.8.2.2.1"/>  
  <templateId root="1.3.6.1.4.1.19376.1.9.1.2.3"/>  
  <templateId root="2.16.840.1.113883.10.20.1.8"/>  
  <code code="60590-7" displayName="Medication Dispensed.Brief" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  
  <title>Abgabe</title>  
  <text> ... Lesbarer Textbereich ... </text>  
  <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

Container zur Angabe einer Sektion.

(Abg...ion)

@classCode

cs

0 … 1

F

DOCSECT

hl7:templateId

II

1 … 1

M

(Abg...ion)

@root

uid

1 … 1

F

1.2.40.0.34.11.8.2.2.1

hl7:templateId

II

1 … 1

M

IHE PHARM Dispense Section

(Abg...ion)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.9.1.2.3

hl7:templateId

II

1 … 1

M

HL7 CCD 3.9

(Abg...ion)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.8

hl7:id

II

0 … 1

Eindeutige ID der Sektion (optional).

(Abg...ion)

Beispiel

Strukturbeispiel

hl7:code

CE

1 … 1

M

(Abg...ion)

@code

CONF

1 … 1

F

60590-7

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@codeSystemName

1 … 1

F

LOINC

@displayName

1 … 1

F

Medication Dispensed.Brief

hl7:title

ST

1 … 1

M

Titel der Sektion.

(Abg...ion)

CONF

Elementinhalt muss "Abgabe" sein

hl7:text

SD.TEXT

1 … 1

M

Information für den menschlichen Leser.

(Abg...ion)

hl7:entry

1 … *

R

Maschinenlesbare Elemente der Sektion.
Beinhaltet 1.2.40.0.34.11.8.2.3.1 Medikation Abgabe Entry eMedikation (DYNAMIC)

(Abg...ion)

@typeCode

cs

0 … 1

F

DRIV

Constraint

Konditionale Konformität <TBODY></TBODY>

Card	Conf	Prädikat
1..1	M	Narrativer Text ist vollständig von den maschinenlesbaren Elementen abgeleitet und enthält keine darüber hinausgehende Information
	NP	Narrativer Text ist nicht vollständig von den maschinenlesbaren Elementen abgeleitet und enthält darüber hinausgehende Information

6.3.1.2.1 Textbereich der Sektion

6.3.1.2.1.1 Empfehlung zur Gestaltung im Falle von CDA Level 3

Die Gestaltung des Textbereichs der Sektion SOLL mit den folgenden Informationselementen und in Form und Layout wie folgt erfolgen.

Tabelle zur Darstellung der Rezeptdaten
Die erste Tabelle stellt die Informationen zum Rezept dar. Die zugrundeliegenden Daten befinden sich im <ClinicalDocument/documentationOf/serviceEvent> Element.

Rezeptart	Gültig von	Gültig bis
< code/@displayName>	<effectiveTime/low/@value>	<effectiveTime/high/@value>

Beispiel:

Rezeptart	Gültig von	Gültig bis
Kassenrezept	2013-03-26	2013-04-27 ¹¹

¹¹ Datumsangaben in HL7, welche keine Zeit beinhalten, implizieren immer die Zeit 00:00:00 (siehe Allgemeiner Leitfaden, Kapitel „Zeitelemente“). Das bedeutet, dass bei Angabe eines Ende-Datums (ohne Zeitangabe), der angegebene Tag nicht inkludiert ist. Dementsprechend ist beim Ende des Gültigkeitszeitraums immer ein Tag hinzuzuzählen

Tabelle zur Darstellung der Verordnungen
Pro Verordnung (entry/substanceAdministration Element) SOLLEN folgende Informationselemente in Tabellenform angegeben werden:

Element	Generierungsvorschrift aus den Entries	Beispiel
Verordnung	Ordnungszahl der Verordnung	1
VerordnungsID	<id/@root> / <id/@extension>	1.2.40.0.10.1.4.3.4.2.2 / 4711
Arznei: Handelsname	<consumable/manufacturedProduct/manufacturedMaterial/name>	CIPROXIN FTBL 500MG
Arznei: Pharmazentralnummer	<consumable/manufacturedProduct/manufacturedMaterial/code/@code>	981417
Arznei: Darreichungsform	<consumable/manufacturedProduct/manufacturedMaterial/pharm:formCode/@displayName>	Filmtablette
Arznei: Angaben zur Packung	<consumable/manufacturedProduct/manufacturedMaterial/pharm:asContent/pharm:containerPackagedMedicine/pharm:capacityQuantity/@value> <consumable/manufacturedProduct/manufacturedMaterial/pharm:asContent/pharm:containerPackagedMedicine/pharm:capacityQuantity/@unit>¹²	30 Einheiten
Arznei: Wirkstoffklassifikation (ATC Code¹³)	<consumable/manufacturedProduct/manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:name> consumable/manufacturedProduct/ manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:code/@code>)	Ciprofloxacin (J01MA02)
Arznei: Wirkstoffklassifikation (ATC Code)	… Weitere Wirkstoffe …	…
Einnahmestart	<effectiveTime[1]/low/@value>	2013-03-27, 00:00:00
Einnahmeende	<effectiveTime[1]/high/@value>	2013-03-30, 23:59:59
Einnahmedauer	<effectiveTime[1]/width/@value> <effectiveTime[1]/width/@unit>¹⁴	2 Wochen
Dosierung	Dosierungsvariante 1: Tagesdosierung <doseQuantity/@value> <doseQuantity/@unit>¹⁵, <effectiveTime[2]/period/@unit>¹⁶ Dosierungsvariante 2: Einzeldosierung <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACM‘]/substanceAdministration/doseQuantity/@value>¹⁷ -<entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACD‘]/substanceAdministration/doseQuantity/@value> - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACV‘]/substanceAdministration/doseQuantity/@value> - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘HS‘]/substanceAdministration/doseQuantity/@value>, täglich Dosierungsvariante 3: Tagesdosierung an bestimmten Tagen <doseQuantity/@value><doseQuantity/@unit>¹⁸, <effectiveTime[2]/period/@unit>¹⁹, wöchentlich, am Wochentag(<effectiveTime[2]/comp[1]/phase/@value>)²⁰, Wochentag(<effectiveTime[2]/comp[2]/phase/@value>), … Dosierungsvariante 4: Einzeldosierung an bestimmten Tagen <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACM‘]/substanceAdministration/doseQuantity/@value>²¹ -<entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACD‘]/substanceAdministration/doseQuantity/@value> - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACV‘]/substanceAdministration/doseQuantity/@value> - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘HS‘]/substanceAdministration/doseQuantity/@value>, wöchentlich, am Wochentag(<entryRelationship[@typeCode=‘COMP‘]/substanceAdministration/effectiveTime/comp[1]/phase/@value>), Wochentag(<entryRelationship[@typeCode=‘COMP‘]/substanceAdministration/effectiveTime/comp[2]/phase/@value>), …	2 Einheiten, täglich 200 mg, wöchentlich 2 - 0 - 1 - 0, täglich 1 - 0 - 0 - 0, täglich 2 Einheiten, wöchentlich am Di, Do 200 mg, wöchentlich am Mo, Mi, Fr 1 - 0 - 1 - 0,.wöchentlich am Mo, Fr 2 - 1 - 1 - 0, wöchentlich am Di
Art der Anwendung	<routeCode/@displayName>	Anwendung auf der Haut
Therapieart	< code/@displayName>	Einzelverordnung
Anzahl der Einlösungen	<repeatNumber/@value> + 1	1
Packungsanzahl	<entryRelationship/supply/quantity/@value>	1
Zusatzinformationen für den Patienten und alternative Einnahme	Wird nicht aus den Entries generiert.	Die Dosierung ist genau einzuhalten! Nur alle 2 Wochen am Dienstag
Ergänzende Informationen zur magistralen Zubereitung und Abgabe	Wird nicht aus den Entries generiert.	Inotyol Salbe 30,0 / Canesten Creme 30,0

¹² Wenn @unit nicht gegeben ist, ist das Wort „Einheiten“ anzugeben
¹³ Falls vorhanden
¹⁴ @unit ist gemäß Valueset „ELGA_MedikationFrequenz_VS“ auf den displayName zu übersetzen
¹⁵ Wenn @unit nicht gegeben ist, ist das Wort „Einheiten“ anzugeben
¹⁶ @unit ist gemäß Valueset „ELGA_MedikationFrequenz_VS“ auf den displayName zu übersetzen
¹⁷ Wenn Element nicht vorhanden, ist 0 anzugeben
¹⁸ Wenn @unit nicht gegeben ist, ist das Wort „Einheiten“ anzugeben
¹⁹ @unit ist gemäß Valueset „ELGA_MedikationFrequenz“ auf den displayName zu übersetzen
²⁰ Wochentag(<Datum>) ist hier eine Funktion zur Ermittlung des Wochentags des angegebenen Datums (z.B. Mo für Montag)
²¹ Wenn Element nicht vorhanden, ist 0 anzugeben

Empfehlung zum Layout der Tabelle:

Verordnung	1
VerordnungsID	4711
Arznei: Handelsname	CIPROXIN FTBL 500MG
Arznei: Pharmazentralnummer	981417
Arznei: Darreichungsform	Filmtablette
:

6.3.2 Abgabe Sektion

Diese Sektion wird in Dokumentklasse „Abgabe“ verwendet.

6.3.2.1 Überblick

	EIS „Full Support“
Template ID	ELGA: 1.2.40.0.34.11.8.2.2.1
Parent Template ID	IHE PHARM Dispense Section: 1.3.6.1.4.1.19376.1.9.1.2.3
Titel der Sektion	Abgabe
Definition	Diese Sektion beinhaltet eine Abgabe einer Medikation.
Codierung	LOINC: 60590-7, „Medication Dispensed.Brief“
Konformität	[M]
Konformität Level 3	[M] ELGA MedikationVerordnung-Entry (1.2.40.0.34.11.8.2.3.1)

6.3.2.2 Spezifikation

Id

1.2.40.0.34.11.8.2.2.1

ref

elgabbr-

Gültigkeit

2014‑01‑31

Status

Aktiv

Versions-Label

Name

AbgabeSection

Bezeichnung

Abgabe Section

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.8.2.2.1

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.11.8.2.3.1	Containment	Medikation Abgabe Entry eMedikation	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.8.2.2.1 (2017‑07‑21 11:58:04)

ref

?

Version: Template 1.2.40.0.34.11.8.2.2.1 Abgabe Section (2014‑01‑31)

ref

elgabbr-

Beispiel

Strukturbeispiel

<section>
  
  <templateId root="1.2.40.0.34.11.8.2.2.1"/>  
  <templateId root="1.3.6.1.4.1.19376.1.9.1.2.3"/>  
  <templateId root="2.16.840.1.113883.10.20.1.8"/>  
  <code code="60590-7" displayName="Medication Dispensed.Brief" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  
  <title>Abgabe</title>  
  <text> ... Lesbarer Textbereich ... </text>  
  <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

Container zur Angabe einer Sektion.

(Abg...ion)

@classCode

cs

0 … 1

F

DOCSECT

hl7:templateId

II

1 … 1

M

(Abg...ion)

@root

uid

1 … 1

F

1.2.40.0.34.11.8.2.2.1

hl7:templateId

II

1 … 1

M

IHE PHARM Dispense Section

(Abg...ion)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.9.1.2.3

hl7:templateId

II

1 … 1

M

HL7 CCD 3.9

(Abg...ion)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.8

hl7:id

II

0 … 1

Eindeutige ID der Sektion (optional).

(Abg...ion)

Beispiel

Strukturbeispiel

hl7:code

CE

1 … 1

M

(Abg...ion)

@code

CONF

1 … 1

F

60590-7

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@codeSystemName

1 … 1

F

LOINC

@displayName

1 … 1

F

Medication Dispensed.Brief

hl7:title

ST

1 … 1

M

Titel der Sektion.

(Abg...ion)

CONF

Elementinhalt muss "Abgabe" sein

hl7:text

SD.TEXT

1 … 1

M

Information für den menschlichen Leser.

(Abg...ion)

hl7:entry

1 … *

R

Maschinenlesbare Elemente der Sektion.
Beinhaltet 1.2.40.0.34.11.8.2.3.1 Medikation Abgabe Entry eMedikation (DYNAMIC)

(Abg...ion)

@typeCode

cs

0 … 1

F

DRIV

Constraint

Konditionale Konformität <TBODY></TBODY>

Card	Conf	Prädikat
1..1	M	Narrativer Text ist vollständig von den maschinenlesbaren Elementen abgeleitet und enthält keine darüber hinausgehende Information
	NP	Narrativer Text ist nicht vollständig von den maschinenlesbaren Elementen abgeleitet und enthält darüber hinausgehende Information

6.3.2.2.1 Textbereich der Sektion

6.3.2.2.1.1 Empfehlung zur Gestaltung im Falle von CDA Level 3

Der Textbereich der Sektion SOLL mit den folgenden Informationselementen und in Form und Layout wie folgt gestaltet werden:

Tabelle zur Darstellung der Abgabe
Für die Abgabe (entry/supply Element) SOLLEN folgende Informationselemente in Tabellenform angegeben werden:

Element	Generierungsvorschrift aus den Entries	Beispiel
AbgabeID	<id/@root> / <id/@extension>	1.2.40.0.10.1.4.3.4.2.3 / 081511
Referenz zu Verordnung	<entryRelationship[@typeCode=‘REFR‘]/substanceAdministration/id/@root> / <entryRelationship[@typeCode=‘REFR‘]/substanceAdministration/id/@extension>	1.2.40.0.10.1.4.3.4.2.2 / 4711
Arznei: Handelsname	<product/manufacturedProduct/manufacturedMaterial/name>	CIPROXIN FTBL 500MG
Arznei: Pharmazentralnummer	<product/manufacturedProduct/manufacturedMaterial/code/@code>	981417
Arznei: Darreichungsform	<product/manufacturedProduct/manufacturedMaterial/pharm:formCode/@displayName>	Filmtablette
Arznei: Angaben zur Packung	<product/manufacturedProduct/manufacturedMaterial/pharm:asContent/pharm:containerPackagedMedicine/pharm:capacityQuantity/@value> < product/manufacturedProduct/manufacturedMaterial/pharm:asContent/pharm:containerPackagedMedicine/pharm:capacityQuantity/@unit>²²	30 Einheiten
Arznei: Wirkstoffklassifikation (ATC Code)	<product/manufacturedProduct/ manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:name> (<product/manufacturedProduct/ manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:code/@code>)	Ciprofloxacin (J01MA02)
Arznei: Wirkstoffklassifikation (ATC Code)	… Weitere Wirkstoffe …	…
Therapieart	< code/@displayName>	Einzelverordnung
Anzahl der abgegebenen Packungen	<quantity/@value>	1
Zusatzinformationen für den Patienten und alternative Einnahme	Wird nicht aus den Entries generiert.	Die Dosierung ist genau einzuhalten! Nur alle 2 Wochen am Dienstag
Ergänzende Informationen zur magistralen Zubereitung und Abgabe	Wird nicht aus den Entries generiert.	Inotyol Salbe 30,0 / Canesten Creme 30,0

²² Wenn @unit nicht gegeben ist, ist das Wort „Einheiten“ anzugeben

Empfehlung zum Layout der Tabelle:

AbgabeID	081511
Arznei: Handelsname	CIPROXIN FTBL 500MG
Arznei: Pharmazentralnummer	981417
Arznei: Darreichungsform	Filmtablette
:

Tabelle zur Darstellung der geänderten Dosierungsinformationen
Sind geänderte Dosierungsinformationen vorhanden (entry/supply/entryRelationship [@typeCode=‘COMP‘]/substanceAdministration) MUSS eine zweite Tabelle wie folgt angegeben werden.

Element	Generierungsvorschrift aus den Entries	Beispiel
Einnahmestart	Generierungsvorschrift gemäß Kapitel Tabelle zur Darstellung der Verordnungen.	2013-03-27
Einnahmeende		2013-03-30
Einnahmedauer		2 Wochen
Dosierung		2 Einheiten, täglich 2 - 0 - 1 - 0, täglich
Art der Anwendung		Anwendung auf der Haut

Empfehlung zum Layout der Tabelle:
Geänderte Dosierungsinformationen

Einnahmestart	2013-03-27
Einnahmeende	2013-03-30
Einnahmedauer	2 Wochen
Dosierung	2 - 0 - 1 - 0, täglich
Art der Anwendung	Anwendung auf der Haut

6.3.3 Medikationsliste Sektion

Diese Sektion wird in Dokumentklasse „Medikationsliste“ verwendet.

6.3.3.1 Überblick

	EIS „Full Support“
Template ID	ELGA: 1.2.40.0.34.11.8.3.2.1
Parent Template ID	IHE PHARM Medication List Section: 1.3.6.1.4.1.19376.1.9.1.2.5
Titel der Sektion	Medikationsliste
Definition	Diese Sektion beinhaltet die Medikationsliste.
Codierung	LOINC: 10160-0, „History of medication use“
Konformität	[M]
Konformität Level 3	[M] ELGA MedikationVerordnung-Entry (1.2.40.0.34.11.8.1.3.1) und/oder ELGA MedikationAbgabe-Entry (1.2.40.0.34.11.8.2.3.1)

6.3.3.2 Spezifikation

Id

1.2.40.0.34.11.8.3.2.1

ref

elgabbr-

Gültigkeit

2014‑01‑31

Status

Aktiv

Versions-Label

Name

MedikationslistenSection

Bezeichnung

Medikationslisten Section

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.8.3.2.1

Klassifikation

CDA Section 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.11.8.1.3.1	Containment	Medikation Verordnung Entry eMedikation	DYNAMIC
1.2.40.0.34.11.8.2.3.1	Containment	Medikation Abgabe Entry eMedikation	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.8.3.2.1 Medikationslisten Section (2014‑01‑31)

ref

elgabbr-

Beispiel

Strukturbeispiel

<section>
  <templateId root="1.2.40.0.34.11.8.3.2.1"/>  
  <templateId root="1.3.6.1.4.1.19376.1.9.1.2.5"/>  
  
  <code code="10160-0" displayName="History of medication use" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  
  <title>Medikationsliste</title>  
  <text> ... Lesbarer Textbereich ... </text>  
  <entry>
    
    <templateId root="1.2.40.0.34.11.8.1.3.1"/>  </entry>  
  <entry>
    
    <templateId root="1.2.40.0.34.11.8.2.3.1"/>  </entry></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

(Med...ion)

@classCode

cs

0 … 1

F

DOCSECT

hl7:templateId

II

1 … 1

M

(Med...ion)

@root

uid

1 … 1

F

1.2.40.0.34.11.8.3.2.1

hl7:templateId

II

1 … 1

M

IHE PHARM Medication List Section

(Med...ion)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.9.1.2.5

hl7:id

II

0 … 1

(Med...ion)

Beispiel

Strukturbeispiel

hl7:code

CE

1 … 1

M

(Med...ion)

@code

CONF

1 … 1

F

10160-0

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@codeSystemName

1 … 1

F

LOINC

@displayName

1 … 1

F

History of medication use

hl7:title

ST

1 … 1

M

(Med...ion)

CONF

Elementinhalt muss "Medikationsliste" sein

hl7:text

ED

1 … 1

M

Information für den menschlichen Leser.

Siehe auch „Empfehlung zur Gestaltung im Falle von CDA Level 3“.

(Med...ion)

Auswahl

0 … *

Elemente in der Auswahl:

hl7:entry welches enthält Template 1.2.40.0.34.11.8.1.3.1 Medikation Verordnung Entry eMedikation (DYNAMIC)
hl7:entry welches enthält Template 1.2.40.0.34.11.8.2.3.1 Medikation Abgabe Entry eMedikation (DYNAMIC)

hl7:entry

Beinhaltet 1.2.40.0.34.11.8.1.3.1 Medikation Verordnung Entry eMedikation (DYNAMIC)

(Med...ion)

@typeCode

cs

0 … 1

F

DRIV

hl7:entry

Beinhaltet 1.2.40.0.34.11.8.2.3.1 Medikation Abgabe Entry eMedikation (DYNAMIC)

(Med...ion)

@typeCode

cs

0 … 1

F

DRIV

6.3.3.2.1 Textbereich der Sektion

6.3.3.2.1.1 Empfehlung zur Gestaltung im Falle von CDA Level 3

Die Gestaltung des Textbereichs der Sektion SOLL mit den folgenden Informationselementen und in Form und Layout wie folgt erfolgen.

Tabelle zur Darstellung der Medikationsliste
Für die Medikationsliste SOLLEN folgende Informationselemente in Tabellenform angegeben werden. Die Arzneimittel werden dabei wie folgt gruppiert:

nach Abgabe (nach Abgabedatum sortiert, beginnend mit der der aktuellsten Abgabe)
nach Verordnung (nach Ausstellungsdatum sortiert, beginnend mit der aktuellsten Verordnung)

Element		Generierungsvorschrift aus den Entries	Beispiel
Abgabe(n)
Folgende Datenfelder sind pro Abgabe vorhanden.
Arzneimittel		Falls ein Arzneimittel abgegeben wurde: <product/manufacturedProduct/manufacturedMaterial/name> Falls eine magistrale Zubereitung abgegeben wurde: magistrale Zubereitung: <product/manufacturedProduct/manufacturedMaterial/name>	„Lemocin – Lutschtabletten“ Oder „Magistrale Zubereitung: Lutschtabletten“
Wirkstoff(e)		In diesem Feld werden jene Wirkstoffe, welche dem Value Set „ELGA_Wirkstoffe_AGES_VS“ angehören, aneinandergereiht. <product/manufacturedProduct/manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:name>	CETRIMONIUM BROMID, LIDOCAIN, TYROTHRICIN
Packung(en)		<quantity/@value>	1
Menge/art		<product/manufacturedProduct/manufacturedMaterial/pharm:asContent/pharm:containerPackagedMedicine/pharm:capacityQuantity/@value> <product/manufacturedProduct/manufacturedMaterial/pharm:asContent/pharm:containerPackagedMedicine/pharm:capacityQuantity/@unit>	20 Stück
ATC-Klassifikation		In diesem Feld werden jene Wirkstoffe, welche dem Valueset „ELGA_whoATC_VS“ angehören, aneinandergereiht. <product/manufacturedProduct/manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:name> (<product/manufacturedProduct/ manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:code/@code>)	Cetrimonium (R02AA17), Tyrothricin (R02AB02), Lidocain ( R02AD02)
Dosierung²³		Dosierungsvariante 1: Tagesdosierung <doseQuantity/@value> <doseQuantity/@unit>²⁴, <effectiveTime[2]/period/@unit>²⁵ Dosierungsvariante 2: Einzeldosierung <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACM‘]/substanceAdministration/doseQuantity/@value>²⁶ - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACD‘]/substanceAdministration/doseQuantity/@value> - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACV‘]/substanceAdministration/doseQuantity/@value> - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘HS‘]/substanceAdministration/doseQuantity/@value>, täglich Dosierungsvariante 3: Tagesdosierung an bestimmten Tagen <doseQuantity/@value><doseQuantity/@unit>²⁷, <effectiveTime[2]/period/@unit>²⁸, wöchentlich, am Wochentag(<effectiveTime[2]/comp[1]/phase/@value>)²⁹, Wochentag(<effectiveTime[2]/comp[2]/phase/@value>), … Dosierungsvariante 4: Einzeldosierung an bestimmten Tagen <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACM‘]/substanceAdministration/doseQuantity/@value>³⁰ - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACD‘]/substanceAdministration/doseQuantity/@value> - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACV‘]/substanceAdministration/doseQuantity/@value> - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘HS‘]/substanceAdministration/doseQuantity/@value>, wöchentlich, am Wochentag(<entryRelationship[@typeCode=‘COMP‘]/substanceAdministration/effectiveTime/comp[1]/phase/@value>), Wochentag(<entryRelationship[@typeCode=‘COMP‘]/substanceAdministration/effectiveTime/comp[2]/phase/@value>), …	2 Einheiten, pro Tag 200 mg, pro Woche 2 - 0 - 1 - 0, pro Tag 1 - 0 - 0 - 0, pro Tag 2 Einheiten, pro Woche am Di, Do 200 mg, pro Woche am Mo, Mi, Fr 1 - 0 - 1 - 0,. pro Woche am Mo, Fr 2 - 1 - 1 - 0, pro Woche am Di
Abgabe am		<author[2]/time>	2013-03-26, 08:02:00
Einnahmestart³¹		<effectiveTime[1]/low/@value>	2013-03-27, 00:00:00
Einnahmeende³²		<effectiveTime[1]/high/@value>	2013-03-30, 23:59:59
Verordnet von
	Name	<author[1]/assignedAuthor/assignedPerson/name/prefix[@qualifier="AC"]> <author[1]/assignedAuthor/assignedPerson/name/given[1]> <author[1]/assignedAuthor/assignedPerson/name/given[2]> <author[1]/assignedAuthor/assignedPerson/name/family>, <author[1]/representedOrganization/name>	Dr. Max Franz Meier, Ordination Dr. Meier
	Fachgebiet	<author[1]/assignedAuthor/code@displayName>	Fachärztin/Facharzt für Chirurgie
	GDA-ID	<author[1]/assignedAuthor/id@extension>	822143
	Adresse	<author[1]/representedOrganization/addr/streetName> <author[1]/representedOrganization/addr/houseNumber>, <author[1]/representedOrganization/addr/postalCode> <author[1]/representedOrganization/addr/city>	Musterstraße 27/1, 1010 Wien
Abgegeben von
	Name	<author[2]/assignedAuthor/assignedPerson/name/prefix[@qualifier="AC"]> <author[2]/assignedAuthor/assignedPerson/name/given[1]> <author[2]/assignedAuthor/assignedPerson/name/given[2]> <author[2]/assignedAuthor/assignedPerson/name/family>, <author[2]/assignedAuthor/representedOrganization/addr/name>	Mag. Jürgen Mustermann, Wald Apotheke
	GDA-ID	<author[2]/assignedAuthor/id@extension>	529141
	Adresse	<author[2]/assignedAuthor/representedOrganization/addr/streetName> <author[2]/assignedAuthor/representedOrganization/addr/houseNumber>, <author[2]/assignedAuthor/representedOrganization/addr/postalCode> <author[2]/assignedAuthor/representedOrganization/addr/city>	Apothekenstraße 10, 1010 Wien
Ergänzende Informationen zur magistralen Zubereitung:		Falls das Element <entryRelationship[@typeCode=‘SUBJ‘]/act/code@code> den Wert „MAGZUB“ aufweist: $magzubCode = <entryRelationship[@typeCode=‘SUBJ‘]/act/text/reference@value > <text/content[@ID=$magzubCode >	Erythromycin 1.0, Ultrasicc ad 50,0
Ergänzende Information		Falls das Element <entryRelationship[@typeCode=‘SUBJ‘]/act/code@code> den Wert „ERGINFO“ aufweist: $erginfoCode = <entryRelationship[@typeCode=‘SUBJ‘]/act/text/reference@value > <text/content[@ID=$erginfoCode> Falls das Element <entry/code@code> die Werte FFP oder RFP aufweist, wird zusätzlich folgender Text angezeigt: Die Packungen wurden (noch) nicht vollständig abgegeben.	Lieferschwierigkeiten Die Packungen wurden (noch) nicht vollständig abgegeben.
Zusatzinformation Patient:		Falls das Element <entryRelationship[@typeCode=‘SUBJ‘]/act/code@code> den Wert „ZINFO“ aufweist: $zinfoCode = <entryRelationship[@typeCode=‘SUBJ‘]/act/text/reference@value > <text/content[@ID=$zinfoCode>	Bei Kreislaufproblemen den Arzt aufsuchen.
Alternative Einnahme:		Falls das Element <entryRelationship[@typeCode=‘SUBJ‘]/act/code@code> den Wert „ALTEIN“ aufweist: $alteinCode = <entryRelationship[@typeCode=‘SUBJ‘]/act/text/reference@value > <text/content[@ID=$alteinCode >	Einnahme bei Bedarf
Mögliche Arten der Anwendung:		Falls das Element <entryRelationship[@typeCode=‘SUBJ‘]/act/code@code> den Wert „ARZNEIINFO“ aufweist: $arzneiinfoCode = <entryRelationship[@typeCode=‘SUBJ‘]/act/text/reference@value > <text/content[@ID=$ arzneiinfoCode >	Buccale Anwendung, Anwendung in der Mundhöhle
Art der Anwendung³³		<routeCode/@displayName> Falls routeCode nicht vorhanden ist werden alle Anwendungsarten dargestellt: Falls das Element <entryRelationship[@typeCode=‘SUBJ‘]/act/code@code> den Wert „ARZNEIINFO“ aufweist: $arzneiinfo = <entryRelationship[@typeCode=‘SUBJ‘]/act/text/reference@value > <text/content[@ID=$arzneiinfo>	zum Einnehmen
Verordnungsdatum		<author[1]/time>	2013-03-25, 23:59:59
Therapieart		<entryRelationship[@typeCode=‘COMP‘]/code@displayname>	Einzelverordnung
Darreichungsform		<product/manufacturedProduct/manufacturedMaterial/pharm:formCode/@displayName>	Tablette
Verordnung(en)
Folgende Datenfelder sind pro Verordnung vorhanden.
Arzneimittel		Falls ein Arzneimittel abgegeben wurde: <product/manufacturedProduct/manufacturedMaterial/name> Falls eine magistrale Zubereitung abgegeben wurde: magistrale Zubereitung: <product/manufacturedProduct/manufacturedMaterial/name>	CIPROXIN FTBL 500MG oder „Magistrale Zubereitung: Lutschtabletten“
Wirkstoff(e)		In diesem Feld werden jene Wirkstoffe, welche dem Valueset „ELGA_Wirkstoffe_AGES_VS“ angehören, aneinandergereiht. <consumable/manufacturedProduct/manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:name>	CIPROFLOXACIN HYDROCHLORID
Packung(en)		<entryRelationship/supply/quantity/@value>	1
Menge/art		<consumable/manufacturedProduct/manufacturedMaterial/pharm:asContent/pharm:containerPackagedMedicine/pharm:capacityQuantity/@value> <consumable/manufacturedProduct/manufacturedMaterial/pharm:asContent/pharm:containerPackagedMedicine/pharm:capacityQuantity/@unit>	20 Stück
ATC-Klassifikation		In diesem Feld werden jene Wirkstoffe, welche dem Valueset „ELGA_whoATC_VS“ angehören, aneinandergereiht. <consumable/manufacturedProduct/manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:name> (<consumable/manufacturedProduct/manufacturedMaterial/pharm:ingredient/pharm:ingredient/pharm:code/@code>)	Ciprofloxacin (J01MA02)
Dosierung		Dosierungsvariante 1: Tagesdosierung <doseQuantity/@value> <doseQuantity/@unit>³⁴, <effectiveTime[2]/period/@unit>³⁵ Dosierungsvariante 2: Einzeldosierung <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACM‘]/substanceAdministration/doseQuantity/@value>³⁶ - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACD‘]/substanceAdministration/doseQuantity/@value> - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACV‘]/substanceAdministration/doseQuantity/@value> - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘HS‘]/substanceAdministration/doseQuantity/@value>, täglich Dosierungsvariante 3: Tagesdosierung an bestimmten Tagen <doseQuantity/@value> <doseQuantity/@unit>³⁷, <effectiveTime[2]/period/@unit>³⁸, wöchentlich, am Wochentag(<effectiveTime[2]/comp[1]/phase/@value>)³⁹, Wochentag(<effectiveTime[2]/comp[2]/phase/@value>), … Dosierungsvariante 4: Einzeldosierung an bestimmten Tagen <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACM‘]/substanceAdministration/doseQuantity/@value>⁴⁰ - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACD‘]/substanceAdministration/doseQuantity/@value> - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘ACV‘]/substanceAdministration/doseQuantity/@value> - <entryRelationship[substanceAdministration/effectiveTime/event/@code=‘HS‘]/substanceAdministration/doseQuantity/@value>, wöchentlich, am Wochentag(<entryRelationship[@typeCode=‘COMP‘]/substanceAdministration/effectiveTime/comp[1]/phase/@value>), Wochentag(<entryRelationship[@typeCode=‘COMP‘]/substanceAdministration/effectiveTime/comp[2]/phase/@value>), …	2 Einheiten, pro Tag 200 mg, pro Woche 2 - 0 - 1 - 0, pro Tag 1 - 0 - 0 - 0, pro Tag 2 Einheiten, pro Woche am Di, Do 200 mg, pro Woche am Mo, Mi, Fr 1 - 0 - 1 - 0,. pro Woche am Mo, Fr 2 - 1 - 1 - 0, pro Woche am Di
Einnahmestart		<effectiveTime[1]/low/@value>	2013-03-27, 00:00:00
Einnahmeende		<effectiveTime[1]/high/@value>	2013-03-30, 23:59:59
Verordnet von
	Name	<author/assignedAuthor/assignedPerson/name/prefix[@qualifier="AC"]> <author/assignedAuthor/assignedPerson/name/given[1]> <author/assignedAuthor/assignedPerson/name/given[2]> <author/assignedAuthor/assignedPerson/name/family>, <author/representedOrganization/name>	Dr. Max Franz Meier, Ordination Dr. Meier
	Fachgebiet	<author/assignedAuthor/code@displayName>	Fachärztin/Facharzt für Chirurgie
	GDA-ID	<author/assignedAuthor/id@extension>	822143
	Adresse	<author/representedOrganization/addr/streetName> <author/representedOrganization/addr/houseNumber>, <author/representedOrganization/addr/postalCode> <author/representedOrganization/addr/city>	Musterstraße 27/1, 1010 Wien
Ergänzende Informationen zur magistralen Zubereitung:		Falls das Element <entryRelationship[@typeCode=‘SUBJ‘]/act/code@code> den Wert „MAGZUB“ aufweist: $magzubCode = <entryRelationship[@typeCode=‘SUBJ‘]/act/text/reference@value > <text/content[@ID=$magzubCode >	Erythromycin 1.0, Ultrasicc ad 50,0.
Ergänzende Information		Falls das Element <entryRelationship[@typeCode=‘SUBJ‘]/act/code@code> den Wert „ERGINFO“ aufweist: $erginfoCode = <entryRelationship[@typeCode=‘SUBJ‘]/act/text/reference@value > <text/content[@ID=$erginfoCode>	Darf nicht mit Milch eingenommen werden
Zusatzinformation Patient:		Falls das Element <entryRelationship[@typeCode=‘SUBJ‘]/act/code@code> den Wert „ZINFO“ aufweist: $zinfoCode = <entryRelationship[@typeCode=‘SUBJ‘]/act/text/reference@value > <text/content[@ID=$zinfoCode>	Bei Kreislaufproblemen den Arzt aufsuchen.
Alternative Einnahme:		Falls das Element <entryRelationship[@typeCode=‘SUBJ‘]/act/code@code> den Wert „ALTEIN“ aufweist: $alteinCode = <entryRelationship[@typeCode=‘SUBJ‘]/act/text/reference@value > <text/content[@ID=$alteinCode >	Einnahme bei Bedarf
Mögliche Arten der Anwendung:		Falls das Element <entryRelationship[@typeCode=‘SUBJ‘]/act/code@code> den Wert „ARZNEIINFO“ aufweist: $arzneiinfoCode = <entryRelationship[@typeCode=‘SUBJ‘]/act/text/reference@value > <text/content[@ID=$ arzneiinfoCode >	Buccale Anwendung, Anwendung in der Mundhöhle
Art der Anwendung		<routeCode/@displayName> Falls routeCode nicht vorhanden ist werden allen Anwendungsarten dargestellt: Falls das Element <entryRelationship[@typeCode=‘SUBJ‘]/act/code@code> den Wert „ARZNEIINFO“ aufweist: $arzneiinfo = <entryRelationship[@typeCode=‘SUBJ‘]/act/text/reference@value > <text/content[@ID=$arzneiinfo>	zum Einnehmen
Verordnungsdatum		<author/time>	2013-03-25, 23:59:59
Therapieart		<entryRelationship[@typeCode=‘COMP‘]/code@displayname>	Einzelverordnung
Darreichungsform		<consumable/manufacturedProduct/manufacturedMaterial/pharm:formCode/@displayName>	Tablette

²³ Die Elemente der Dosierungsinformationen bei Abgaben sind in einem entryRelationShip/substanceAdministration Element abgebildet (siehe Kapitel 6.4.2.2.7).
²⁴ Wenn @unit nicht gegeben ist, ist das Wort „Einheiten“ anzugeben
²⁵ @unit ist gemäß Valueset „ELGA_MedikationFrequenz_VS“ auf den displayName zu übersetzen
²⁶ Wenn Element nicht vorhanden, ist 0 anzugeben
²⁷ Wenn @unit nicht gegeben ist, ist das Wort „Einheiten“ anzugeben
²⁸ @unit ist gemäß Valueset „ELGA_MedikationFrequenz“ auf den displayName zu übersetzen
²⁹ Wochentag(<Datum>) ist hier eine Funktion zur Ermittlung des Wochentags des angegebenen Datums (z.B. Mo für Montag)
³⁰ Wenn Element nicht vorhanden, ist 0 anzugeben
³¹ Einnahmestart bei Abgaben ist in einem entryRelationShip/substanceAdministration Element abgebildet (siehe Kapitel 6.4.2.2.7).
³² Einnahmeende bei Abgaben ist in einem entryRelationShip/substanceAdministration Element abgebildet (siehe Kapitel 6.4.2.2.7).
³³ Art der Anwendung bei Abgaben ist in einem entryRelationShip/substanceAdministration Element abgebildet (siehe Kapitel 6.4.2.2.7).
³⁴ Wenn @unit nicht gegeben ist, ist das Wort „Einheiten“ anzugeben
³⁵ @unit ist gemäß Valueset „ELGA_MedikationFrequenz_VS“ auf den displayName zu übersetzen
³⁶ Wenn Element nicht vorhanden, ist 0 anzugeben
³⁷ Wenn @unit nicht gegeben ist, ist das Wort „Einheiten“ anzugeben
³⁸ @unit ist gemäß Valueset „ELGA_MedikationFrequenz“ auf den displayName zu übersetzen
³⁹ Wochentag(<Datum>) ist hier eine Funktion zur Ermittlung des Wochentags des angegebenen Datums (z.B. Mo für Montag)
⁴⁰ Wenn Element nicht vorhanden, ist 0 anzugeben

Empfehlung zum Layout der Tabelle:

Abgabe(n)
Arzneimittel⁴¹			Wirkstoff(e)
Lemocin - Lutschtabletten			CETRIMONIUM BROMID, LIDOCAIN, TYROTHRICIN
Packung(en)	Menge/art	ATC-Klassifikation	Dosierung	Abgabe am	Einnahmestart	Einnahmeende
1	20 Stück	Cetrimonium (R02AA17)	2 – 0 – 1 – 0, täglich, Einnahme bei Bedarf	2013-03-26, 08:02:00	2013-03-27, 00:00:00	2013-03-30, 23:59:59
Verordnet von
Name			Fachgebiet		GDA-ID	Adresse
Dr. Max Franz Meier, Ordination Dr. Meier			Fachärztin/Facharzt für Chirurgie		822143	Musterstraße 27/1, 1010 Wien
Abgegeben von
Name			GDA-ID		Adresse
Mag. Jürgen Mustermann, Wald Apotheke			529141		Apothekenstraße 10, 1010 Wien

Ergänzende Information: Darf nicht mit Milch eingenommen werden. Zusatzinformation Patient: Bei Kreislaufproblemen den Arzt aufsuchen. Alternative Einnahme: Einnahme bei Bedarf Mögliche Arten der Anwendung: Buccale Anwendung, Anwendung in der Mundhöhle Verordnungsdatum: 2013-03-25, 23:59:59 Therapieart: Einzelverordnung Darreichungsform: Tablette

Arzneimittel			Wirkstoff(e)
Magistrale Zubereitung: Lutschtabletten			Erythromycin
Packung(en)	Menge/art	ATC-Klassifikation	Dosierung	Abgabe am	Einnahmestart	Einnahmeende
2	-	-	1 – 0 – 1 – 0, täglich	2013-03-26, 08:02:00	2013-03-27, 00:00:00	2013-03-30, 23:59:59
Verordnet von
Name			Fachgebiet		GDA-ID	Adresse
Dr. Max Franz Musterdoktor, Meier			Fachärztin/Facharzt für Chirurgie		822143	Musterstraße 27/1, 1010 Wien
Abgegeben von
Name			GDA-ID		Adresse
Mag. Jürgen Mustermann, Wald Apotheke			529141		Apothekenstraße 10, 1010 Wien

Ergänzende Information zur magistralen Zubereitung: Erythromycin 1.0, Ultrasicc ad 50,0 Art der Anwendung: zum Einnehmen Verordnungsdatum: 2013-03-25, 23:59:59 Therapieart: Einzelverordnung Darreichungsform: Salbe

Arzneimittel			Wirkstoff(e)
Parkemed 250 mg - Kapseln			MEFENAMINSÄURE
Packung(en)	Menge/art	ATC-Klassifikation	Dosierung	Abgabe am	Einnahmestart	Einnahmeende
0	10 Stück	Mefenaminsäure(M01AG01)	1 – 0 – 1 – 0, täglich	2013-03-26, 08:02:00	2013-03-27, 00:00:00	2013-03-30, 23:59:59
Verordnet von
Name			Fachgebiet		GDA-ID	Adresse
Dr. Max Franz Musterdoktor, Meier			Fachärztin/Facharzt für Chirurgie		822143	Musterstraße 27/1, 1010 Wien
Abgegeben von
Name			GDA-ID		Adresse
Mag. Jürgen Mustermann, Wald Apotheke			529141		Apothekenstraße 10, 1010 Wien

Ergänzende Information: Lieferschwierigkeiten Die Packungen wurden (noch) nicht vollständig abgegeben. Art der Anwendung: zum Einnehmen Verordnungsdatum: 2013-03-25, 23:59:59 Therapieart: Einzelverordnung Darreichungsform: Kapsel

Arzneimittel			Wirkstoff(e)
Parkemed 250 mg - Kapseln			MEFENAMINSÄURE
Packung(en)	Menge/art	ATC-Klassifikation	Dosierung	Einnahmestart	Einnahmeende
1	10 Stück	Mefenaminsäure(M01AG01)	2 – 0 – 1 – 0, täglich	2013-03-27, 00:00:00	2013-03-30, 23:59:59
Verordnet von
Name			Fachgebiet		GDA-ID	Adresse
Dr. Max Franz Musterdoktor, Meier			Fachärztin/Facharzt für Chirurgie		822143	Musterstraße 27/1, 1010 Wien
Abgegeben von
Name			GDA-ID		Adresse
Mag. Jürgen Mustermann, Wald Apotheke			529141		Apothekenstraße 10, 1010 Wien

Ergänzende Information: Darf nicht mit Milch eingenommen werden Zusatzinformation Patient: Bei Kreislaufproblemen den Arzt aufsuchen. Alternative Einnahme: Einnahme bei Bedarf Mögliche Arten der Anwendung: Buccale Anwendung, Anwendung in der Mundhöhle Verordnungsdatum: 2013-03-25, 23:59:59 Therapieart: Einzelverordnung Darreichungsform: Kapsel

Arzneimittel			Wirkstoff(e)
Magistrale Zubereitung: Lutschtabletten			CIPROFLOXACIN HYDROCHLORID
Packung(en)	Menge/art	ATC-Klassifikation	Dosierung	Einnahmestart	Einnahmeende
1	20 Stück	Ciprofloxacin (J01MA02)	2 – 0 – 1 – 0, täglich
Verordnet von
Name			Fachgebiet		GDA-ID	Adresse
Dr. Max Franz Meier, Ordination Dr. Meier			Fachärztin/Facharzt für Chirurgie		822143	Musterstraße 27/1, 1010 Wien
Abgegeben von
Name			GDA-ID		Adresse
Mag. Jürgen Mustermann, Wald Apotheke			529141		Apothekenstraße 10, 1010 Wien

Ergänzende Information zur magistralen Zubereitung: Ciprofloxacin Hydrochlorid 2.5 Art der Anwendung: zum Einnehmen Verordnungsdatum: 2013-03-25, 23:59:59 Therapieart: Einzelverordnung Darreichungsform: Tablette

⁴¹ In der Tabelle des narrativen Teils werden Arzneimittel chronologisch nacheinander angeführt.

6.3.4 Pharmazeutische Empfehlung Sektion

Diese Sektion wird in Dokumentklasse „Pharmazeutische Empfehlung“ verwendet.

6.3.4.1 Überblick

	EIS „Full Support“
Template ID	ELGA: 1.2.40.0.34.11.8.4.2.1
Parent Template ID	IHE PHARM Pharmaceutical Advice Section: 1.3.6.1.4.1.19376.1.9.1.2.2
Titel der Sektion	Pharmazeutische Empfehlung
Definition	Diese Sektion entspricht einer Korrekturmeldung zu einer bestehenden Verordnung oder Abgabe und enthält eine „Pharmazeutische Empfehlung“
Codierung	LOINC: 61357-0, „Medication Pharmaceutical Advice.Brief“
Konformität	[M]
Konformität Level 3	[M] ELGA MedikationPharmazeutischeEmpfehlung-Entry (1.2.40.0.34.11.8.4.3.1)

6.3.4.2 Spezifikation

Id

1.2.40.0.34.11.8.4.2.1

ref

elgabbr-

Gültigkeit

2014‑01‑31

Status

Aktiv

Versions-Label

Name

PharmazeutischeEmpfehlungSektion

Bezeichnung

Pharmazeutische Empfehlung Section

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.8.4.2.1

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.11.8.4.3.1	Containment	Medikation Pharmazeutische Empfehlung Entry eMedikation	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.8.4.2.1 Pharmazeutische Empfehlung Section (2014‑01‑31)

ref

elgabbr-

Beispiel

Strukturbeispiel

<section>
  <templateId root="1.2.40.0.34.11.8.4.2.1"/>  
  <templateId root="1.3.6.1.4.1.19376.1.9.1.2.2"/>  
  
  <code code="61357-0" displayName="Medication Pharmaceutical Advice.Brief" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>  
  <title>Pharmazeutische Empfehlung</title>  
  <text> ... Lesbarer Textbereich ... </text>  
  <entry typeCode="DRIV">
     :     
    <templateId root="1.2.40.0.34.11.8.4.3.1"/>     :   </entry></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

(Pha...ion)

@classCode

cs

0 … 1

F

DOCSECT

hl7:templateId

II

1 … 1

M

(Pha...ion)

@root

uid

1 … 1

F

1.2.40.0.34.11.8.4.2.1

hl7:templateId

II

1 … 1

M

IHE PHARM Pharmaceutical Advice Section

(Pha...ion)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.9.1.2.2

hl7:id

II

0 … 1

(Pha...ion)

Beispiel

Strukturbeispiel

hl7:code

CE

1 … 1

M

(Pha...ion)

@code

CONF

1 … 1

F

61357-0

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

@codeSystemName

1 … 1

F

LOINC

@displayName

1 … 1

F

Medication Pharmaceutical Advice.Brief

hl7:title

ST

1 … 1

M

(Pha...ion)

CONF

Elementinhalt muss "Pharmazeutische Empfehlung" sein

hl7:text

ED

1 … 1

M

Information für den menschlichen Leser. Siehe auch „Empfehlung zur Gestaltung im Falle von CDA Level 3“.

(Pha...ion)

hl7:entry

1 … *

R

Beinhaltet 1.2.40.0.34.11.8.4.3.1 Medikation Pharmazeutische Empfehlung Entry eMedikation (DYNAMIC)

(Pha...ion)

@typeCode

cs

0 … 1

F

DRIV

6.3.4.2.1 Textbereich der Sektion

6.3.4.2.1.1 Empfehlung zur Gestaltung im Falle von CDA Level 3

Tabelle zur Darstellung des Status
Die erste Tabelle stellt den Status der Pharmazeutischen Empfehlung dar. Die zugrundeliegenden Daten befinden sich im <entry/observation> Element.

Verordnung oder Abgabe	Dokumenten ID	Status
Wenn <entryRelationship[@typeCode=‘REFR‘]/substanceAdministration dann Verordnung Wenn < entryRelationship[@typeCode=‘REFR‘]/supply dann Abgabe	<entryRelationship[@typeCode=‘REFR‘] /substanceAdministration\| supply/ id/ @root> / <br/><entryRelationship[@typeCode=‘REFR‘]/substanceAdministration\|supply/id/@extension>	< code/@displayName>

Beispiel:

Verordnung oder Abgabe	Item ID	Status
Verordnung	1.2.40.0.10.1.4.3.4.2.2 / 4711	Änderung

Tabelle zur Darstellung der geänderten Verordnung (im Falle von Status = CHANGE zu einer Verordnung)
Siehe Spezifikation der Darstellung einer Verordnung im Kapitel Tabelle zur Darstellung der Verordnungen.

Tabelle zur Darstellung der geänderten Dosierungsinformationen bei einer Abgabe (im Falle von Status = CHANGE zu einer Abgabe)
Siehe Spezifikation der Darstellung geänderter Dosierungsinformationen im Kapitel Tabelle zur Darstellung der geänderten Dosierungsinformationen.

Tabelle zur Darstellung der geänderten Patienteninformationen bei einer Abgabe (im Falle von Status = CHANGE zu einer Abgabe)
Sind geänderte Patienteninformationen vorhanden (gemäß Kapitel geänderte Abgabe) müssen diese in einer gesonderten Tabelle angegeben werden.

Element	Generierungsvorschrift aus den Entries	Beispiel
Zusatzinformationen für den Patienten und alternative Einnahme	Generierungsvorschrift gemäß Kapitel Tabelle zur Darstellung der Verordnungen.	Die Dosierung ist genau einzuhalten! Nur alle 2 Wochen am Dienstag

Empfehlung zum Layout der Tabelle:
Geänderte Patienteninformationen

Zusatzinformationen für den Patienten und alternative Einnahme	Die Dosierung ist genau einzuhalten! Nur alle 2 Wochen am Dienstag

6.4 Maschinenlesbare Elemente

6.4.1 ELGA MedikationVerordnung-Entry

Template ID	ELGA: 1.2.40.0.34.11.8.1.3.1
Parent Template ID	HL7 CCD 3.9: 2.16.840.1.113883.10.20.1.24 IHE PCC Medications Entry: 1.3.6.1.4.1.19376.1.5.3.1.4.7 IHE PHARM Prescription Entry: 1.3.6.1.4.1.19376.1.9.1.3.2

Abbildung 3: CDA R-MIM (L-POCD_RM000040) Ausschnitt - Klassen um die Verordnung

Diese Abbildung zeigt die für die Verordnung relevanten R-MIM Klassen SubstanceAdministration, Consumable, entryRelationship. Die Reihenfolge der Attribute entsprechend Schema ist normativ.

6.4.1.1 Spezifikation

Id

1.2.40.0.34.11.8.1.3.1

ref

elgabbr-

Gültigkeit

2014‑09‑01

Andere Versionen mit dieser Id:

MedikationVerordnungEntryemed vom 2014‑01‑31

Status

Entwurf

Versions-Label

Name

MedikationVerordnungEntryemed

Bezeichnung

Medikation Verordnung Entry eMedikation

Kontext

Elternknoten des Template-Element mit Id 1.2.40.0.34.11.8.1.3.1

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 18 Templates

Benutzt	als	Name	Version
1.2.40.0.34.11.90012	Inklusion	Sbadm TemplateId Options	DYNAMIC
1.2.40.0.34.11.30006	Inklusion	Einnahmedauer	DYNAMIC
1.2.40.0.34.11.30007	Inklusion	Dosierungsvariante 1: Tagesdosierung effectiveTime	DYNAMIC
1.2.40.0.34.11.30008	Inklusion	Dosierungsvariante 2: Einzeldosierung	DYNAMIC
1.2.40.0.34.11.30009	Inklusion	Dosierungsvariante 3: Tagesdosierung mit Einnahmepause	DYNAMIC
1.2.40.0.34.11.30010	Inklusion	Dosierungsvariante 4: Einzeldosierung mit Einnahmepause	DYNAMIC
1.2.40.0.34.11.30037	Inklusion	Dosierungsvariante 1: Tagesdosierung doseQuantity	DYNAMIC
1.2.40.0.34.11.30039	Inklusion	Dosierungsvariante 2: Einzeldosierung doseQuantity	DYNAMIC
1.2.40.0.34.11.30041	Inklusion	Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity	DYNAMIC
1.2.40.0.34.11.30043	Inklusion	Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity	DYNAMIC
1.2.40.0.34.11.2.3.4	Containment	Arznei Entry (1.0.2+20220121)	DYNAMIC
1.2.40.0.34.11.90004	Inklusion	AuthorElements	DYNAMIC
1.2.40.0.34.11.30040	Inklusion	Dosierungsvariante 2: Einzeldosierung entryRelationship	DYNAMIC
1.2.40.0.34.11.30044	Inklusion	Dosierungsvariante 4: Einzeldosierung mit Einnahmepause entryRelationship	DYNAMIC
1.2.40.0.34.11.30033	Inklusion	Patient Instructions (2020.1)	DYNAMIC
1.2.40.0.34.11.30034	Inklusion	Pharmacist Instructions (2020.1)	DYNAMIC
1.2.40.0.34.11.30045	Inklusion	Therapieart	DYNAMIC
1.2.40.0.34.11.90013	Inklusion	ID des Containers	DYNAMIC

Beziehung

Version: Template 1.2.40.0.34.11.8.1.3.1 Medikation Verordnung Entry eMedikation (2014‑09‑01)

ref

elgabbr-

Beispiel

Strukturbeispiel

Item

DT

Kard

Konf

Beschreibung

Label

hl7:substanceAdministration

(Med...med)

@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

Constraint

Wiederholung der Komponente zur Aufnahme eines Einnahmezeitpunkts und -dosis bei Dosierungsvariante 2 und 4 höchstens einmal je Zeitcode!

Constraint

Konditionale Konformität für ID des Verordnungs-Entry Containers (Rezept-Dokument)

Element wird in Medikationsliste verwendet: Card 1..1 Conf M
Sonst NP

hl7:templateId

II

1 … 1

M

ELGA.

(Med...med)

@root

uid

1 … 1

F

1.2.40.0.34.11.8.1.3.1

hl7:templateId

II

1 … 1

M

HL7 CCD 3.9.

(Med...med)

@root

uid

1 … 1

F

2.16.840.1.113883.10.20.1.24

hl7:templateId

II

1 … 1

M

IHE PCC Medications Entry.

(Med...med)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.7

hl7:templateId

II

1 … 1

M

IHE PHARM Prescription Entry.

(Med...med)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.9.1.3.2

hl7:templateId

II

1 … 1

M

IHE PHARM Dosage Instructions.

(Med...med)

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

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

Es ist in jedem Fall die TemplateId für „Normal dosing“ (a) anzugeben (auch wenn keine strukturierten Dosierungsinformationen angegeben sind), außer es ist gemäß Kapitel „Dosierungsvarianten/Zeitpunkt(e) der Einnahme“ die Angabe von „Split dosing“ (b) vorgeschrieben

(Med...med)

@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

1 … 1

Dosierungsart: Normal (1.3.6.1.4.1.19376.1.5.3.1.4.7.1) oder Split (1.3.6.1.4.1.19376.1.5.3.1.4.9)

Elemente in der Auswahl:

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

hl7:templateId

II

… 1

M

(Med...med)

@root

uid

1 … 1

F

1.3.6.1.4.1.19376.1.5.3.1.4.7.1

hl7:templateId

II

… 1

M

(Med...med)

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

(Med...med)

wo [1]

@root

uid

1 … 1

R

@extension

st

1 … 1

R

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

Schematron assert

role

error

test

not(ancestor::hl7:ClinicalDocument/hl7:templateId[@root='1.2.40.0.34.11.8.3']) 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.11.8.1']) 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.11.8')]) or hl7:id[1]

Meldung

Für e-Medikation Dokumente muss die erste ID angegeben sein.

hl7:id

II

0 … 1

C

ID des MedikationVerordnungs-Entry.

(Med...med)

wo [2]

@root

uid

1 … 1

F

1.2.40.0.10.1.4.3.4.2.2

Wurzel OID der ID eines MedikationAbgabe-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 vor: Card 1..1 Conf M
Sonst: 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).

(Med...med)

Beispiel

Strukturbeispiel

hl7:reference

TEL

1 … 1

M

(Med...med)

@value

1 … 1

R

#vpos-{generierteID},
z.B.: #vpos-1

hl7:statusCode

CS

1 … 1

M

(Med...med)

@code

CONF

1 … 1

F

completed

Eingefügt

von 1.2.40.0.34.11.30006 Einnahmedauer (DYNAMIC)

Beispiel

Strukturbeispiel

<cda:ClinicalDocument>
  
  <cda:effectiveTime xsi:type="IVL_TS">
    <cda:low value="20110527000000+0200"/>    <cda:high nullFlavor="UNK"/>  </cda:effectiveTime></cda:ClinicalDocument>

Beispiel

Strukturbeispiel

<cda:ClinicalDocument>
  
  <cda:effectiveTime xsi:type="IVL_TS">
    <cda:width value="2" unit="wk"/>  </cda:effectiveTime></cda:ClinicalDocument>

Beispiel

Strukturbeispiel

<cda:ClinicalDocument>
  
  <cda:effectiveTime xsi:type="IVL_TS">
    <cda:low nullFlavor="UNK"/>    <cda:high nullFlavor="UNK"/>  </cda:effectiveTime></cda:ClinicalDocument>

Auswahl

0 … 1

Elemente in der Auswahl:

hl7:effectiveTime[1][hl7:low]
hl7:effectiveTime[1][hl7:width]
hl7:effectiveTime[1][@nullFlavor]

hl7:effectiveTime

IVL_TS

Zeitelement zur Dokumentation der Einnahmedauer.

(Med...med)

wo [1] [hl7:low]

hl7:low

TS

1 … 1

R

Zeitpunkt des Einnahmestarts.
Zugelassene nullFlavor: UNK

(Med...med)

hl7:high

TS

1 … 1

R

Zeitpunkt des Einnahmeendes.
Zugelassene nullFlavor: UNK

(Med...med)

hl7:effectiveTime

IVL_TS

Dauer der Einnahme, wenn Einnahmestart unbekannt

(Med...med)

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"

(Med...med)

@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

(Med...med)

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.11.30007 Dosierungsvariante 1: Tagesdosierung effectiveTime (DYNAMIC)
hl7:effectiveTime[2] eingefügt vom Template 1.2.40.0.34.11.30008 Dosierungsvariante 2: Einzeldosierung (DYNAMIC)
ein Element eingefügt vom Template 1.2.40.0.34.11.30009 Dosierungsvariante 3: Tagesdosierung mit Einnahmepause (DYNAMIC)
hl7:effectiveTime[2] eingefügt vom Template 1.2.40.0.34.11.30010 Dosierungsvariante 4: Einzeldosierung mit Einnahmepause (DYNAMIC)

Eingefügt

von 1.2.40.0.34.11.30007 Dosierungsvariante 1: Tagesdosierung effectiveTime (DYNAMIC)

hl7:effectiveTime

PIVL_TS

C

Zeitelement zur Aufnahme der Dosierungsvarianten 1 und 3.

(Med...med)

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.

(Med...med)

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

(Med...med)

wo [2]

Eingefügt

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

(Med...med)

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)

(Med...med)

hl7:period

PQ

1 … 1

R

(Med...med)

@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

(Med...med)

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.

(Med...med)

wo [not(@operator)]

hl7:phase

IVL_TS

1 … 1

R

Erstes Datum des entsprechenden Wochentags nach Einnahmebeginn (z.B.: 01.10.2013 -> Dienstag)

(Med...med)

hl7:period

PQ

1 … 1

R

(Med...med)

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

hl7:comp

PIVL_TS

0 … *

(Med...med)

wo [@operator='I']

@operator

cs

1 … 1

F

I

hl7:phase

IVL_TS

1 … 1

R

(Med...med)

hl7:period

PQ

1 … 1

R

(Med...med)

@value

1 … 1

F

1

@unit

cs

1 … 1

F

wk

Eingefügt

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

(Med...med)

wo [2]

Auswahl

… 1

Elemente in der Auswahl:

ein Element eingefügt vom Template 1.2.40.0.34.11.30037 Dosierungsvariante 1: Tagesdosierung doseQuantity (DYNAMIC)
hl7:doseQuantity eingefügt vom Template 1.2.40.0.34.11.30039 Dosierungsvariante 2: Einzeldosierung doseQuantity (DYNAMIC)
ein Element eingefügt vom Template 1.2.40.0.34.11.30041 Dosierungsvariante 3: Tagesdosierung mit Einnahmepause doseQuantity (DYNAMIC)
hl7:doseQuantity eingefügt vom Template 1.2.40.0.34.11.30043 Dosierungsvariante 4: Einzeldosierung mit Einnahmepause doseQuantity (DYNAMIC)

Eingefügt

von 1.2.40.0.34.11.30037 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

(Med...med)

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_VS (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

(Med...med)

wo [hl7:lowoder
hl7:high]

hl7:low

PQ

(Med...med)

@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_VS (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

(Med...med)

@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_VS (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.11.30039 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.

(Med...med)

Eingefügt

von 1.2.40.0.34.11.30041 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

(Med...med)

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_VS (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

(Med...med)

wo [hl7:lowoder
hl7:high]

hl7:low

PQ

(Med...med)

@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_VS (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

(Med...med)

@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_VS (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.11.30043 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.

(Med...med)

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

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:effectiveTime[2]

Meldung

effectiveTime[2] darf in den Dosierungsvariante 'Split dosing' nicht 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:repeatNumber

IVL_INT

1 … 1

R

Anzahl der Einlösungen.

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

(Med...med)

Beispiel

Strukturbeispiel

hl7:routeCode

CE

0 … 1

Art der Anwendung der Arznei.

(Med...med)

@codeSystem

CONF

0 … 1

F

1.2.40.0.10.1.4.3.4.3.4

Beispiel

Strukturbeispiel

hl7:consumable

1 … 1

M

Komponente zur Aufnahme der Arznei auf die sich der MedikationVerordnungs-Entry bezieht.
Beinhaltet 1.2.40.0.34.11.2.3.4 Arznei Entry (DYNAMIC)

(Med...med)

Beispiel

Strukturbeispiel

Eingefügt

0 … 1

C

von 1.2.40.0.34.11.90004 AuthorElements (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

Auswahl

0 … 1

Elemente in der Auswahl:

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

hl7:author

Verfasser des Dokuments.

(Med...med)

wo [not(@nullFlavor)]

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

hl7:functionCode

CE

0 … 1

Funktionscode des Verfassers des Dokuments

z.B: „Diensthabender Oberarzt“, „Verantwortlicher Arzt für Dokumentation“,„Stationsschwester“, …

Eigene Codes und Bezeichnungen können verwendet werden.

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

(Med...med)

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

(Med...med)

hl7:assignedAuthor

1 … 1

M

Organisation, in deren Auftrag der Verfasser des Dokuments die Dokumentation verfasst hat.

(Med...med)

@classCode

cs

0 … 1

F

ASSIGNED

Beispiel

hl7:id

II

1 … *

R

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

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

(Med...med)

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.

(Med...med)

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.

(Med...med)

Auswahl

1 … 1

Elemente in der Auswahl:

hl7:assignedPerson
hl7:assignedAuthoringDevice

hl7:assignedPerson

… 1

Personendaten des Verfassers des Dokuments.

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

(Med...med)

Eingefügt

von 1.2.40.0.34.11.90001 PersonElements (DYNAMIC)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

Name der Person

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

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

(Med...med)

hl7:assignedAuthoringDevice

… 1

(Med...med)

@classCode

cs

0 … 1

F

DEV

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:manufacturerModelName

SC

0 … 1

Hersteller und Modellbezeichnung des datenerstellenden Gerätes.

(Med...med)

hl7:softwareName

SC

0 … 1

Bezeichnung (und ggf Version) der datenerstellenden Software.

(Med...med)

hl7:representedOrganization

1 … 1

M

(Med...med)

Eingefügt

von 1.2.40.0.34.11.90002 OrganizationElements (DYNAMIC)

@classCode

0 … 1

F

ORG

@determinerCode

0 … 1

F

INSTANCE

hl7:id

II

0 … *

(Med...med)

hl7:name

ON

1 … 1

M

(Med...med)

hl7:telecom

TEL.AT

0 … *

(Med...med)

hl7:addr

AD

0 … 1

(Med...med)

hl7:author

Verfasser nicht bekannt/nicht anwendbar

(Med...med)

wo [@nullFlavor]

@nullFlavor

cs

1 … 1

F

NA

Beispiel

hl7:time

1 … 1

R

(Med...med)

@nullFlavor

cs

1 … 1

F

NA

hl7:assignedAuthor

1 … 1

R

(Med...med)

@nullFlavor

cs

1 … 1

F

NA

hl7:id

1 … 1

R

(Med...med)

@nullFlavor

cs

1 … 1

F

NA

Eingefügt

von 1.2.40.0.34.11.30040 Dosierungsvariante 2: Einzeldosierung entryRelationship (DYNAMIC)

E-Medikation

Inhaltsverzeichnis

1 Informationen über dieses Dokument

1.1 Allgemeines

1.2 Sprachliche Gleichbehandlung

1.3 Verbindlichkeit

1.4 Zielgruppe

1.5 Hinweis auf verwendete Grundlagen

1.6 Danksagung

1.7 Revisionsliste

1.8 Weitere unterstützende Materialien

1.9 Bedienungshinweise für die PDF-Version

1.10 Impressum

2 Harmonisierung

3 Einleitung

3.1 Ausgangssituation

3.1.1 e-Medikation

3.2 Zweck

3.3 Hierarchie der Implementierungsleitfäden

4 Anwendungsfälle

4.1 eMED-ID-Assertion anfordern

4.1.1 Beschreibung

4.1.2 Vorbedingung

4.1.3 Akteure

4.1.4 Ablauf

4.2 eMED-ID (Dokumenten-ID) anfordern

4.2.1 Beschreibung

4.2.2 Vorbedingung

4.2.3 Akteure

4.2.4 Ablauf

4.3 Verordnung(en) mit Rezept anlegen

4.3.1 Allgemein

4.3.2 Vorbedingung

4.3.3 Akteure

4.3.4 Ablauf

4.3.4.1 Ergebnis im Gutfall

4.3.4.2 Ergebnis im Fehlerfall

4.4 Rezept mit Verordnung(en) abrufen

4.4.1 Beschreibung

4.4.2 Vorbedingung

4.4.3 Akteure

4.4.4 Ablauf

4.4.4.1 Ergebnis im Gutfall

4.4.4.2 Ergebnis im Fehlerfall

4.5 Verordnung/Rezept stornieren

4.5.1 Beschreibung

4.5.2 Vorbedingung

4.5.3 Akteure

4.5.4 Ablauf

4.5.4.1 Ergebnis im Gutfall

4.5.4.2 Ergebnis im Fehlerfall

4.6 Verordnung/Rezept ändern

4.6.1 Beschreibung

4.6.2 Vorbedingung

4.6.3 Akteure

4.6.4 Ablauf

4.6.4.1 Ergebnis im Gutfall

4.6.4.2 Ergebnis im Fehlerfall

4.7 Abgabe mittels eMED-ID durchführen

4.7.1 Beschreibung

4.7.2 Vorbedingung

4.7.3 Akteure

4.7.4 Ablauf

4.7.4.1 Sonderfall

4.7.4.2 Ergebnis im Gutfall

4.7.4.3 Ergebnis im Schlechtfall

4.8 Abgabe über e-card durchführen

4.8.1 Beschreibung

4.8.2 Vorbedingung

4.8.3 Akteure

4.8.4 Ablauf

4.8.4.1 Sonderfall

4.8.4.2 Ergebnis im Gutfall

4.8.4.3 Ergebnis im Schlechtfall

4.9 Abgabe ohne Verordnung durchführen

4.9.1 Beschreibung

4.9.2 Vorbedingung

4.9.3 Akteure

4.9.4 Ablauf

4.9.4.1 Ergebnis im Gutfall