652
Bearbeitungen
Änderungen
keine Bearbeitungszusammenfassung
''Medieneigentümer, Herausgeber, Hersteller, Verleger:''<br />
ELGA GmbH, Treustraße 35-43, Wien, Österreich. Telefon: +43.1.2127050<br />
Internet: [[http://www.elga.gv.at |www.elga.gv.at]]<br />Email: [[mailto:cda@elga.gv.at |cda@elga.gv.at]]
''Abbildungen:'' © ELGA GmbH
''Nutzung'': Das Dokument enthält geistiges Eigentum der Health Level Seven® Int. und HL7® Austria, Franckstrasse 41/5/14, 8010 Graz; [[http://www.hl7.at |www.hl7.at]].<br />
Die Nutzung ist ohne Lizenz- und Nutzungsgebühren zum Zweck der Erstellung medizinischer Dokumente ausdrücklich erlaubt. Andere Arten der Nutzung und auch auszugsweise Wiedergabe bedürfen der Genehmigung des Medieneigentümers.
Download unter [[https://www.gesundheit.gv.at |www.gesundheit.gv.at]] und [[https://www.elga.gv.at/cda |www.elga.gv.at/cda]]
</div></div>
==Verwendete Grundlagen und Bezug zu anderen Standards==
Grundlage dieses Implementierungsleitfadens ist der internationale Standard "HL7 Clinical Document Architecture, Release 2.0" (CDA ©), für die das Copyright © von Health Level Seven International<ref name="HL7">Health Level Seven International [http://www.hl7.org www.hl7.org]</ref> gilt. 2009 wurde die Release 2.0 als ISO-Standard ISO/HL7 27932:2009 publiziert<ref>ISO/HL7 27932:2009 Data Exchange Standards — HL7 Clinical Document Architecture, Release 2 [https://www.iso.org/standard/44429.html]</ref>.
CDA definiert die Struktur und Semantik von "medizinischen Dokumenten" zum Austausch zwischen Gesundheitsdiensteanbietern und Patienten. Es enthält alle Metadaten zur Weiterverarbeitung und einen lesbaren textuellen Inhalt und kann diese Informationen auch maschinenlesbar tragen. Das Datenmodell von CDA und seine Abbildung in XML<ref>World Wide Web Consortium. Extensible Markup Language, 1.0, 5th Edition. [http://www.w3.org/TR/REC-xml]</ref> folgen dem Basisstandard HL7 Version 3<ref>HL7 Version 3 Product Suite [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=186]</ref> mit seinem Referenz-Informationsmodell (RIM). Dieser Leitfaden verwendet das HL7-Template-Austauschformat zur Definition der "Bausteine" (Templates) und ART-DECOR® <ref>ART-DECOR® [https://art-decor.org www.art-decor.org]</ref> als Spezifikationsplattform.
* HL7 Clinical Document Architecture (CDA) <ref name="CDA"> HL7 Clinical Document Architecture (CDA) [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7]</ref>
* HL7 Referenz-Informationsmodell (RIM)<ref name="RIM">HL7 Version 3: Reference Information Model (RIM) [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=77]</ref>
* HL7 V3 Datentypen <ref name="HL7 Version 3 Standard: Data Types">HL7 Version 3 Standard: Data Types – Abstract Specification, Release 2[http://www.hl7.org/documentcenter/private/standards/v3/edition_web/infrastructure/datatypes_r2/datatypes_r2.html]</ref>
* HL7 Template-Austauschformat Specification and Use of Reusable Information Constraint Templates, Release 1<ref name="Templates Specification"> HL7 Templates Standard: Specification and Use of Reusable Information Constraint Templates, Release 1 [http://www.hl7.org/implement/standards/product_brief.cfm?product_id=377] </ref>
Die HL7 Standards können über die HL7 Anwendergruppe Österreich (HL7 Austria)<ref>HL7 Austria [http://www.hl7.at/ www.hl7.at]</ref>, die offizielle Vertretung von Health Level Seven International in Österreich bezogen werden ([https://www.hl7.at 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.
{{BeginILFBox}}
Die e-Medikation basiert auf den Vorgaben des '''[[ILF:Allgemeiner_Implementierungsleitfaden_2020|Allgemeinen Implementierungsleitfadens (Version 3)]]'''.{{EndILFBox}}
Für die Modellierung der technischen Spezifikation der Inhalte wurde bei dieser Hauptversion der e-Medikation die [[https://art-decor.ehdsi.eu/art-decor/decor-templates--epsos- |Art-Decor Spezifikation des eHDSI CDA Leitfaden für "eHDSI ePrescription" und "eHDSI eDispensation"]] als wesentliche Grundlage gewählt, um eine "Abwärtskompatibilität" herzustellen. Das Bedeutet, das jedes e-Medikation Rezept CDA nach eHDSI e-Prescrition ePrescription Spezifikation valide ist und jede jedes e-Medikation Abgabe CDA nach eHDSI e-Dispensation eDispensation Spezifikation valide ist. Für eine tatsächliche Übertragung in den eHDSI Kontext wären jedoch Transformations-Schritte notwendig! Darunter fallen die Auftrennung jeder Verordnungen in einzelne Rezepte, die Auftrennung von jedem Abgabe-Entry in eine eigene Abgabe wie auch das Herausextrahieren der Informationen der Pharmazeutischen Empfehlung als einzelne ePrescritions ePrescription oder eDispensations. Zusätzlich sind Übersetzungen von Terminologien notwendig. Man beachte jedoch das andersrum, nicht jede eHDSI ePrescription oder eHDSI eDispensation valdie zur e-Medikation Spezifikation sind!
==Wichtige unterstützende Materialien==
* Schematron-Dateien für die Prüfung der Konformität ("Richtigkeit") von CDA Dateien
Die im weiteren angeführten Templatespezifikationen wurden im Art-Decor Projektrepository [[https://art-decor.org/art-decor/decor-templates--at-emed-?section=templates |e-Medikation]] erstellt und können dort eingesehen werden.
{{EndYellowBox}}
Gemeinsam mit diesem Leitfaden werden in diesem Wiki weitere Dokumente zur Unterstützung bereitgestellt:
* Leitfaden zur richtigen Verwendung von Terminologien
{{BeginYellowBox}}Fragen, Kommentare oder Anregungen für die Weiterentwicklung können an [[mailto:cda@elga.gv.at |cda@elga.gv.at]] gesendet werden.{{EndYellowBox}}
==Bedienungshinweise==
Die Leitfäden werden über ein reguläres Standardisierungsverfahren ("Ballot") durch die HL7 Anwendergruppe Österreich (HL7 Austria) zu einem nationalen HL7 Standard.
{{BeginILFBox}}
Weitere Details zum Vorgehensmodell sind im [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Vorgehensmodell| Allgemeiner Leitfaden - Kapitel Leitfadenerstellungs- und Harmonisierungsprozess - Vorgehensmodell]] zu finden.{{EndILFBox}}
Dieser Implementierungsleitfaden entstand durch die Harmonisierungsarbeit der [[AG e-Medikation v3]], die im ''Zeitraum von September 2024 bis Dezember 2024 tagte.'' Die Teilnehmer der Arbeitsgruppe wurden durch ihre Organisation delegiert.
Der Leitfaden wird in einem technischen Abstimmungsverfahren durch die HL7 Austria ("Ballot") zu einem österreichischen Standard. Die Verbindlichkeit zur Anwendung soll durch eine Novellierung des Gesundheitstelematikgesetzes 2012, BGBl.I Nr.111/2012 begründet werden.
Der CDA-Koordinator evaluiert in regelmäßigen Abständen, ob und welche Änderungen (etwa durch neue medizinische oder gesetzliche Anforderungen) notwendig sind. Aufgrund des Berichtes des CDA-Koordinators empfiehlt die ELGA GmbH die Erstellung von Revisionsversionen der bestehenden Leitfäden. Die geplanten Änderungen sollen mit den maßgeblichen Stakeholdern abgestimmt werden.
Neue Versionen, die "verpflichtende Elemente" (Sections oder Entries) neu einführen oder entfernen, sind "Hauptversionen", die jedenfalls über eine Durchführungsverordnung verbindlich gemacht und veröffentlicht werden. Andere Versionen sind "Nebenversionen". Alle verbindlichen Versionen sind auf http://www.gesundheit.gv.at zu veröffentlichen.
== Autoren und Mitwirkende ==
=Technischer Hintergrund=
{{BeginILFBox}}
Der technische Hintergrund soll im [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Technischer_Hintergrund| allgemeinen Leitfaden]] nachgelesen werden.{{EndILFBox}}
==Allgemeine Richtlinien für ELGA CDA-Implementierungsleitfäden==
==Anwendungsfälle des Dokumentenmanagements==
Die folgenden Kapiteln aus dem allgemeinen Leitfaden stellen eine Zusammenfassung der Inhalte der ELGA-Gesamtarchitektur, des Leitfadens XDS Metadaten und Usability Styleguides zum Thema e-Befunde dar. Detailinformationen sind in den entsprechenden Dokumenten nachzulesen (verfügbar auf der Homepage der [[https://www.elga.gv.at/ |ELGA GmbH]]). Die wesentlichen Anwendungsfälle sind
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Schreiben_und_Einbringen_von_Dokumenten|Schreiben und Einbringen von Dokumenten]]
*[[ILF:Allgemeiner_Implementierungsleitfaden_2020#Versionierung_von_Dokumenten|Versionierung von Dokumenten]]
** In der e-Medikation erfolgt keine Unterscheidung in stationären und ambulanten Bereich.
* Akteure in der Apotheke
** Pharmazeut/In** Pharmazeutisch-kaufmännisch(er/e) AssistentInAssistent
* 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
* Verordnung
** OFFEN
** EINGELOESTEINGELÖST
** STORNIERT
** NICHT_DISPENSIERT
Die Erfassung eines Rezepts mit Verordnung stellt folgende Prozessschritte in der GDA- Software dar:
* Arzneimittel auswählen: Der Arzt wählt eine oder mehrere Arzneimittelspezialitäten aus einem Katalog („ASP-Liste“, die Liste der humanen Arzneispezialitäten gelistet nach PZN) aus, wobei Handelsname, Pharmazentralnummer (PZN) sowie andere Daten zur Beschreibung des Arzneimittels (Stärke, Darreichungsform, Packungsgröße, Zulassungsnummer etc.) automatisch aus einem Katalog6 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)
* Rezept drucken (Anforderung an die GDA-Software, kein Teil in der e-Medikation). Die eMED-ID soll, sofern technisch möglich, sowohl als Klartext als auch als maschinenlesbarer Code (2D-Matrix-Code) auf dem e-Rezept-Ausdruck bzw. einem Papierrezept aufgedruckt werden (§18 Abs. 4 Z. 4 GTelG 2012) um die Versorgungskontinuität (verbesserte Arbeitsabläufe) als auch die anwenderfreundlichen Umsetzung der e-Medikation zu unterstützen.
Der Arzt kann pro „Patientenkontakt“ (Besuch) mehrere Rezepte mit Verordnungen in e- Medikation speichern; Rezepte können jedoch nur einzeln übermittelt werden. Das Rezept mit den Verordnungen ist sofort nach Speicherung in e-Medikation gültig.
Das Rezept wird durch eine Rezeptart gekennzeichnet, um die Gültigkeitsdauer prüfen zu können. In e-Medikation werden folgende Rezeptarten berücksichtigt:
* Privatrezept - 12 Monate gültig, sofern die erste Einlösung innerhalb von 1 Monat ab Erstelldatum erfolgt ist
** Die maximale Gültigkeitsdauer beträgt 365 Tage bzw. sind bis zu 6 Einlösungen möglich, wobei Gültigkeitsdauer und Anzahl der möglichen Einlösungen vom Arzt definiert werden können. Dabei muss das Privatrezept innerhalb des ersten Monats erstmalig eingelöst werden (§ 4 Abs. 1 RezeptpflichtG).
* Substitutionsrezept – Maximale Gültigkeitsdauer von 12 Monaten. Das "GültigVon " Datum darf maximal einen Monat in der Zukunft liegen.
Es ist nicht möglich, zusätzliche Einlösungen anzugeben.
Die Gültigkeitsdauer je Rezeptart folgt den rechtlichen Vorgaben. Es wird daher der Ausstellungstag in die Berechnung der Einlösefrist nicht mit eingerechnet. Die Gültigkeiten von Rezepten und somit die Verfügbarkeit in e-Medikation ergeben sich folgendermaßen:
* Wenn ein Rezept mit den Verordnungen in e-Medikation gespeichert ist, dann erhält dasRezept/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.
* Bei Kassen- und Substitutionsrezepten müssen alle Verordnungen mit einer Abgabe oder Leerabgabe referenziert werden.
Die am Rezept angegebenen Verordnungen sind im Status OFFEN in e-Medikation gespeichert. Die zuvor vom Server erstellte eMED-ID wurde für die Dokumentenerstellung verwendet und dem e-Rezept Service als Parameter übergeben.
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
Es gibt keine Einschränkung bei der Anzeige der Datenfelder (z.B. ausstellender GDA darf angezeigt werden). Es werden über die Schnittstelle alle verfügbaren Datenfelder zu einer Verordnung/Rezept geliefert (lt. Datenmodell).
Im Gutfall werden dem Akteur die angeforderten Rezepte/ Verordnungen sowie die dazugehörigen Korrekturmeldungen („Pharmazeutischen Empfehlungen“) zurückgeliefert und stehen zur weiteren Verwendung zur Verfügung.
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden.
Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
====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“STORNIERT. Eine Stornierung ist nur zulässig, falls die referenzierte Verordnung bereits in e-Medikation vorhanden ist und den Status „OFFEN“ OFFEN besitzt. Bereits abgegebene Verordnungen können nicht mehr verändert werden.
* Ganzes Rezept stornieren:
** Ein Rezept gilt als storniert, wenn einer der folgenden beiden Methoden angewandt wird:
*** Der Akteur bestimmt das Rezept mit den Verordnungen (über eMED-ID). Es wird ein Update der Metadaten des Rezepts ausgeführt. Dies kann nur vom Ersteller des Rezepts durchgeführt werden.
Die Verordnung bzw. das Rezept erhalten den Status= STORNIERT.
===Verordnung/Rezept ändern===
Der Aussteller des Rezepts mit der entsprechenden Verordnung bleibt gleich und darf nicht durch die Änderung der Verordnung verändert werden.
Im Gutfall wird die Änderung der Datenfelder der Verordnung über eine Korrekturmeldung durchgeführt und in e-Medikation gespeichert.
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Die in e-Medikation gespeicherte Verordnung wurde nicht verändert.
Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
* Zu Rezepten mit dem Status ABGELAUFEN können keine Abgaben mehr gespeichert werden. Die (nachträgliche) Speicherung von Abgaben zu einem abgelaufenen Rezept kann im Anlassfall allerdings ohne Verordnungsbezug erfolgen (siehe Kapitel xxx).
Wird ein Arzneimittel verordnet, welches in der Apotheke nicht vorhanden ist, so kann im Rahmen der gesetzlichen Bestimmungen, der Apotheker bzw. der hausapotheken- führende Arzt ein wirkstoffgleiches Arzneimittel bzw. nach Rücksprache mit dem Arzt ein alternatives Arzneimittel abgeben.
Jedenfalls ist das tatsächlich abgegebene Arzneimittel in e-Medikation zu speichern und der Verordnung/dem Rezept zuzuordnen, um die Zugrundeliegende Verordnung einzulösen.
Der Prozess einer „Teilabgabe“ eines Rezeptes kann mit obiger Logik des „Besorgers“ auch abgebildet werden.
* Erfolgt die Abgabe eines OTC auf Basis einer Verordnung, wird die Abgabe immer in e-Medikation gespeichert, auch wenn dieses OTC nicht in der ASP-Liste als wechselwirkungsrelevante Arzneispezialität geführt ist.
* Erfolgt die Abgabe eines OTC ohne Verordnungsbezug (siehe Kapitel „Abgabe ohne Verordnungsbrzug Verordnungsbezug durchführen“), darf die Abgabe nur in e-Medikation gespeichert werden, wenn dieses OTC in der ASP-Liste als wechselwirkungsrelevante Arzneispezialität geführt ist.
Die Verordnung ist eingelöst und die Medikationsabgabe ist gespeichert. Die Verknüpfung von Verordnung und Abgabe ist vorhanden. Teilabgaben sind entsprechend markiert.
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Die in e-Medikation gespeicherte Verordnung wird nicht verändert.
====Ablauf====
Der Akteur erfasst die Medikationsabgabe. Die Prüfungen der Arzneimittel z.B. auf potentielle Wechselwirkungen, Kontraindikationen, Dosierungen etc. erfolgt in der Eigenverantwortung des Akteurs und ist nicht Gegenstand des Informationssystems „e- Medikation“.
Wenn eine Medikationsabgabe (ohne Rezept/Verordnung) in e-Medikation gespeichert wird, dann gilt die Medikationsabgabe als vom Akteur geprüft. Wenn ein e-Rezept-Eintrag oder ein Papierrezept ohne e-Medikations-Verordnung vorhanden ist, dann obliegt es dem abgebenden Akteur diese zu prüfen.
Im Rahmen der Nacherfassung von bereits erfolgten Abgaben wird als Erfassungsdatum der Zeitpunkt der Nacherfassung gesetzt, während als Abgabedatum das in der Vergangenheit liegende Datum der tatsächlichen Abgabe eingetragen wird.
Die Medikationsabgabe ist in e-Medikation gespeichert.
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden.
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.
Im Gutfall werden dem Akteur die angeforderten Medikationsabgaben als auch zugehörige Korrekturmeldungen zurückgeliefert und stehen zur weiteren Verwendung zur Verfügung.
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden.
Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
====Ablauf====
Der Akteur wählt die Medikationsabgabe, welche storniert werden soll. Die Stornierung von Abgaben ist jederzeit möglich. Die Abgabe erhält den Status=STORNIERT und kann nicht mehr abgerufen werden. Handelt es sich bei der Abgabe um eine Medikation mit Verordnungsbezug, dann wechselt der Status der Verordnung auf „OFFEN“oder OFFEN oder – falls der Gültigkeitszeitraum des zugrunde liegenden Rezepts überschritten wurde – auf „ABGELAUFEN“ABGELAUFEN
Im Gutfall wird die Stornierung der Medikationsabgabe durchgeführt. Die Abgabe erhält den Status STORNIERT, eine der Abgabe zugrunde liegende Verordnung den Status OFFEN oder ABGELAUFEN.
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden.
Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
Das Absetzen kann via Metadatenupdate der entsprechenden Pharmazeutischen Empfehlung wieder rückgängig gemacht werden.
Im Gutfall wird das Absetzen der Medikationsabgabe durchgeführt und in e-Medikation gespeichert (Status=ABGESETZT). Das Absetzdatum ist in den Abgabedatenfeldern vorhanden.
===Abgabe ändern===
====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
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.
Im Gutfall wird die Änderung der Medikationsabgabe durchgeführt und in e-Medikation gespeichert.
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
Die Medikationsliste wird bei Aufruf serverseitig erstellt und enthält die aktuell gültigen Abgaben bzw. Verordnungen (z.B. bei einer Änderung wird nur die geänderte Dosierung angezeigt).
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.
Im Fehlerfall wird der Vorgang abgebrochen und kann bei Bedarf wiederholt werden. Falls fehlerhafte Daten übergeben werden, muss eine Fehlermeldung zurückgeliefert werden mit dem Hinweis auf den Fehler.
====Alternativer Ablauf====
Bei der Ermittlung der aktuellen Medikation eines Patienten ist die Verwendung der konsolidierten Medikationsliste optional. Alternativ können alle die verfügbaren (Quell)Daten der e-Medikation (das sind die Dokumenten- klassen Rezept (Prescription), Abgabe (Dispense), und die entsprechenden Korrektur- meldungen Korrekturmeldungen bzw. Pharmazeutische Empfehlungen (Pharmaceutical Advice) separat entsprechend dem im IHE Pharmacy Profil definierten Abfragen („Queries“) abgerufen und in der lokalen Software weiterverarbeitet werden.
Dies hat den Vorteil, dass man auch die Historie der Änderungen sehen kann, welche in der Implementierung der Medikationsliste bereits eingearbeitet sind.
Die Struktur des CDA Austauschformats ist in den nachfolgenden Kapiteln im Detail beschrieben.
Der Header entspricht im Wesentlichen den bisherigen ELGA CDA-Leitfäden [[ILF:Allgemeiner_Implementierungsleitfaden_("Allgemeiner Version_3)#Dokumentenstruktur|Vorgaben im allgemeinen Leitfaden")]]. Der Body enthält die tatsächlichen (medizinischen) Inhalte des Dokuments. Dieses Dokument existiert ausschließlich in einer voll strukturierten Form, eine Unterscheidung der Interoperabilitätsstufen ist daher nicht notwendig.
==Übersichtstabelle der CDA Strukturen des Headers==
===Header Level Templates===
{{BeginILFBox}}Die Header Level Templates wurden großteils aus dem bestehenden "Allgemeiner Implementierungsleitfaden für ELGA CDA Dokumente" übernommen. Diese sind unter [[ILF:Allgemeiner_Implementierungsleitfaden_2020#Dokumentenstruktur| Allgemeiner Leitfaden - Kapitel Administrative Daten (CDA Header) - Dokumentenstruktur]] zu finden.{{EndILFBox}}
Die Header-Element welche spezifisch für die e-Medikation angepasst wurden sind folgende:
