Quelltext der Seite IG:Medikationsmanagement

<!--

    Implementierungsleitfaden "elektronisches Medikations-Datenaustauschformat (eMDAF)"
  
-->
{{Infobox Dokument
|Title     = Medikationsmanagement<br/>auf Basis der HL7 Clinical Document Architecture Release 2
|Short     = Medikationsmanagement
|Namespace = cdamedmgmt
|Type      = Implementierungsleitfaden
|Version   = 1.11
|Date      = 20. August 2020
|Copyright = 2018-2020
|Status    = final
|Period    = Entwurf
|Verfahren = Standard zur Probe (STU)
|OID       = 2.16.840.1.113883.2.6.7.67
|Realm     = Deutschland
}}
{{Infobox Contributors Begin}}
{{Contributor | Logo = Gevko_logo_mit_claim_neu.jpg | Name = gevko GmbH | Location = Bonn }}
{{Contributor | Logo = Logo-Hcs.jpg | Name = Heitmann Consulting and Services GmbH, Gefyra GmbH | Location = Hürth}}
{{Contributor | Logo = hl7logo.jpg| Name = HL7 Deutschland e. V. | Location = Berlin }}
{{Infobox Contributors End}}

= Dokumenteninformationen=
==Dokumentenhistorie==
{{:Ballotbox_Medikationsmanagement}}

==Impressum==
Dieser Leitfaden ist im Rahmen des Projekts Digitales Gesundheitsnetzwerk (DiGeN) des AOK BV entstanden, im Interoperabilitätsforum und den Technischen Komitees von HL7 Deutschland e. V. vorgestellt und unterliegt dem Abstimmungsverfahren des Interoperabilitätsforums<ref>Abstimmungsverfahren (Regeln) des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Abstimmungsverfahren_(Regeln)</ref> und der Technischen Komitees von HL7 Deutschland e. V. <ref>HL7 Deutschland e. V. http://www.hl7.de</ref>.
{{HL7transclude| cdaab3:Disclaimer}}
{{HL7transclude| cdaab3:CopyrightNutzungsbedingungen}}

==Autoren==
*gevko GmbH, Bonn, vertreten durch Gwenda Elmen, Ralf Franke
*Dr. med. Kai U. Heitmann, HL7 Deutschland e.V., Heitmann Consulting and Services, Gefyra GmbH
*Daniel Roggors und Jörg Rupprecht (Product Owner, AOK Bayern)
*Andreas Mohr und Dr. Ulf Maywald (Nutzervertreter, AOK PLUS)
*Carl Schüler, Carmen Gaa, Oliver Lowens, Horst Kakuschke und Hanna Pfenning (Nutzervertreter AOK Baden-Württemberg, HÄVG Hausärztliche Vertragsgemeinschaft AG und MEDIVERBUND AG)
*Ulrich Henning (Nutzervertreter, AOK Nordost)
*Dr. med. Thies Eggers (Scrum Master, fbeta GmbH)

=Einleitung=

Das deutsche Gesundheitswesen ist aufgrund seiner sektoralen Abgrenzung von Informationsasymmetrien geprägt. Die Gesundheitsversorgung kann in Bezug auf Wechselwirkungen und Kontraindikationen im Kontext von Arzneimitteln weiter verbessert werden, indem die Kommunikation zwischen den Leistungserbringern untereinander und zwischen den Leistungserbringern und den Patienten optimiert wird. Derzeit werden für die strukturierte Dokumentation von Medikationsplänen verschiedene Formate und Spezifikationen genutzt. Diese ähneln einander in vielen Merkmalen, sind aber nicht vollständig interoperabel.

Im Rahmen des Projektes „Digitales Gesundheitsnetzwerk“ der AOK (DiGeN) werden Fachanwendungen erarbeitet, welche die Informationsflüsse von Medikationsdaten von und zwischen Leistungserbringern (Ärzte, Apotheken) sowie Austausch mit den Versicherten zum Ziel haben.
Die interdisziplinäre Arbeitsgruppe eMedikation, die aus 
*dem Projekt Digitales Gesundheitsnetzwerk (DiGeN), in der Arbeitsgruppe vertreten durch die Lead-AOKs AOK Baden-Württemberg, AOK Bayern, AOK Nordost und AOK PLUS,
*der HÄVG Hausärztliche Vertragsgemeinschaft AG,
*der MEDIVERBUND AG,
*der gevko GmbH und
*HL7 Deutschland
besteht hat in einem ersten Schritt einen gemeinsamen Nenner für ein zukünftiges Datenaustauschformat erarbeitet, dass die Bezeichnung eMDAF ("elektronisches Medikationsdatenaustauschformat") trägt.

Die Spezifikation eMDAF erfüllt einerseits die gesetzlichen (Mindest-)Anforderungen und ermöglicht andererseits gleichzeitig den Austausch von darüber hinaus gehenden Informationen (z.B. in besonderen Versorgungsformen), die für eine Akzeptanz der Leistungserbringer, insbesondere der Ärzte, entscheidend ist.
Das bestehende Projekt ARMIN wird mit einem Update der Schnittstelle S3C-MP auf eMDAF migriert.
Im Rahmen des Projektes Digitales Gesundheitsnetzwerk (DiGeN) des AOK-Systems wird ein Medikationsplanaustausch zuerst im Rahmen des Migrationsprojektes der AOK Nordost umgesetzt. Dabei wird primär das in den verbreiteten AIS und KIS vorhandene UKF-Format des BMP und eMP zum Einsatz kommen. Der vorliegende Anforderungskatalog stellt die Kompatibilität des eMDAF zum UKF sicher. Somit können die Anforderungen für das DiGeN-Migrationsprojekt durch das eMDAF erfüllt werden. Die erweiterten Funktionen für das eMDAF sehen den Nutzern in DiGeN dann auch zur Verfügung.
Die Fachanwendung HAUSKOMET der Elektronischen Arztvernetzung (EAV) in Baden-Württemberg
HAUSKOMET wird ab dem ersten Quartal 2020 das elektronische Medikationsdatenaustauschformat (eMDAF) einsetzen, welches im HL7 Implementierungsleitfaden Medikationsmanagement (http://wiki.hl7.de/index.php?title=IG:Medikationsmanagement) beschrieben ist. 
Mit dem Wechsel auf eMDAF verfolgen die Projektpartner der EAV (AOK Baden-Württemberg, MEDIVERBUND AG und HÄVG AG) das Ziel, ein einheitliches Datenaustauschformat bei unterschiedlichen Projekten zur Übermittlung von Medikationsinformationen zu verwenden


Durch den übergreifenden sowie interoperablen Austausch von Medikationsdaten soll die Wirtschaftlichkeit durch: 
*weniger Mehrfachverordnungen,
*die Qualität der Behandlung durch Vermeidung von stationären Aufenthalten aufgrund von Wechselwirkungen und Kontraindikationen,
*die Transparenz der Behandlung durch eine Historisierung von Medikationsinformationen,
*die technische Interoperabilität durch die Integration bereits bestehender Formate, 
*die inter- und intrasektorale Zusammenarbeit durch die Einbeziehung aller Leistungserbringer sowie des Versicherten in das Medikationsmanagement und die Akzeptanz aller Beteiligten durch den Verzicht auf papiergebundene Verfahren gesteigert werden.


Aus bisherigen Diskussionen mit verschiedenen Akteuren ergeben sich – unabhängig von dem gewählten Ansatz – folgende Zielsetzungen für Patient, Arzt und Software-Hersteller:
*Patienten und Ärzte möchten grundsätzlich einen vollständig, aktuell und einheitlichen Überblick der aktuellen Medikationsinformationen (inklusive der historischen Verlaufsmedikation) haben
*Patienten möchten, dass Ärzte immer über die aktuelle Medikation informiert sind und Änderungen, die sich seit dem letzten Arztbesuch ergeben haben, schnell erkennen und bewerten
*Ärzte möchten die Medikation in ihrem Software-System mit der Medikation aus anderen Systemen abgleichen und in ihrem System aktualisieren
*Ärzte möchten erkennen können, welche Änderungen seit dem letzten Kontakt erfolgt sind, um sie bewerten zu können
*Ärzte möchten in ihren bestehenden Arbeitsabläufen möglichst wenig Aufwand bei diesen Vorgängen haben, insbesondere sollen sie von ihrem System bei der Nutzung unterschiedlicher Medikationsformate (BMP, eMP und weitere Formate) unterstützt werden
*Ärzte möchten, dass ihre Software-Systeme möglichst kostengünstig bleiben
*Software-Hersteller möchten in verschiedenen Regionen und Projekten möglichst nur wenig Unterschiede in Implementierungsleitfäden und Anforderungskatalogen haben, um Kosten und Ressourcen in der Umsetzung zu sparen
*Patienten und Ärzte möchten in Regionen, bei denen sich Projekte überschneiden, eine möglichst interoperable Umsetzung mit wenig Unterschieden haben

Die teilnehmenden Institutionen der Arbeitsgruppe haben sich entschlossen, die vorliegende Spezifikation gemeinsam in ihren jeweiligen Versorgungsangeboten und dem krankenkassenspezifischen Teil der elektronischen Patientenakte zu nutzen. Damit steht die vorliegende Spezifikation für die Versorgung von mindestens 27 Millionen Versicherten allein in der AOK-Gemeinschaft zur Verfügung.

==Vorarbeiten==
Der vorliegende Implementierungsleitfaden berücksichtigt eine Reihe von Vorarbeiten aus dem nationalen und internationalen Umfeld.
* Die Basis des elektronisches Medikations-Datenaustauschformat (eMDAF) stellt der Medikationsplan Plus der HL7 Deutschland e.V. dar<ref> Patientenbezogener Medikationsplan PLUS http://wiki.hl7.de/index.php?title=IG:Patientenbezogener_Medikationsplan_Plus</ref>.
* Die einschlägigen inhaltlichen IHE-Profile (PRE, DIS, PADV, PML)<ref>IHE Pharmacy Profiles, http://www.ihe.net/Pharmacy</ref>, insbesondere das Template "Medications" 1.3.6.1.4.1.19376.1.5.3.1.4.7 im Rahmen des Technical Framework "Patient Care Coordination (PCC)" von IHE <ref>IHE Template "Medications" 1.3.6.1.4.1.19376.1.5.3.1.4.7, http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.4.7</ref>
* Den bundeseinheitlichen Medikationsplan (BMP)<ref>IHE Pharmacy Profiles, https://fachportal.gematik.de/spezifikationen/online-produktivbetrieb/</ref>. 
* Den elektronischen Medikationsplan (eMP)<ref>IHE Pharmacy Profiles, https://fachportal.gematik.de/spezifikationen/online-produktivbetrieb/</ref>. 

==Abgrenzung==
Dieser Leitfaden deckt eine Reihe von Themen nicht ab. Dazu gehören:
* Prozessbeschreibung
* Use Cases
* digitale Signatur
* Security
* Transport von CDA-Dokumenten
* Verwendung von XSL-Stylesheets

==Medikationsmanagement heute und morgen==
Sobald Medikationspläne zwischen verschiedenen Akteuren (Ärzte, Patienten) ausgetauscht werden, ergeben sich Fragen in Bezug auf das Medikationsmanagement des Patienten. 
<br />

Die AG eMedikation hat eine beispielhafte Liste von Szenarien erarbeitet, die durch das Datenaustauschformat unterstützt werden sollen:
*Neu anlegen der Medikation aufgrund eines therapeutischen Vorgehens 
*Absetzen eines Medikaments aufgrund eines therapeutischen Vorgehens
*Änderung der Medikation aufgrund einer Änderung des therapeutischen Vorgehens mit anderem Wirkstoff
*Änderung der Dosierung eines Arzneimittels
*Änderung der Wirkstärke eines Arzneimittels
*Änderung der Darreichungsform in eine gemäß Arzneimittelrichtlinie gleichwertige Darreichungsform
*Änderung bei Kombinationspräparaten, d.h. mehrere Wirkstoffe verschiedener Präparate werden als 1 Kombinationspräparat verordnet (oder ein Kombinationspräparat wird durch mehrere Präparate ersetzt)
*Wechsel eines Handelspräparats, Änderung in ein anderes Handelspräparat mit demselben Wirkstoff, Wirkstärke, Darreichungsform u. Packungsgröße
*Umsortierung von Zeilen bei Papierausdrucken wie z.B. BMP (Zeile 3 ist jetzt 4 und Zeile 4 ist jetzt 3)

Grundsätzlich können zwei verschiedene Ansätze unterschieden werden:
#Medikationsmanagement mit verteilter Verantwortung für die Koordination der Arzneimitteltherapie<br />Medikationsmanagement als Zusammenspiel von verschiedenen Gesundheitsdienstleistern wie Ärzten, Apothekern, die alle an der Arzneimittelversorgung des Patienten teilhaben und eigenständig Medikationsdaten dokumentieren. Grundlage dafür können sowohl die derzeit bestehenden gesetzlichen Vorgaben und kollektivvertraglichen Regelungen als auch Selektivverträge sein.
#Medikationsmanagement mit solitärer Verantwortung für die Koordination der Arzneimitteltherapie<br />Medikationsmanagement als Zusammenspiel von verschiedenen Gesundheitsdienstleistern wie Ärzten, Apothekern (und Patienten), dass durch einen einzigen Supervisor (Kurator) verantwortlich gepflegt wird aber von allen anderen im Sinne von Vorschlägen Richtung Supervisor zur Medikamentenversorgung beitragen. Eine solche Regelung der Aufgaben ist derzeit nur durch Selektivverträge zur erreichen. 

Mit dem elektronischen Medikationsplanaustauschformat (eMDAF) können beide Ansätze unterstützt werden. Die entsprechenden Anforderungen an die Funktionen in den Software-Systemen zur Sicherstellung dieses Zusammenspiels sind über regionale Vereinbarungen in den entsprechenden Projekten können den entsprechenden Kapitel des Anforderungskatalogs entnommen werden.

=Funktionale Beschreibung zum elektronisches Medikations-Datenaustauschformat (eMDAF)=
Der technischen Spezifikation liegt eine Analyse der funktionalen Anforderung zugrunde. Diese wurden im Tool ART-DECOR® dokumentiert.

Im Folgenden ist das "Medikationsmanagement" wiedergegeben, dass die Strukturen und Hierarchien der behandelten Datenelemente wiedergibt. Die Datenelemente sind mit einer Kardinalität angezeigt (0..1, 1..1 etc.) und erhalten auch die Angabe, ob es sich um ein unbedingt auzufüllendes Feld (M) oder ein verpflichtendes Feld (R) handelt. Datentypen werden ebenso dokumentiert, wie beispielsweise eine Messgröße (Quantität) oder eine Zeichenkette (String). Die umrandeten Zahlen sind Item-Nummern zur einfacheren Identifizierung der Datenelemente.

{{:2.16.840.1.113883.3.1937.99.61.48.4.2/hgraph}}

=Allgemeine Konzepte von Medikationsdaten=

==Begriffsdefinitionen==
Grundsätzlich werden folgende Definitionen verwendet:
* Identifier – werden grundsätzlich systemseitig vergeben und können, müssen aber nicht dem Nutzer angezeigt werden.
* Medikations-ID – Mit der Medikations-ID wird eine einzelne Medikation (Arzneimittel und zugehörige Angaben wie z.B. Dosierung) eindeutig identifiziert – diese bleibt stabil, auch wenn Änderungen z.B. der Dosierung erfolgen.
* Zeilen-ID – Die Zeilen-ID ist eine ID die eine Medikationszeile eindeutig innerhalb des Dokuments identifiziert identisch mit der Medikations-ID; kombiniert mit einer Regel aus einem Anforderungs- oder Funktionskatalog, in welchen Situationen eine neue Medikations-ID erforderlich wird.
* Sequenznummer – Eine intendierte Reihenfolge, in welcher Sortierung eine Liste von Medikationseinträgen in einem System dem Nutzer angezeigt werden sollen (Reihenfolge in der Dokumenten-Instanz bzw. Reihenfolge innerhalb einer Gruppierung).
* Therapieintentions-ID – Eine Therapieintentions-ID dient zur Zuordnung eines Medikationseintrags der Kategorie "Hinzugefügte Medikation" bzw. "Geänderte Medikation (inkl. Löschung)" zu einem Medikationseintrag der Kategorie "Bestand“. 
* Gruppierung – Die Zusammenfassung mehrerer Medikationen (bzw. ihrer ID‘s) unter einem bestimmten Begriff (z.B. Dauermedikation, Selbstmedikation) – dies ist zu unterscheiden von der Therapieintention.
* Historische Medikation – Dies bezeichnet einen Hinweis auf eine temporär oder dauerhaft abgesetzte Medikation, welche aber im Datenformat erscheint („ausgesetzt“).
* Zwischenüberschriften – Zwischenüberschriften werden zur Gliederung von Medikationsdaten verwendet. 
* Arzneimittel – Beschreibt Handelspräparat oder eine Rezeptur, d.h. das konkrete Mittel.
* Medikation – Beschreibt das Arzneimittel inkl. Einnahmehinweisen, etc.. 

==Wirkstoff-Kodierungen und Wirkstoff-Verordnungen==
Bei Verordnungen muss zwischen Arzneimittel-basierten und Wirkstoff-basierten Verordnungen unterschieden werden.
Bei Medikationsplänen haben sich in der Praxis in Deutschland bisher die Arzneimittel-basierten Medikationspläne durchgesetzt.

Für die weiteren Ausführungen sind nochmals folgende zwei Definitionen herauszustellen: 
* Arzneimittel – Beschreibt Handelspräparat oder eine Rezeptur, d.h. das konkrete Mittel.
* Medikation – Beschreibt das Arzneimittel inkl. Einnahmehinweisen, etc..

Die AG eMedikation unterstützt bewusst, neben dem Fokus auf Arzneimittel, auch die Abbildung von Wirkstoff-basierte Verordnungen.
;Hierfür können verschiedene Ansätze gewählt werden, die AG eMedikation hat sich für den folgenden Ansatz entschieden:
:1. Ergänzende Angabe von Inhaltsstoffen zu Arzneimitteln:
:*Die Angabe von Wirkstoffen ist ergänzend zu einem Arzneimittel möglich
:*Im Datenmodell kann bei jedem Eintrag eines Arzneimittels optional der oder die enthaltenen Wirkstoffe zusätzlich angegeben werden
:*Bei den Inhaltsstoffen kann außerdem noch zwischen aktiven Wirkstoffen und inaktiven Hilfsstoffen unterschieden werden
:*Das jeweilige System nennt den oder die Wirkstoffe unter Angabe des verwendeten Wirkstoffkatalogs
:*Gegebenenfalls können auch einheitliche, von allen Systemen zu nutzenden Wirkstoffkataloge vorgegeben werden
:<br />Grundsätzlich denkbar ist auch der folgende Ansatz:<br />
:2. Wirkstoff-Verordnung als Alternative zur Arzneimittelverordnung
:*Die Systeme haben die Möglichkeit, anstatt der Angabe eines Arzneimittels in einer Verordnung alternativ auch nur eine Verordnung auf Basis eines Wirkstoffes in der Medikationsdatenzusammenstellung zu nennen
:*Dies bedeutet, dass unter Umständen nur der Wirkstoff, aber nicht das entsprechende Handelspräparat angegeben werden
:*Im Datenmodell bedeutet das, dass Wirkstoffeinträge gleichberechtigt neben Arzneimitteleinträgen optional möglich sind.

==Extensionen – Innovationsspielräume dauerhaft ermöglichen==
Grundsätzlich ermöglicht die AG eMedikation Innovationsspielräume für Projekte zum Thema Medikation, AMTS, usw. – ohne dass dies sofort verpflichtend für alle anderen Systeme in der Fläche wird. 

Das Konzept der „Extensionen“ hat zum Ziel, genau diese Innovationsspielräume zu ermöglichen, die genaue Umsetzung von Extensionen ist allerdings noch auszugestalten.
Die AG eMedikation hat folgende Vorüberlegungen getätigt: 
*Extensionen sind der beste Mittelweg, um einerseits Innovationen, andererseits aber auch Vereinheitlichung in einem kontrollierten Rahmen umzusetzen
*Es muss grundsätzlich für Extensionen eine unabhängige Registrierungsstelle geben
*Für eine Registrierung müssen bestimmte Angaben getätigt werden
*Im Rahmen der Registrierung sollte geprüft werden, dass keine Inkonsistenzen zu bestehenden Datenfeldern und Extensionen entstehen. Die Wiederverwendung von Extensionen sollte dabei ermuntert werden.
*Eine Extension sollte zeitlich begrenzt sein (1-4 Jahre)
*Parallel sollte ein Prüfprozess mit dem Ziel erfolgen, die Extension in die Regelinhalte zu überführen 

Zu den Extensionen verweisen wir auch auf den Abschnitt ''CDA mit Informellen Erweiterungen'' im Kapitel ''CDA-Spezifikation''.

==Zielsetzung für komplexe Dosierangaben==
Das eMDAF sieht vor auch komplexere Dosierangaben zu ermöglichen, die über das „4er Schema (1-1-1-1) hinausgehen. Die Zielsetzung besteht darin, für die Nutzer die Möglichkeit zu schaffen, komplexere Medikationsschemata in einem elektronischen Format abbilden zu können. Weiterhin sollen unterstützende Systeme (z.B. zur Arzneimitteltherapiesicherheit / AMTS) diese Angaben auslesen und dem Nutzer (Arzt, Patient) eine ergänzende Hilfestellung anbieten.

Die AG eMedikation hat eine Sammlung von Mustern mit Beispielen zusammengetragen, die den Nutzen von komplexeren Dosierangaben verdeutlichen sollen – diese sind im Anhang beigefügt.

=Migrationspfade – der Weg zum konsolidierten Datenaustauschformat=
Die vorliegende Spezifikation bildet eine Übermenge der Inhalte bestehender Medikationsdatenaustauschformate ab. Bei dem Großteil der enthaltenen Datenfelder handelt es sich um übergreifende Inhalte, die Deckungsgleich zu bestehenden Medikationsplanformaten sind. Damit sind insbesondere die Dateninhalte des Bundeseinheitlichen Medikationsplans nach §31a SGB V und der Fachanwendung eMP/ AMTS Stufe A nach §291a SGB V, die den normativen Rahmen und somit die Grundlage der Medikationsdaten bilden, gemeint. 

Diese Daten bilden ebenfalls im eMDAF die Basis und werden um Dateninhalte ergänzt, die regional spezifische Versorgungskontexte, Best Practices aus Projekten oder internationale Standards abbilden. Diese sind in Form bestehender Medikationsplanformate bereits regional vorhanden und werden in den jeweiligen Versorgungsangeboten aktiv genutzt. Es handelt es sich um Erweiterungen, die regional Mehrwerte erzeugen oder für eine Region essentiell sind, um deren Versorgungsszenarien abzubilden. Durch die vorliegende Spezifikation sollen nun auch überregional Synergien erzeugt und Interoperabilität gewährleistet werden. 

Die in der AG eMedikation repräsentierten Institutionen stellen unter diesem Diskussionspunkt die Rahmenbedingungen ihrer Initiativen dar. Sie erläutern, wie eine Migration von der jeweiligen Region zu eMDAF umgesetzt werden kann, denn sie haben sich entschlossen, die vorgeschlagene Spezifikation für einen gemeinsamen und interoperablen Datenaustausch zu nutzen.

==AOK Nordost==
Die AOK Nordost strebt in ihrer Region mit dem Gesundheitsnetzwerk die Vernetzung der verschiedenen Leistungserbringergruppen über die Sektorengrenzen hinweg an. Dabei soll den Leistungserbringern der Zugang zum Gesundheitsnetzwerk niederschwellig angeboten werden, d.h. die Teilnahme am Gesundheitsnetzwerk ist auch ohne den Beitritt zu Selektivverträgen möglich. Der Austausch von Informationen zur Medikation soll ermöglicht werden, sobald dazu Daten in einer einheitlich strukturierten Form vorliegen. Dies ist derzeit beim BMP und eMP gegeben.

Als weiteren Schritt bietet die AOK Nordost den Vertragsärzten und Krankenhäusern im Rahmen von eLiSa - electronic Life Saver die Möglichkeit, Medikationschecks durchzuführen und somit die Arzneimitteltherapie zu optimieren. Die eLiSa-Software ermöglicht den Ärzten den Zugriff auf Daten der AOK-Nordost über verordneten Medikamente, Diagnosen, Behandlungen, Krankenhausaufenthalte, mitbehandelnde Ärzte und Heil- und Hilfsmittel, die aus den Leistungsabrechnungen vorliegen, Voraussetzung dafür ist die Teilnahme der Vertragsärzte bzw. Krankenhäuser und Versicherten an einem Selektivvertrag mit der dazugehörigen Einwilligung des Versicherten zur Datenübermittlung. Darüber hinaus wird die eLiSa-Software die im Gesundheitsnetzwerk verfügbaren Medikationsdaten den Ärzten bereitstellen, soweit der Versicherte dazu die Berechtigung erteilt.

Der eMDAF wird als Weiterentwicklung der bisher bekannten Medikationsplanformate den Leistungserbringern weitere Funktionen, die u.a. auf den Austausch über digitale Netzwerke ausgerichtet sind, anbieten. Dabei ist die Kompatibilität zu den bestehenden BMP und eMP gegeben. Die Nutzung des eMDAF bringt Vorteile für Leistungserbringer und Patienten, ist aber keine zwingende Voraussetzung zum Austausch von Medikationsdaten im Gesundheitsnetzwerk. Der eMDAF sichert auch die Kompatibilität zu anderen Medikationsplänen, die im Rahmen von ARMIN oder dem Hauskometen erstellt werden.

Über die eLiSa-Software sollen die Ärzte den eMDAF nutzen können. Durch die Implementierung des eMDAF in die Systeme der Leistungserbringer werden diesen auch dort die zusätzlichen Funktionen des eMDAF und eine optimierte Anbindung an das Gesundheitsnetzwerk zur Verfügung stehen.

==AOK Baden-Württemberg==
Die Fachanwendung HAUSKOMET (HAUSärztlich KOntrollierte MEdikamentöse Therapie) kommt in den Versorgungsverträgen (HZV-Vertrag und Facharztverträge) zwischen der AOK Baden-Württemberg, dem MEDIVERBUND und dem Hausärzteverband zum Einsatz. Bei HAUSKOMET handelt es sich um einen zentralen, durch den Hausarzt gepflegten Medikationsspeicher zu einem Patienten. FACHÄRZTE können lesend auf den Medikationsspeicher zugreifen und Ergänzungen in Form von Änderungsdatensätzen angeben. Haus- und Facharzt verantworten die Sicherheit der Pharmakotherapie gemeinsam, der Hausarzt entscheidet im Sinne eines finalen Editors (Kurator) über die Änderungsdatensätze und übernimmt diese in den Medikationsspeicher. 

Fokus von HAUSKOMET bildet der Arzt-zu-Arzt-Austausch von Medikationsinformationen auf elektronischen Weg auf Basis vollständig strukturierter Daten.
Damit ermöglicht HAUSKOMET die Schaffung einer Zusammenstellung von Medikationsinformationen, die vollständig maschinell weiterverabeitet werden können (z.B. im Rahmen von AMTS-Checks).

HAUSKOMET nutzt als Datenaustauschformat die fachlich relevante Teilmenge der Spezifikation eMDAF.

==AOK PLUS==
Die Arzneimittelinitiative Sachsen-Thüringen (ARMIN) ist ein gemeinsames Modellprojekt der Kassenärztlichen Vereinigungen und der Apothekerverbände beider Bundesländer sowie der AOK PLUS. Es sollen vorrangig die Sicherheit von Arzneimitteltherapien optimiert, Anwendungsrisiken bei der Medikamenteneinnahme minimiert und damit eine optimale Arzneimittelwirkung erzielt werden.  

Das Modellprojekt baut auf drei Modulen auf, welche seit Juli 2014 stufenweise in die Praxis umgesetzt wurden. Alle drei Module des Projekts sind darauf ausgerichtet, die Arzneimitteltherapie zu optimieren und Risiken bei der Arzneimitteleinnahme zu senken. Die Wirkstoffverordnung und der Medikationskatalog sind im Juni 2014 gestartet. Das Medikationsmanagement wurde im Januar 2015 eingeführt.

Für das ARMIN-Medikationsmanagement können sich Versicherte der AOK PLUS einschreiben, welche dauerhaft fünf oder mehr Arzneimittel einnehmen. In diesem Zusammenhang wird z. B. ein vollständiger, aktueller und elektronisch verfügbarer Medikationsplan der Gesamtmedikation erstellt, welcher u. a. als Grundlage zur Prüfung von Wechselwirkungen, Optimierung der Arzneimitteltherapie und der sicheren Anwendung der Medikamente dient. Sowohl die initiale Erarbeitung als auch die kontinuierliche Pflege des Medikationsplanes erfolgen gemeinsam durch den betreuenden Arzt und Apotheker.

Nach Veröffentlichung des eMDAF werden mit den Vertragspartnern des ARMIN-Vertrages und den Softwareherstellern die notwendigen Schritte zur Migration des bisher genutzten MPAF-Formates diskutiert und umgesetzt.


=CDA-Spezifikation=
Ein Medikationsmanagement-Dokument - wie andere Dokumente auch - setzt sich aus verschiedenen Teilen zusammen, dem Header mit 
* Informationen zum CDA-Dokument wie Id, Datum etc.,
* Informationen über die verschiedenen Beteiligten an einem Dokument wie Patient (Versicherter), Autor etc.,
* Informationen über Aktivitäten, die in Zusammenhang mit dem Dokument stehen (Gesundheitsdienstleistung),
Sowie dem Body
*mit Abschnitten für den Text (Sections)
*und maschinenlesbaren, strukturierten Information (Entries).

==Hierarchische Ansicht der Komponenten zum Medikationsmanagement-Dokument ==
Die folgende hierarchische Zusammenstellung gibt eine Übersicht über die einzelnen Komponenten des Medikationsmanagement-Dokuments.
 
{{:2.16.840.1.113883.3.1937.99.61.48.10.1/hgraph}}


Des Weiteren wird verwiesen auf die Ausführungen Abschnitt "Arztbriefstruktur" im Arztbrief Plus<ref name="abplus"> Implementierungsleitfaden "Arztbrief Plus", HL7 Deutschland 2017 http://download.hl7.de/documents/cdar2-arztbrief/ArztbriefPlus-v310.pdf</ref> zu Kardinalität, Konformität, NullFlavor und die besonderen Hinweise zur Verwendung von Identifikationen (IDs). Weitere Informationen werden im Folgenden gegeben.

==Besonderheiten bei der CDA-Spezifikation "elektronisches Medikations-Datenaustauschformat (eMDAF)"==

=== Erläuterungen zu Kardinalität, Konformität, NullFlavor===
Es wird auf die Erläuterungen andernorts zu den Themen
*Kardinalität, Konformität [http://wiki.hl7.de/index.php?title=v3dtr1:Kardinalitäten]
*NullFlavor [http://wiki.hl7.de/index.php?title=v3dtr1:NullFlavor]
hingewiesen.

===Besondere Hinweise zur Verwendung von Identifikationen (IDs)===
In diversen Templates ist die Angabe von identifizierenden Merkmalen möglich. Dabei sind beispielsweise gemeint
* Patienten, identifiziert über die Krankenversichertennummer (KVNR),
* Gesundheitsdienstleister, typischerweise identifiziert über die Lebenslange Arztnummer (LANR),
* Betriebsstätten, typischerweise identifiziert über die Betriebsstättennummer (BSNR),
* Institutionskennzeichen (IK) z. B. für Abrechnungen und Qualitätssicherungsmaßnahmen im Bereich der deutschen Sozialversicherung.

Hinweise zu den Identifikationen und Best Practive finden sich im Wiki des Interoperabilitätsforums<ref>Informationen zu LANR und BSNR http://wiki.hl7.de/index.php?title=LANR_und_BSNR</ref>, <ref>Best Practice Leitseite des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Kategorie:Best_practice</ref>.

====Krankenversichertennummer (KVNR)====
Die Krankenversichertennummer (KVNR) besteht im unveränderliche Teil aus insgesamt 10 Stellen, beginnend mit einem alphanumerischen Zeichen.

Die Krankenversichertennummer für einen Patienten wird im id-Element der Rolle (... etc.) in der @extension angegeben. Das Identifikationssystem hat die registrierte OID 1.2.276.0.76.4.8 (Versichertennummer, unveränderbarer Teil der Krankenversichertennummer zur Identifikation des Versicherten, gemaess §290 SGB V; für PKV Versicherte: gleich Versicherungsnummer) und wird im @root-Attribut gekennzeichnet.
<syntaxhighlight lang="xml" highlight="3">
<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <id root="1.2.276.0.76.4.8" extension="G970865268"/>
    ...
  </patientRole>
</recordTarget>
</syntaxhighlight>

==== Lebenslange Arztnummer (LANR)====
Die LANR für den entsprechenden Arzt wird im id-Element seiner Rolle (assignedEntity, assignedAuthor etc.) in der @extension angegeben. Das Identifikationssystem LANR hat die registrierte OID 1.2.276.0.76.4.16 und wird im @root-Attribut gekennzeichnet.
<syntaxhighlight lang="xml" highlight="2">
<assignedAuthor>
     <id root="1.2.276.0.76.4.16" extension="381259301"/>
    ...
</assignedAuthor >
</syntaxhighlight>
==== Betriebsstättennummer (BSNR)====
Die BSNR für die entsprechende Betriebsstätte wird im id-Element der Rolle (... etc.) in der @extension angegeben. Das Identifikationssystem BSNR hat die registrierte OID 1.2.276.0.76.4.17 und wird im @root-Attribut gekennzeichnet.
<syntaxhighlight lang="xml" highlight="2">
<representedOrganization>
      <id root="1.2.276.0.76.4.17" extension="981069211"/>
      <name>Beispiel Betriebsstätte</name>
</representedOrganization>
</syntaxhighlight>
====Institutionskennzeichen (IK)====
Für die Angabe eines Institutionskennzeichens enthält im id-Element das @extension Attribut das Institutionskennzeichen (IK) und @root = 1.2.276.0.76.4.5, die OID für IK-Nummern in Deutschland
<syntaxhighlight lang="xml" highlight="2">
<scopingOrganization>
      <id root="1.2.276.0.76.4.5" extension="302205023"/>
      <name>Beispiel Krankenhaus</name>
</scopingOrganization >
</syntaxhighlight>

====Apotheken-IDF====
Für die Angabe einer Apotheken-IDF enthält im id-Element das @extension Attribut die 7-stellige Identifikationsnummer und @root = 1.2.276.0.76.4.197, die OID für IDF-Nummern in Deutschland
<syntaxhighlight lang="xml" highlight="2">
<scopingOrganization>
      <id root="1.2.276.0.76.4.197" extension="3379589"/>
      <name>Beispiel Apotheke</name>
</scopingOrganization >
</syntaxhighlight>

===Set-ID und Versionsnummer===
Als Besonderheit kann hervorgehoben werden, dass die im Header befindlichen Attribute
* setId
* versionNumber
als Identifikations- und Versionierungsattribute für die Gesamtheit aller Medikationsinformationen zu einem Patienten gehandhabt werden. Die ''setId'' (eine OID oder UUID) ist dabei für alle Medikationsinformations-Dokumente eines Patienten gleich, jede neue Version führt dazu, dass ''versionNumber'' um eins erhöht wird.

Davon losgelöst hat natürlich jedes neue Medikationsinformations-Dokument eine neue Dokumenten-Identifikation in ''ClinicalDocument.id''.

===CDA mit Informellen Erweiterungen===
In CDA gibt es die Möglichkeit, Informationen, die nicht oder nur sehr umständlich im CDA-Modell unterzubringen sind, in so genannten Informellen Erweiterungen (informal extensions) unterzubringen. Diese werden in einem XML CDA-Instanzendokument in einem eigenen XML Namespace geführt.

In dieser Spezifikation werden an drei Stellen solche Informellen Erweiterungen genutzt:
*Bei Wirkstoff- und Packungsangaben zum Medikament
*Bei den so genannten Druckkennzeichen
*Bei vorhaben-spezifischen Erweiterungen/Zusatzinformationen

====Wirkstoff- und Packungsangaben beim Medikament====
Im Bereich der Informationen über das Medikament werden Wirkstoff- und Packungsangaben durch die offizielle HL7 Erweiterung der Pharmacy Working Group angegeben. Diese von der HL7 Pharmacy Workgroup definierten CDA-Erweiterungen für Pharmacy werden unter der XML-Namensraumkennung <code>urn:hl7-org:pharm</code> behandelt und verwenden in der Regel das Namespacepräfix <code>pharm:</code>.

====Druckkennzeichen====
Im Kontext des Ausdrucks von Medikationsplänen (für den Patienten) taucht das Kennzeichen auf, ob ein Datenitem auf dem Plan erscheinen soll bzw. darf oder ob es nicht gedruckt wird. Dieses als „Druckkennzeichen“ bezeichnetes Flag (ja/nein) erscheint als Informelle Erweiterung immer im Kontext des Datenelements, für das dieses Druckkennzeichen gilt (siehe Beispiel). Es wird in CDA-Dokumenten unter der XML-Namensraumkennung <code>urn:hl7-de:medmgmt</code> behandelt und verwendet in der Regel das Namespacepräfix <code>medmgmt:</code>.

Die Erweiterungen folgen im Wesentlichen den Definitionen der Extensions in FHIR (https://www.hl7.org/fhir/extensibility.html), so dass ein solches Element immer die URI angibt, wo die Definition der Erweiterung hinterlegt ist, gefolgt durch einen Wert vom Typ Boolean oder String. Nur, wenn diese Erweiterung genannt ist und gleichzeitig den Wert „false“ enthält, wie im Beispiel unten angeben, wird das Element, in dessen Kontext diese Extension verwendet wird, nicht gedruckt.

Beispiel
<syntaxhighlight lang="xml">
<medmgmt:extension url="http://fhir.de/StructureDefinition/druckkennzeichen/0.2">
    <medmgmt:valueBoolean value="false"/>
</medmgmt:extension>
</syntaxhighlight>

====Vorhaben-spezifische Erweiterungen/Zusatzinformationen====
In Projekten rund um die Medikationsversorgung hat sich der Wunsch manifestiert, vorhaben-spezifische Erweiterungen/Zusatzinformationen nutzen zu können, die auch nur im Rahmen eines Projekts nutzbar sind. Es wird in CDA-Dokumenten unter der XML-Namensraumkennung <code>urn:hl7-de:medmgmt</code> behandelt und verwendet in der Regel das Namespacepräfix <code>medmgmt:</code>. Für diese Erweiterungen gilt ebenfalls, dass sie der Definitionen der Extensions in FHIR folgen, so dass ein solches Element die URI angibt, wo die Definition der Erweiterung hinterlegt ist, gefolgt durch einen Wert vom Typ Boolean oder String.

Beispiel
<syntaxhighlight lang="xml">
<medmgmt:extension url="http://fhir.de/StructureDefinition/vorhabenerweiterung/0.2">
  <medmgmt:extension url="http://fhir.de/StructureDefinition/vorhabenerweiterung-typ/0.2">
    <medmgmt:valueString value="Typ der vorhabenspezifischen Zusatzinformation"/>
  </medmgmt:extension>
  <medmgmt:extension url="http://fhir.de/StructureDefinition/vorhabenerweiterung-wert/0.2">
    <medmgmt:valueString value="Wert der vorhabenspezifischen Zusatzinformation"/>
  </medmgmt:extension>
</medmgmt:extension>
</syntaxhighlight>

==Einsatz im Kontext von HAUSKOMET==
Innerhalb des Implementationsleitfadens ist für HAUSKOMET ein spezifisches Document Level Template namens "CDA Medikationsmanagement Hauskomet" spezifiziert, das für CDA Dokumente zum Austausch von Medikationsinformationen im Kontext von HAUSKOMET zu verwenden ist.

Folgende Übersicht zeigt die im Kontext von HAUSKOMET verfügbaren Komponenten des Medikationsmanagement-Dokuments:
 
{{:2.16.840.1.113883.3.1937.99.61.48.10.35/hgraph}}

==Hinweise zu den Darstellungen der Templates==
Im folgenden Abschnitt dieser Spezifikation werden alle Templates aufgeführt. Die Darstellung der Definitionen erfolgt in Tabellenform. Weitere Hinweise, die möglicherweise für das Verständnis der Template-Definitionen nötig sein könnten, finden sich in englischer Sprache auf den Erläuterungsseiten von ART-DECOR<ref>ART-DECOR: How to read ART-DECOR Definitions [https://art-decor.org/mediawiki/index.php?title=How_to_read_ART-DECOR_Definitions]</ref>.

<div class="landscape">

=CDA Document Level Templates=
== CDA Dokument für Medikationsmanagement ==
{{:2.16.840.1.113883.3.1937.99.61.48.10.1/dynamic}}
== CDA Dokument für Medikationsmanagement Hauskomet ==
{{:2.16.840.1.113883.3.1937.99.61.48.10.35/dynamic}}

=CDA Header Level Templates=
==CDA countryCode (medmgmt) ==
{{:2.16.840.1.113883.3.1937.99.61.48.10.22/dynamic}}
==CDA recordTarget (medmgmt) / Patient ==
{{:2.16.840.1.113883.3.1937.99.61.48.10.4/dynamic}}
==Pflegearzt (Kurator) ==
{{:2.16.840.1.113883.3.1937.99.61.48.10.25/dynamic}}

=CDA Section Level Templates=
==Aktuelle Medikation (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.15/hgraph}}
{{:2.16.840.1.113883.3.1937.99.61.48.10.15/dynamic}}
==Allergien und Unverträglichkeiten (medmgmt)==
Die Spezialisierung ist nur dadurch notwendig geworden, dass hier Erweiterungen (Extensions) vorgesehen werden mussten.
{{:2.16.840.1.113883.3.1937.99.61.48.10.16/hgraph}}
{{:2.16.840.1.113883.3.1937.99.61.48.10.16/dynamic}}
==Gesundheitsbelange (medmgmt)==
Die Spezialisierung ist nur dadurch notwendig geworden, dass hier in den zugehörigen Entries Erweiterungen (Extensions) vorgesehen werden mussten.
{{:2.16.840.1.113883.3.1937.99.61.48.10.11/hgraph}}
{{:2.16.840.1.113883.3.1937.99.61.48.10.11/dynamic}}
==Klinische Parameter (medmgmt)==
Die Spezialisierung ist nur dadurch notwendig geworden, dass hier und in den zugehörigen Entries Erweiterungen (Extensions) vorgesehen werden mussten.
{{:2.16.840.1.113883.3.1937.99.61.48.10.10/hgraph}}
{{:2.16.840.1.113883.3.1937.99.61.48.10.10/dynamic}}
==Leistungserbringer-Kommentar ==
{{:1.2.276.0.76.10.3133/hgraph}}
{{:1.2.276.0.76.10.3133/dynamic}}
==Sozialanamnese (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.23/hgraph}}
{{:2.16.840.1.113883.3.1937.99.61.48.10.23/dynamic}}

=CDA Entry Level Templates=
==Alkoholabusus (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.33/dynamic}}
==Alkoholgebrauch (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.26/dynamic}}
==Allergie/Unverträglichkeit Concern Act (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.31/dynamic}}
==Allergie/Unverträglichkeit Observation (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.30/dynamic}}
==AMTS Prüfung==
{{:2.16.840.1.113883.3.1937.99.61.48.10.20/dynamic}}
==Datenerfassung ==
{{:2.16.840.1.113883.3.1937.99.61.48.10.2/dynamic}}
==Datenübermittlung==
{{:2.16.840.1.113883.3.1937.99.61.48.10.24/dynamic}}
==Einnahmedauer (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.36/dynamic}}
==Einzeldosierungen (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.28/dynamic}}
==Grund für Medikation (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.29/dynamic}}
==Kreatinin (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.9/dynamic}}
==Körpergewicht (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.7/dynamic}}
==Körpergröße (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.8/dynamic}}
==Laborergebnis (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.34/dynamic}}
==Medikation (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.3/dynamic}}
==Medikation Gruppierung (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.14/dynamic}}
==Status Schwangerschaft (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.12/dynamic}}
==Stillzeit (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.13/dynamic}}
==Tabakgebrauch (medmgmt)==
{{:2.16.840.1.113883.3.1937.99.61.48.10.27/dynamic}}

= Templates aus Repositories (nicht zur Abstimmung stehend)=

Die folgenden Templates stehen im Rahmen dieses Leitfadens nicht zur Abstimmung, da sie aus anderen Repositories entlehnt wurden.
* [[1.2.276.0.76.10.2019]] CDA authenticator
* [[1.2.276.0.76.10.2029]] CDA author (pmp)
* [[1.2.276.0.76.10.2030]] CDA custodian (pmp)
* [[1.2.276.0.76.10.2011]] CDA participant Notfallkontakt
* [[1.2.276.0.76.10.2012]] CDA participant Hausarzt
* [[1.2.276.0.76.10.2019]] CDA authenticator
* [[1.2.276.0.76.10.2020]] CDA legalAuthenticator
* [[1.2.276.0.76.10.2030]] CDA custodian (pmp)
* [[1.2.276.0.76.10.2031]] CDA author software (pmp)
* [[1.2.276.0.76.10.3042]] Wichtige Angaben
* [[1.2.276.0.76.10.4015]] Annotation Comment
* [[1.2.276.0.76.10.4024]] Dosierung Freitext
* [[1.2.276.0.76.10.4025]] Medikament
* [[1.2.276.0.76.10.4026]] Patienteninstruktionen
* [[1.2.276.0.76.10.4027]] Grund für Medikation
* [[1.2.276.0.76.10.4254]] Laborergebnis
* [[1.2.276.0.76.10.4255]] Erwarteter Geburtstermin
* [[1.2.276.0.76.10.4256]] Allergie/Unverträglichkeit Concern Act
* [[1.2.276.0.76.10.4257]] Allergie/Unverträglichkeit Observation
* [[1.2.276.0.76.10.4258]] Reaktion/Manifestation
* [[1.2.276.0.76.10.4259]] Kritikalität
* [[1.2.276.0.76.10.4292]] Grund für Nichtgabe Medikation
* [[1.2.276.0.76.10.4295]] Ohne Medikation
* [[1.2.276.0.76.10.4297]] Leistungssportler
* [[1.2.276.0.76.10.90002]] CDA realmCode
* [[1.2.276.0.76.10.90003]] CDA typeId
* [[1.2.276.0.76.10.90004]] CDA id
* [[1.2.276.0.76.10.90005]] CDA title
* [[1.2.276.0.76.10.90006]] CDA effectiveTime
* [[1.2.276.0.76.10.90007]] CDA confidentialityCode
* [[1.2.276.0.76.10.90008]] CDA languageCode
* [[1.2.276.0.76.10.90009]] CDA setId and versionNumber
* [[1.2.276.0.76.10.90010]] CDA Person Elements
* [[1.2.276.0.76.10.90011]] CDA Organization Elements
* [[1.2.276.0.76.10.90012]] CDA Assigned Entity Elements
* [[1.2.276.0.76.10.90014]] Performer (Body)
* [[1.2.276.0.76.10.90020]] RelatedEntity (Body)
* [[1.2.276.0.76.10.90022]] Material
* [[1.2.276.0.76.10.90023]] Einnahmedauer
* [[1.2.276.0.76.10.90024]] Patientenidentifikation
* [[1.2.276.0.76.10.90025]] Author (Body)
* [[1.2.276.0.76.10.90028]] Medikation Vorbedingung
* [[1.2.276.0.76.10.90030]] Personenname
* [[2.16.840.1.113883.3.1937.777.27.10.2]] Kuratierender Arzt (Medikationseintrag)
* [[2.16.840.1.113883.3.1937.777.27.10.12]] Hauskomet Kategorie
* [[2.16.840.1.113883.3.1937.777.27.10.17]] Medikation Therapie-Intention (Hauskomet)

</div>

=Terminologien=
==Value Sets==
===Medikationseintrag Kategorie===
{{:2.16.840.1.113883.3.1937.99.61.48.11.2/dynamic}}
===Medikationsmanagement-Codes===
{{:2.16.840.1.113883.3.1937.99.61.48.11.1/dynamic}}

=Anhang=
{{:cdamedp:Dosierbeispiele}}

=Literatur und Referenzen=
==Weiterführende Literatur==
Folgende Literatur ist zum Verständnis des Leitfadens hilfreich:

*"The CDA-Book", Keith Boone, Springer
* HL7 Datentypleitfaden

==Glossar und Abkürzungsverzeichnis==
Für ein Glossar der Begriffe wird auf die "Enzyklopädie des deutschen Gesundheitswesens" bei Interoperabilitätsforum verwiesen:
http://wiki.hl7.de/index.php?title=Kategorie:Enzyklopädie

Das Interoperabilitätsforum führt auch ein Abkürzungsverzeichnis:
http://wiki.hl7.de/index.php?title=Kategorie:Abkürzungen

==Referenzen==
<references/>
==Abbildungen==
<references group="Abbildung" />
Zurzeit keine.

== Tabellen==
<references group="Tabelle" />
Zurzeit keine.

[[Kategorie:IG]]