IG:ERezept

eRezept auf Basis der
HL7 Clinical Document Architecture Release 2 und FHIR
für das deutsche Gesundheitswesen

eRezept

Implementierungsleitfaden

vorgelegt von:
.

in Arbeit

Version:	0.1
Datum:	10. Dezember 2018
Status:	Entwicklung
Verfahren:	{{{Verfahren}}}
Realm:	Deutschland

Copyright © 2018: HL7 Deutschland

Abstimmungsdokument
Version	Datum	Status	Realm
0.1	01.02.2019	in Arbeit	Deutschland
		noch kein download verfügbar

Kontributoren
	bvitg	Berlin
	HS Niederrhein	Krefeld
	DTHS	Essen
	medatixx	Eltville
	MediSoftware	Kiel

Dokumenteninformationen

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Impressum

Dieser Leitfaden wurde im Rahmen des Interoperabilitätsforums und der Technischen Komitees von HL7 Deutschland e. V. sowie der entsprechenden Projektgruppen erstellt und unterliegt dem Abstimmungsverfahren des Interoperabilitätsforums und der Technischen Komitees von HL7 Deutschland e. V.

Ansprechpartner und Autoren

• Elisabeth Pantazoglou, HS Niederrhein
• Frank Oemig, DTHS

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Copyright-Hinweis, Nutzungshinweise

Nachnutzungs- bzw. Veröffentlichungsansprüche

Für alle veröffentlichten Dateien mit einem CDA-Bezug gilt ferner: Alle abgestimmten und veröffentlichten Spezifikationen wie Implementierungsleitfäden, Stylesheets und Beispieldateien sind frei verfügbar und unterliegen keinerlei Einschränkungen, da die Autoren auf alle Rechte, die sich aus der Urheberschaft der Dokumente ableiten lassen, verzichten.

Alle auf nationale Verhältnisse angepassten und veröffentlichten CDA-Schemas können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.
Aus der Nutzung ergibt sich kein weiter gehender Anspruch gegenüber HL7 Deutschland e.V., zum Beispiel eine Haftung bei etwaigen Schäden, die aus dem Gebrauch der Spezifikationen bzw. der zur Verfügung gestellten Dateien entstehen.

Näheres unter http://www.hl7.de und http://www.hl7.org.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Einleitung

Ein wesentliches Element bei der Digitalisierung des Gesundheitswesens wird die elektronische Verordnung (eVerordnung)/ das elektronische Rezept (eRezept) darstellen. Der Aufbau für das Formular der Verordnung/ des Rezepts ist durch die Formularkommission der KBV im Muster 16 festgehalten. Die Verordnung/ das Rezept wird vom Vertragsarzt ausgestellt und enthält die Verordnung von Arznei- und Verbandmitteln, sowie Hilfsmitteln mit Ausnahme von Sehhilfen und Hörhilfen. Darüber hinaus gilt das Verordnungsformular für den patientenbezogenen Sprechstundenbedarf.

Dieser Leitfaden beschreibt, wie die fachlichen Inhalte des Musters 16 "Arzneiverordnungsblatt" (der Verordnung/ des Rezepts) in elektronischer Form vollständig auf Basis der HL7 Clinical Document Architecture (CDA) bzw. FHIR technisch abgebildet werden können.

Muster 16: Arzneiverordnungsblatt (eRezept)

Die Umsetzung fokussiert primär auf die Übertragung der im Muster 16 (s.u.) enthaltenen Daten.

Muster 16

Dieses Formular wird jedoch zur Realisierung mehrerer Anwendungsfälle (personenbezogenes Rezept, Sprechstundenbedarf, ..) genutzt, die nachfolgend näher erläutert werden.

Rationale

Das eRezept ist mit zentraler Bestandteil im neuen Gesetz für mehr Sicherheit in der Arzneimittelversorgung (GSAV). Hierbei soll das derzeit papiergebundene Rezept durch eine elektronische Fassung abgebildet werden.

Der vorliegende Implementierungsleitfaden stellt die vereinheitlichte elektronische Wiedergabe des elektronischen Rezepts dar und bildet

• das CDA-basierte Rezept in ISO/HL7 27932:2009 Ausgabe und
• die Profile für das FHIR-basierte Rezept

in der offiziellen Fassung für Deutschland, d.h. es wird gemäß des internationalen Regelwerks auf Basis dieser Standards als Profile erarbeitet und abgestimmt. Ziel ist somit eine offizielle Affiliate Localization.

Zweck

Im Rahmen dieses Leitfadens sollen die oben erwähnten Sachverhalte durch entsprechende semantische und strukturelle Vorgaben adressiert werden:

• Festlegung von Daten- und Übertragungsstandards auf der Basis von
  • HL7 Clinical Document Architecture Format (ISO/HL7 27932:2009) mit Templates und Value Sets und
  • HL7 FHIR® (Fast Healthcare Interoperability Resources) mit Profilen und Value Sets

Im weiteren Verlauf werden in den Abschnitten "Aufbau" und "Technische Spezifikationen"

• die Festlegung definierter semantische Bezugssysteme (insbesondere Klassifikationen, Terminologien) im Abschnitt "Terminologien",
• sowie durch Aufzeigen der Möglichkeiten des Mappings und automatisierter Konversionen der Spezifikationen untereinander im "Anhang"

erläutert.

Diese Spezifikationen werden als Beitrag für die weitere Zusammenarbeit mit Ärzten, Apothekern, anderen Projekten und Vorhaben und den entsprechenden Gremien und Arbeitsgruppen gesehen, die für das elektronische Rezept zuständig sind.

Vorarbeiten

Das Rezept wurde bereits mehrfach von unseren Nachbarländern bzw. in der Standardisierung abgebildet.

Standardisierung

Neben den Niederlanden hat auch Österreich in seinen Spezifikationen zur ELGA eine CDA-basierte Arzneimittelverordnung (eRezept) erarbeitet und offiziell abgestimmt. Parallel dazu gibt es Ausarbeitungen im Bereich IHE Pharmacy:

• PRE: Prescription
• CPMD: Community Prescription and Medication Dispense.

Ersteres kümmert sich um die inhaltlichen Vorgaben auf Basis von CDA, letzteres um den Transport beispielsweise über XDS. Letzteres passt damit sehr gut zu den deutschen Anforderungen für die Telematik-Infrastruktur (TI), die ebenfalls auf IHE ITI XDS basieren soll.

Neben diesen Vorarbeiten gibt es eine harmonisierte Ausarbeitung für CDA als "UV Medication Order Template" von HL7 International.

Im Rahmen dieses Projektes sollen diese Ansätze kombiniert werden.

andere KV-Formulare

Die Arzneimittelverordnung / das Rezept nutzt Module (Komponenten) aus den anderen Spezifikationen im Bereich Verordnungsmanagement sowie dem Projekt Medikationsplan PLUS und der konsolidierten Fassung der Medikationspläne im Medikationsmanagement. So lies sich relativ leicht ein Dokument-Template erstellen, das bereits die Grundlagen für das Verordnungsmanagement beinhaltet und dann nur noch Ergänzungen und Anpassungen für die dedizierten Abschnitte erforderte.

Nutzer

Mögliche Nutzer sind Institutionen, welche am Informationsaustausch im Rahmen des Rezepts beteiligt sind:

• Haus- und Facharztpraxen
• Apotheken
• Krankenhäuser

Zu den möglichen Akteuren gehören:

• Haus- und Fachärztinnen und –ärzte
• Mitarbeiterinnen und Mitarbeiter von Apotheken.

Forderungen und Potenziale

Derzeit laufen mehrere Projekte, die ebenfalls das Ziel eines elektronischen Rezepts verfolgen.

Der Ansatz des eRezepts auf internationalen Standards zielt auf den Einsatz im ambulanten und stationären Bereich inklusive neuerer und mobiler Anwendungen ab und stellt das Thema „Rezept“ auch für andere Gesundheits-Anwendungen als das reine Rezept oder AMTS zur Verfügung. Die Abbildungen zum Thema „Medikation“ sind über Anwendungsgrenzen hinweg isomorph, von Struktur und Semantik gleich bzw. nahezu gleich, ohne dabei starr zu sein.

Ein weiteres Ziel von eRezepten ist, dass diese ein natürlicher Bestandteil der sicheren Arzneimitteltherapie sind, vorrangig für den Patienten, aber auch für alle in die Therapie und Versorgung mit Medikamenten involvierten Gesundheitsdienstleister. Damit dies ohne große Brüche möglich ist, steht auch in diesem Vorhaben die Kompatibilität mit dem elektronischen Arztbrief und Arztbrief Plus [23], den Notfalldaten oder (später) einer Patientenakte im Vordergrund, ebenso die Kongruenz zu anderen Formularen aus dem Verordnungsmanagement.

Daraus ergeben sich die folgenden Forderungen, die diese Spezifikation flankierend unterstützen will:

• eRezepte sind integraler Bestandteil der intersektoralen Arzneimitteltherapie
• Medikamenten-Informationen nutzen zur eindeutigen Wiedergabe der Datenfelder sowie zur Abbildung der einzelnen Inhalte einheitliche Strukturen, unabhängig vom Anwendungsfall;
• Medikamenten-Informationen nutzen zur eindeutigen Kennzeichnung der Datenfelder sowie zur Abbildung der einzelnen Inhalte eine einheitliche Semantik im Sinne von Katalogen, Codierungen usw., insbesondere internationale Klassifikationen und Terminologien wie beispielsweise Logical Observation Identifiers Names and Codes (LOINC®), Systematisierte Nomenklatur der Medizin (SNOMED CT®) oder die Standard Terms des European Directorate for the Quality of Medicines (EDQM).

Abgrenzung

Das Thema "Signatur" wird explizit ausgeklammert. Das betrifft zum Einen den Umfang der Signatur, d.h. wann eine forteschrittene und wann eine qualifizierte Signatur benötigt, und zum Anderen, wie die Signatur angewendet wird. Hierzu existieren bereits andere Vorarbeiten, auf die dann Bezug genommen wird.

Offene Punkte und Besonderheiten

Folgende Punkte bedürfen noch einer weitergehenden Klärung:

• Das Projekt Medikationsplan PLUS schlägt für die Textteile in den entsprechenden Sections Tabellenstrukturen vor, die direkt ausgegeben werden können. Die Vorgaben hier legen eine Erzeugung einer druckbaren Darstellung durch ein Stylesheet nahe, so dass auch das entsprechende Formular "ausgefüllt" zur Verfügung stehen kann. Ein solches Stylesheet ist noch in der finalen Abrundung.
• Aus dem Projekt Medikationsplan PLUS bzw. dem Medikationsmanagement wurden für diese Spezifikation diverse Templates entweder gänzlich übernommen oder geeignet adaptiert. Ihre Passgenauigkeit muss noch diskutiert werden, da die Verordnung ein etwas anders gelagerter Anwendungsfall ist.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Aufbau

Aufbau dieses Implementierungsleitfadens

Dieser Leitfaden eRezept beinhaltet die folgenden Spezifikationen:

• Ein Informationsmodell, das die grundlegenden Beziehungen der einzelnen Informationseinheiten zueinander darstellt
• Strukturelle Vorgaben in Form von Templates auf der Basis der Clinical Document Architecture Release 2, wiedergegeben in den Abschnitten zu den Templates CDA Dokumenten-Level, CDA Header-Level, CDA Section-Level und CDA Entry-Level
• Strukturelle Vorgaben in Form von FHIR-Profilen, wiedergegeben in der Technischen Spezifikation im Abschnitt FHIR-Profile
• Semantische Vorgaben in Form von Value Sets, aufgeführt im Abschnitt Terminologien.

Verwendete Standards und Spezifikationen

In der vorliegenden Spezifikation ist zum einen die Clinical Document Architecture Release 2 (CDA R2), auch ISO/HL7 27932:2009 die Grundlage.

Des Weiteren sind die FHIR-Profile zum eRezept auf dem so genannten R4 (wo möglich, sonst STU 3 ) aufgebaut.

Templates, Profile und Value Sets wurden abgeleitet oder übernommen aus folgenden internationalen bzw. nationalen Standards:

• HL7 Deutschland: "Arztbrief 2014/2015 auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen" und "Arztbrief Plus"

Die genauen Referenzen in diese Standards sind bei den Templates unter Beziehungen/Relationships angegeben.

• HL7 Deutschland: FHIR Basisprofile

Dieser Implementierungsleitfaden basiert weiterhin auf Vorarbeiten folgender Leitfäden:

• Implementierungsleitfaden "elektr. Arbeitsunfähigkeitsbescheinigung"

sowie von HL7 Deutschland e. V. zur Verfügung gestellten CDA-Templates und FHIR-Profilen.

• Die Vorgaben zum eRezept der Europäischen Union, erarbeitet durch das IPS (International Patient Summary) Project

Tooling

Es sei darauf verwiesen, dass alle CDA-spezifischen technischen Artefakte wie Templates und Value Sets auf ART-DECOR® als Spezifikations-Plattform einsehbar sind. Der direkte Link zur ART-DECOR® Live Version ist http://art-decor.org/art-decor/decor-project--vomgt-, die HTML-Dokumentation steht auf http://hl7de.art-decor.org/index.php?prefix=vomgt- zur Verfügung. Dort sind auch ergänzenden Materialien wie Beispieldokumente und Schematrons herunterladbar.

Die Templates werden mit ART-DECOR® erstellt und verwaltet, der darunterlegende Standard ist der so genannte Template Exchange Standard.

Beispiel der Ansicht eines Templates und die zugehörige Navigation

Für die Erstellung der FHIR-Profile wurde Forge von Furore genutzt, die Profile selbst wurden unter Simplifier gespeichert. HL7 Deutschland hat für Simplifier eine so genannte Affiliate-Vereinbarung für die Basisprofile.

Frontseite des Projekts auf Simplifier.net (FHIR-Profile)

Die FHIR-Profile werden in naher Zukunft transparent im Tool ART-DECOR® verfügbar gemacht (siehe und dort mit den Funktionalen Definitionen verbunden.

Beispiel der Darstellung von FHIR-Profilen in ART-DECOR®, die auf simplifier.net gehostet werden

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Transportaspekte

Interaktionsdiagramm

In diesem Leitfaden geht es um die Präzisierung des Aufbaus von Dokumenten (hier: der Arztbrief), d.h. wie diese inhaltlich strukturiert sind. Die Prinzipien der Gliederung gelten aber auch für andere Arten von Dokumenten wie Ein-/Überweisungen, Befunde, etc.

Im Allgemeinen wird ein CDA-Dokument von einer Anwendung in einem bestimmten Kontext erzeugt und dann als ganzheitliches Objekt übertragen. Dies kann auf unterschiedlichen Wegen passieren (bspw. als Datei, als Binärobjekt in einer Email oder als Objekt einer Akte wie EFA, eEPA oder EGA), diese werden hier aber nicht spezifiziert. Dieses Objekt wird dann letztendlich von einer – oder mehreren – Anwendungen konsumiert:

Interaktionsdiagramm

Dokumentenaustausch

Für den Austausch der Dokumente gibt es mehrere Möglichkeiten, zu denen eine Reihe von konkreten Vorgaben existieren - insbesondere bei IHE ITI -, die hier nur kurz genannt werden sollen:

• IHE ITI
  • die Integrationsprofile XDS, XDM und XDR
• Telematikinfrastruktur (in Vorbereitung) mit KOM-LE
• KV-Connect
• Safemail
• FTP
• ...

Diese Liste ist nicht vollständig und soll nur als Beispiel dienen.

Rechtssichere Übertragung

Eine eAU kann papierbegleitend, aber auch papierersetzend umgesetzt werden. Im letzteren Fall ist diese mit einer rechtssicheren elektronischen Signatur (fortgeschritten oder QES) zu ergänzen:

• Datenschutz-/-sicherheit
• IT-Sicherheit
• Verschlüsselung
• Signaturen

Rechtssichere Übertragung

Eine eVerordnung/ ein eRezept kann papierbegleitend, aber auch papierersetzend umgesetzt werden. Im letzteren Fall ist diese mit einer rechtssicheren elektronischen Signatur (fortgeschritten oder QES) zu ergänzen:

o Datenschutz-/-sicherheit o IT-Sicherheit o Verschlüsselung o Signaturen

Akteure

Folgende Akteure kommen in Kontakt mit einer Verordnung/ einem Rezept

• Vertragsarzt
• Krankenhaus
• Versicherter
• Apotheke/ Krankenhausapotheke
• Kostenträger
• Kassenärztliche Vereinigung

Transportwege

1. Arzt – Patient – Apotheke – Apothekenrechenzentrum – Krankenkasse – Kassenärztliche Vereinigung
2. Krankenhaus – Patient – Apotheke – Apothekenrechenzentrum – Krankenkasse – Kassenärztliche Vereinigung
3. Arzt – Patient – Apotheke – Apothekenrechenzentrum – Berufsgenossenschaft – Kassenärztliche Vereinigung

Weitere Wege?

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Use Case

Als Grundlage fallen alle Transaktionen in die übergeordnete Transaktion eVerordnung. Darunter sind die drei Basistransaktionen zu verstehen, die dann einerseits spezialisiert werden, und andererseits ggf. mit anderen Akteuren durchgeführt werden:

• eVerschreibung durchführen (verordnen)
• eVerschreibung ausgeben
• eVerschreibung abrechnen

Use Cases

eVerschreibung durchführen

Für die Verordnung einer Medikation wird diese Aktion spezialisiert als:

• eRezept erstellen und eVerschreibung übergeben

Für Heil- und Hilfsmittel sind die Prozesse im Wesentlichen gleich. Für Transportaufträge erfolgt keine Ausgabe, sondern eine entsprechende Leistungserbringung. Im Prinzip unterscheiden sich diese durch unterschiedliche Spezialisierung der Dokumente - statt eines Medikamentenrezepts eine Brillenverordnung - und andere Transakteure.

eVerschreibung einlösen

• Medikament ausgeben

eVerschreibung abrechnen

• Medikament abrechnen

Stornierung einer Verschreibung

Es ist zu diskutieren, inwieweit eine Stornierung explizit definiert werden muss? Im einfachsten Fall wird ein Rezept innerhalb des Gültigkeitsztraums nicht eingelöst. Ein einmal ausgegebens Rezept befindet sich aktuell im Besitz des Patienten und kann daher vom ausgebenden Arzt nicht mehr storniert werden.

Dieses Material ist Teil des Leitfadens Implementierungsleitfaden. Direkt im Wiki geändert werden sollten Schreibfehler, ergänzende Hinweise. Offene Fragen, die der Diskussionen bedürfen, sollten auf der Diskussionsseite aufgenommen werden. Liste der Seiten dieses Leitfadens: hier, Liste der Seiten, in denen dieses Material verwendet (transkludiert) siehe hier .

Informationsmodell

Vorgehensweise

Im Mittelpunkt dieser Ausarbeitung steht das Informationsmodell, aus dem die beiden technischen Umsetzungen in Form von CDA und FHIR abgeleitet werden. Dieses Informationsmodell wird durch die beteiligten Organisationen und deren Mitglieder erarbeitet. Über das Interoperabilitätsforum steht es aber auch weiteren Institutionen offen.

Die Qualitätssicherung für eine anschließende Ballotierung als sog. Affiliate Localization wird durch HL7 Deutschland übernommen.

Die inhaltliche Ausarbeitung orientiert sich primär an den Erfordernissen, die aus dem papiergebundenen Rezept abgeleitet werden können. Dies geschieht über die Erfassung als ART-DECOR Data Set, woran sich auch die Erarbeitung als übergordnetes Informationsmodell orientiert.

Als Randbedingungen fließen hierzu die Vorarbeiten ein, die bspw. über IHE Pharmacy, HL7 International, ELGA in Österreich und das europäische eRezept bereits vorhanden sind. Idealerweise werden diese miteinander harmonisiert. Als Ergebnis entstehen dann Templates (Document, Section, Entries) für CDA und äquivalente FHIR-Profile. Das zusammen bildet dann diesen Implementierungsleitfaden. Als informative Ergänzung werden dann XML-Schemas und ggf. auch Schematron für Testzwecke generiert.

Vorgehensweise

Hierarchien

Bei der Informationsmodellierung lassen sich verschiedene Hierarchien identifizieren, die nachfolgend kurz erläutert werden.

Prozesshierarchie

Zuerst einmal lässt sich der Prozess in drei Teilprozesse zerlegen:

• eVerschreibung: Arzt - Patient/Angehöriger/Bevollmächtigter - Leistungserbringer
• eAbgabe: Leistungserbringer - Patient
• eAbrechnung: Leistungserbringer - Kostenträger

Anmerkung: Der Arzt ist in der Verschreibung der Hauptakteur, während er als Leistungserbringer ebenfalls in anderen Szenarien wie beispielsweise bei Laboraufträgen, die heir keine Rolle spielen, in Erscheinung treten kann.

Prozesshierarchie

Zwischen diesen Akteuren werden die entsprechenden Dokumente ausgetauscht.

Akteurhierarchie

Genauso können einzelne Akteure weiter spezialisiert werden, je nachdem, um welche Verordnung es sich handelt.

Akteurshierarchie

Dokumentenhierarchie

Die verschiedenen Dokumenttypen, die im Verordnungsprozess eine primäre Rolle spielen, lassen sich ebenfalls in einer Hierachie anordnen, so dass das Rezept als Muster 16 nur eine Ausprägung davon darstellt. Die anderen Muster lassen sich im Prinzip ähnlich abbilden.

Dokumentenhierarchie

Das Rezept selbst steht in einem Zusammenhang mit der Abgabe und Abrechnung.

Zusammenhang zwischen den Dokumenten

Damit ergeben sich in einer Template-Darstellung folgende Dokumentbeziehungen:

Dokumentbeziehungen

Informationsmodell (als Domain Model)

Die im Falle von Verordnungen relevanten Informationen lassen sich in ein gemeinsames Informationsmodell (als Domain Model) einordnen:

Informationsmodell

Das Informationsmodell wurde als Domänenmodell erstellt, um eine leicht erhöhtes Abstraktionsniveau sicherzustellen. Daraus lässt sich dann ein Klassenmodell ableiten, das hier aber nicht weiter betrachtet wird.

Data Set

Grundlegender Bestandteil für eine Abbildung in CDA und FHIR ist das Vorhandensein eines Informationsmodells, das eine entsprechende Datenmenge umfasst.

Die Daten, die für alle KV-Formulare in gleicher Art behandelt werden können, lassen sich wie folgt strukturieren:

Dataset Headerdaten

Die Daten, die die speziellen Details aus dem Rezept enthalten, sind wie folgt strukturiert:

Dataset Rezeptdaten

CDA Domänenmodell

Das eigentliche Domänenmodell für CDA lässt sich daraus ableiten. Auf der linken Seite in nachfolgender Abbildung sind drei Dokumente aufgeführt, die mit diesem Leitfaden ausspezifiziert werden müssen. Inhaltlich beinhalten diese die Medikation mit den Details zum Medikament.

Domänenmodell CDA

CDA-Spezifikation

Übersicht CDA Header und Body

Im Folgenden wird eine Übersicht über das CDA-Dokument gegeben.

1.2.276.0.76.3.1.135.8.10.100/hgraph

CDA-Dokument-Template

CDA Document Level Templates

16: eRezept

1.2.276.0.76.3.1.135.8.10.100/dynamic

16: eRezept für Sprechstundenbedarf

Dieses Dokumententemplate dient der Übermittlung des Sprechstundenbedarfs.

16: eAbgabe/eAbrechnung

Dieses Dokumententemplate verweist in den Sections bzw. Entries auf das entsprechende Rezept.

CDA Header Level Templates

Im Header der Verordnungsdateien werden alle benötigten administrativen Daten in einer festen Struktur abgebildet. Die hier erfassten Daten sind umfangreicher als auf einer papiergebundenen Verordnung, wodurch eine maschinelle Verarbeitung innerhalb verschiedener Institutionen unterstützt wird, da keine administrativen Daten mehr an anderer Stelle hinzugefügt werden müssen.

CDA recordTarget (vomgt)

Id	1.2.276.0.76.10.2048	Gültigkeit	2016‑02‑19 15:12:48
Status	Entwurf	Versions-Label
Name	CDArecordTargetvomgt	Bezeichnung	CDA recordTarget (vomgt)
Beschreibung	Das recordTarget repräsentiert die Person, über die dokumentiert wird. recordTarget umfasst IDs und dem Namen, Geschlecht, Adressen etc.
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 vomgt-data​element-4  Patientendaten  KV-Mustersammlung
Benutzt	Benutzt 1 Template Benutzt als Name Version 1.2.276.0.76.10.90030 Inklusion Personenname DYNAMIC
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.101 CDA recordTarget (DYNAMIC) ref ad1bbr- Spezialisierung: Template 1.2.276.0.76.10.2001 CDA recordTarget (2013‑07‑10) ref hl7de-
Item DT Kard Konf Beschreibung Label hl7:recordTarget (CDA...mgt)   vomgt-data​element-4  Patientendaten  KV-Mustersammlung @typeCode cs 0 … 1 F RCT @context​Control​Code cs 0 … 1 F OP   Beispiel <recordTarget typeCode="RCT" contextControlCode="OP">   <templateId root="1.2.276.0.76.10.2048"/>  <patientRole classCode="PAT">     <!-- ... -->   </patientRole></recordTarget> hl7:templateId 1 … 1 M (CDA...mgt) @root uid 1 … 1 F 1.2.276.0.76.10.2048 hl7:patientRole 1 … 1 (CDA...mgt) @classCode cs 0 … 1 F PAT   Beispiel <patientRole classCode="PAT">   <!-- eGK Nr -->   <id extension="A123456789" root="1.2.276.0.76.4.8"/>  <!-- lokale Patientennummer -->   <id extension="186245" root="1.2.276.0.76.3.1.139.3.871"/>  <!-- ID aus Selektivvertrag -->   <id extension="SV124-5" root="1.2.276.0.76.99.1.5.6"/>  <patient classCode="PSN" determinerCode="INSTANCE">     <!-- ... -->   </patient></patientRole> hl7:id 0 … * R (CDA...mgt) hl7:addr AD 1 … 1 M Adresse des Patienten (CDA...mgt)   Beispiel normale Adresse <addr use="HP">   <streetName>Dorfstraße</streetName>  <houseNumber>54</houseNumber>  <postalCode>51371</postalCode>  <city>Leverkusen</city>  <country>D</country></addr>   Beispiel Postfach <addr use="HP">   <postBox>654321</postBox>  <postalCode>51371</postalCode>  <city>Leverkusen</city>  <country>D</country></addr> hl7:patient 0 … 1 (CDA...mgt) @classCode cs 0 … 1 F PSN @determiner​Code cs 0 … 1 F INSTANCE   Beispiel <patient classCode="PSN" determinerCode="INSTANCE">   <name>     <!-- ... -->   </name>  <birthTime value="19541223"/></patient> Eingefügt 1 … 1 M von 1.2.276.0.76.10.90030 Personenname (DYNAMIC) hl7:name PN 1 … 1 M Die Reihenfolge der Namensbestandteile soll der typischen Schreibweise entsprechen. Zu beachten ist, dass prefix- und suffix-Elemente mit einem Leerzeichen enden müssen, wenn sie nicht unmittelbar an den folgenden Namensbestandteil anschließen sollen. (CDA...mgt)   vomgt-data​element-26  Name  KV-Mustersammlung vomgt-data​element-773  Full Name  KV-Mustersammlung   Beispiel Dr. med. Sine Johanna Gräfin von Oberberg <name>   <prefix qualifier="AC">Dr. med. </prefix>  <given>Sine Johanna</given>  <prefix qualifier="NB">Gräfin </prefix>  <prefix qualifier="VV">von </prefix>  <family>Oberberg</family></name>   Beispiel Prof. Dr. med. Dr. rer. nat. Fritz Julius Karl Freiherr von und zu Rathenburg vor der Isar, MdB <name>   <prefix qualifier="AC">Prof. Dr. med. Dr. rer. nat. </prefix>  <given>Fritz</given>  <given>Julius</given>  <given>Karl</given>  <prefix qualifier="NB">Freiherr </prefix>  <prefix qualifier="VV">von und zu </prefix>  <family>Rathenburg vor der Isar</family>  <suffix>, MdB</suffix></name> hl7:prefix ENXP 0 … * Titel (CDA...mgt) wo [@qualifier='AC'] @qualifier set_cs 1 … 1 F AC hl7:given ENXP 0 … * Vorname (CDA...mgt) hl7:prefix ENXP 0 … * Namenszusatz (CDA...mgt) wo [@qualifier='NB'] @qualifier set_cs 1 … 1 F NB hl7:prefix ENXP 0 … * Vorsatzwort (CDA...mgt) wo [@qualifier='VV'] @qualifier set_cs 1 … 1 F VV hl7:family ENXP 0 … * Nachname (CDA...mgt) hl7:suffix ENXP 0 … * Suffix (CDA...mgt) hl7:administrative​Gender​Code CE NP Hier sollte das administrative Geschlecht des Patienten übermittelt werden. In KBV-Formularen spielt allerdings nur die Information über das Geschlecht eine Rolle, was auf der eGK enthalten ist. Dies wird über eine separate Observation übermittelt. Deshalb entfällt diese Element. (Weitere Informationen zu diesem Thema: http://wiki.hl7.de/index.php?title=Geschlecht) (CDA...mgt) hl7:birthTime TS.​DATE.​MIN 1 … 1 M Geburtsdatum des Patienten (CDA...mgt)   Beispiel <birthTime value="19491224"/>

CDA author Person (vomgt)

Id	1.2.276.0.76.10.2049	Gültigkeit	2016‑09‑06 10:43:05
Status	Entwurf	Versions-Label
Name	HeaderAuthorPerson	Bezeichnung	CDA author Person (vomgt)
Beschreibung	Dieses Template spezifiziert, wie ein Mensch/Person als Autor des Dokumentes angegeben wird.
Klassifikation	CDA Header Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 6 Konzepte Id Name Datensatz vomgt-data​element-3  Arztdaten  KV-Mustersammlung vomgt-data​element-33  Betriebsstättennummer  KV-Mustersammlung vomgt-data​element-34  Arzt-Nr  KV-Mustersammlung vomgt-data​element-679  ASV-Teamnummer  KV-Mustersammlung vomgt-data​element-755  Krankenhausaufnahme  KV-Mustersammlung vomgt-data​element-756  Krankenhaus  KV-Mustersammlung
Benutzt	Benutzt 2 Templates Benutzt als Name Version 1.2.276.0.76.10.90010 Inklusion CDA Person Elements DYNAMIC 1.2.276.0.76.10.90032 Inklusion CDA Organization Elements (vomgt) DYNAMIC
Beziehung	Spezialisierung: Template 1.2.276.0.76.10.2002 CDA author (DYNAMIC) ref hl7de- Spezialisierung: Template 2.16.840.1.113883.10.12.102 CDA author (DYNAMIC) ref ad1bbr- Spezialisierung: Template 1.2.276.0.76.10.2007 CDA author Person (2013‑10‑11) ref hl7de-
Beispiel	Beispiel <author typeCode="AUT">   <templateId root="1.2.276.0.76.10.2049"/>  <functionCode code="DISPHYS" displayName="discharging physican" codeSystem="2.16.840.1.113883.5.88" codeSystemName="ParticipationFunction"/>  <time value="201304071300"/>  <assignedAuthor classCode="ASSIGNED">     <id root="20cf14fb-b65c-4c8c-a54d-b0cca834c18c"/>    <assignedPerson classCode="PSN" determinerCode="INSTANCE">       <name>         <prefix>Dr.med.</prefix>        <given>Karl</given>        <family>Gebhardt</family>      </name>    </assignedPerson>    <representedOrganization>       <id root="2.16.840.1.113883.19.5"/>      <name>Beispiel Krankenhaus</name>    </representedOrganization>  </assignedAuthor></author>
Item DT Kard Konf Beschreibung Label hl7:author (Hea...son) wo [hl7:templateId/@root='1.2.276.0.76.10.2049']   vomgt-data​element-3  Arztdaten  KV-Mustersammlung vomgt-data​element-33  Betriebsstättennummer  KV-Mustersammlung vomgt-data​element-34  Arzt-Nr  KV-Mustersammlung @typeCode cs 0 … 1 F AUT @context​Control​Code cs 0 … 1 F OP   Beispiel <author typeCode="AUT" contextControlCode="OP">   <templateId root="1.2.276.0.76.10.2049"/>  <time value="201306101654"/>  <assignedAuthor classCode="ASSIGNED">     <!-- ... -->   </assignedAuthor></author> hl7:templateId II 1 … 1 M (Hea...son) @root uid 1 … 1 F 1.2.276.0.76.10.2049 hl7:functionCode CE 0 … 1 (Hea...son)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10267 ParticipationFunction (DYNAMIC) hl7:time TS.​DATE.​MIN 1 … 1 (Hea...son)   vomgt-data​element-755  Krankenhausaufnahme  KV-Mustersammlung hl7:assignedAuthor 1 … 1 (Hea...son) @classCode cs 0 … 1 F ASSIGNED hl7:id II 1 … 1 Die LANR des Arztes wird im id-Element der Rolle (... 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. (Hea...son) @extension st 1 … 1 R @root uid 1 … 1 F 1.2.276.0.76.4.16 hl7:id II 0 … 1 R Die ASV-Teamnummer wird in einer eigenen Wiederholung untergebracht. Die OID dafür ist beantragt, aber noch nicht zugewiesen.  Es muss entweder die ASV-Teamnummer oder die BSNR übermittelt werden! (Hea...son)   vomgt-data​element-679  ASV-Teamnummer  KV-Mustersammlung @extension st 1 … 1 R @root uid 1 … 1 F 1.2.276.0.76.4.200 hl7:code CE 0 … 1 Fachgebiet/Spezialität des Gesundheitsdienstleister, z. B. Ärztin/Arzt für Allgemeinmedizin, Approbierte Ärztin/Approbierter Arzt, Fachärztin/Facharzt für Anästhesiologie und Intensivmedizin (Hea...son)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.101 S_BAR2_ARZTNRFACHGRUPPE (DYNAMIC) hl7:telecom TEL 0 … * (Hea...son) hl7:assigned​Person 1 … 1 M (Hea...son) Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC) @classCode 0 … 1 F PSN @determiner​Code 0 … 1 F INSTANCE hl7:name PN 1 … 1 M (Hea...son) hl7:represented​Organization 1 … 1 M (Hea...son)   vomgt-data​element-756  Krankenhaus  KV-Mustersammlung   Beispiel <representedOrganization classCode="ORG" determinerCode="INSTANCE">   <id root="1.2.276.0.76.4.17" extension="123456700"/>  <name>     <!-- ... -->   </name></representedOrganization> Eingefügt von 1.2.276.0.76.10.90032 CDA Organization Elements (vomgt) (DYNAMIC) @classCode cs 0 … 1 F ORG @determiner​Code cs 0 … 1 F INSTANCE hl7:id II 0 … 1 R Die BSNR für die entsprechende Betriebsstätte wird im id-Element in @extension angegeben. Das Identifikationssystem BSNR hat die registrierte OID 1.2.276.0.76.4.17 und wird im @root-Attribut gekennzeichnet. Es muss entweder die BSNR oder die ASV-Teamnummer übermittelt werden! (Hea...son) @extension st 0 … 1   @root uid 0 … 1 F 1.2.276.0.76.4.17 hl7:name ON 1 … 1 M (Hea...son) hl7:telecom TEL 0 … * (Hea...son) hl7:addr AD 0 … 1 (Hea...son)

CDA Section Level Templates

Insurance Section

Id	1.2.276.0.76.10.3103	Gültigkeit	2016‑02‑25 18:55:55
Status	Entwurf	Versions-Label
Name	InsuranceSection	Bezeichnung	Insurance Section
Beschreibung In diesem Abschnitt werden die Versichertendaten untergebracht.  Hintergrund: Durch das CDA RMIM ist es nicht möglich alle notwendigen Versicherteninformationen als Participant im Header unterzubringen.
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.3103
Klassifikation	CDA Section level template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz vomgt-data​element-24  Versichertendaten  KV-Mustersammlung
Benutzt	Benutzt 1 Template Benutzt als Name Version 1.2.276.0.76.10.4263 Containment Coverage Activity DYNAMIC
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07) ref ad1bbr- Adaptation: Template 2.16.840.1.113883.10.20.22.2.18 Payers Section (V3) (DYNAMIC) ref ccda-
Beispiel	Beispiel <section>   <templateId root="1.2.276.0.76.10.3103"/>  <code code="48768-0" codeSystem="2.16.840.1.113883.6.1"/>  <title>Versicherung</title>  <!-- Versicherung/Coverage -->   <!-- .... --> </section>
Item DT Kard Konf Beschreibung Label hl7:section (Ins...ion)   vomgt-data​element-24  Versichertendaten  KV-Mustersammlung hl7:templateId II 1 … 1 M (Ins...ion) @root uid 1 … 1 F 1.2.276.0.76.10.3103 hl7:code 1 … 1 M Payment sources Document (Ins...ion) @code CONF 1 … 1 F 48768-6 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:title ST 1 … 1 (Ins...ion)   CONF Elementinhalt muss "Versicherung" sein hl7:entry 1 … 1 M Beinhaltet 1.2.276.0.76.10.4263 Coverage Activity (DYNAMIC) (Ins...ion) @typeCode cs 1 … 1 F COMP @context​Conduction​Ind bl 0 … 1

Rezept Section

1.2.276.0.76.3.1.135.8.10.102/dynamic

wichtige Angaben Section

Id	1.2.276.0.76.10.3042	Gültigkeit	2014‑11‑01
Status	Entwurf	Versions-Label
Name	Instructions	Bezeichnung	Wichtige Angaben
Beschreibung	Wichtige Angaben/Hinweise für den Patienten
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.3042
Label	instpmp
Klassifikation	CDA Section level template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07) ref ad1bbr- Spezialisierung: Template 2.16.840.1.113883.10.20.21.2.45.2 (DYNAMIC) ref ?
Beispiel	Beispiel <section classCode="DOCSECT" moodCode="EVN">   <templateId root="1.2.276.0.76.10.3042"/>  <code code="69730-0" codeSystem="2.16.840.1.113883.6.1" displayName="Instructions"/>  <title>Wichtige Angaben</title>  <text>     Bitte messen Sie Ihren Blutdruck täglich!    <br/>     Nächster Impftermin: 24.12.2014    <br/>     Bei Rissen in der Hornhaut bitte Desinfektion auftragen.  </text></section>
Item DT Kard Konf Beschreibung Label hl7:section 0 … * instpmp @classCode 0 … 1 F DOCSECT @moodCode 0 … 1 F EVN hl7:templateId II 1 … 1 instpmp @root 1 … 1 F 1.2.276.0.76.10.3042 hl7:code CE 1 … 1 M instpmp @code CONF 1 … 1 F 69730-0 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC)   Beispiel <code code="69730-0" displayName="Instructions" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/> hl7:title ST 1 … 1 M instpmp   CONF Elementinhalt muss "Wichtige Angaben" sein hl7:text SD.TEXT 1 … 1 M instpmp

CDA Entry Level Templates

Coverage Activity

Id	1.2.276.0.76.10.4263	Gültigkeit	2016‑02‑25 19:00:30
Status	Entwurf	Versions-Label
Name	CoverageActivity	Bezeichnung	Coverage Activity
Beschreibung	Dieses Template ist der "Aufhänger" für die Detailangaben zum Versicherungsverhältnis, also insbesondere die Informationen von der Gesundheitskarte (eGK).
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4263
Klassifikation	CDA Entry Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Benutzt	Benutzt 1 Template Benutzt als Name Version 1.2.276.0.76.10.4264 Containment Policy Activity DYNAMIC
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.301 CDA Act (2005‑09‑07) ref ad1bbr- Spezialisierung: Template 2.16.840.1.113883.10.20.22.4.60 Coverage Activity (V3) (DYNAMIC) ref ccda-
Item DT Kard Konf Beschreibung Label hl7:act (Cov...ity) @classCode cs 1 … 1 F ACT @moodCode cs 1 … 1 F EVN hl7:templateId II 1 … 1 M (Cov...ity) @root uid 1 … 1 F 1.2.276.0.76.10.4263 hl7:id 0 … * (Cov...ity) hl7:code 1 … 1 M Payment sources Document (Cov...ity) @code CONF 1 … 1 F 48768-6 @codeSystem 1 … 1 F 2.16.840.1.113883.6.1 (LOINC) hl7:statusCode 1 … 1 M (Cov...ity) @code CONF 1 … 1 F completed hl7:entryRelationship 1 … 1 M Im Verordnungsmanagement muss die Information zu genau einer Versicherung übermittelt werden. Beinhaltet 1.2.276.0.76.10.4264 Policy Activity (DYNAMIC) (Cov...ity) @typeCode cs 1 … 1 F COMP

DMP Observation

Id	1.2.276.0.76.10.4271	Gültigkeit	2017‑12‑01 14:01:13 Andere Versionen mit dieser Id: DMPObservation vom 2017‑11‑29 14:43:15
Status	Entwurf	Versions-Label
Name	DMPObservation	Bezeichnung	DMP Observation
Beschreibung	Mit dieser Observation wird die DMP-Zuordnung angegeben.
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4271
Klassifikation	CDA Entry Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Adaptation: Template 1.2.276.0.76.3.1.135.8.10.34 DMP Observation (2017‑11‑29 14:43:15) Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07) ref ad1bbr-
Item DT Kard Konf Beschreibung Label hl7:observation (DMP...ion) @classCode cs 0 … 1 F OBS @moodCode cs 1 … 1 F EVN hl7:templateId II 1 … 1 M (DMP...ion) @root uid 1 … 1 F 1.2.276.0.76.10.4271 hl7:code CD 1 … 1 M (DMP...ion) @code CONF 1 … 1 F DMP @codeSystem 1 … 1 F 1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99) hl7:value CE 1 … 1 M (DMP...ion)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.138 S_KBV_DMP (DYNAMIC)

eGK-Geschlecht Observation

Id	1.2.276.0.76.10.4272	Gültigkeit	2017‑11‑29 18:17:27
Status	Entwurf	Versions-Label
Name	eGKGeschlechtObservation	Bezeichnung	eGK-Geschlecht Observation
Beschreibung Mit dieser Observation wird das Geschlecht angegeben, das auf der eGK hinterlegt ist. (Hier handelt es sich nicht um das administrative Geschlecht, für das recordTarget.administrativeGender vorgesehen ist.)
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4272
Klassifikation	CDA Entry Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07) ref ad1bbr-
Item DT Kard Konf Beschreibung Label hl7:observation (eGK...ion) @classCode cs 0 … 1 F OBS @moodCode cs 1 … 1 F EVN hl7:templateId II 1 … 1 M (eGK...ion) @root uid 1 … 1 F 1.2.276.0.76.10.4272 hl7:code CD 1 … 1 M (eGK...ion) @code CONF 1 … 1 F eGK_Gender @codeSystem 1 … 1 F 1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99) hl7:value CD 1 … 1 M (eGK...ion)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.458 Geschlecht (eGK) (DYNAMIC) oder Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.3.1.135.8.11.25 Geschlecht2 (eGK) (DYNAMIC)

KV-Zuordnung Observation

Id	1.2.276.0.76.10.4275	Gültigkeit	2018‑02‑27 12:35:11
Status	Entwurf	Versions-Label
Name	KVZuordnungObservation	Bezeichnung	Kv-Zuordnung Observation
Beschreibung	Mit dieser Observation wird die Zuordnung zur KV angegeben.
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4275
Klassifikation	CDA Entry Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Adaptation: Template 1.2.276.0.76.3.1.135.8.10.34 DMP Observation (2017‑11‑29 14:43:15) Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07) ref ad1bbr-
Item DT Kard Konf Beschreibung Label hl7:observation (KVZ...ion) @classCode cs 0 … 1 F OBS @moodCode cs 1 … 1 F EVN hl7:templateId II 1 … 1 M (KVZ...ion) @root uid 1 … 1 F 1.2.276.0.76.10.4275 hl7:code CD 1 … 1 M (KVZ...ion) @code CONF 1 … 1 F KV-Zuordnung @codeSystem 1 … 1 F 1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99) hl7:value CE 1 … 1 M (KVZ...ion)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.148 S_KBV_KV (DYNAMIC)

Rezept Entry

1.2.276.0.76.3.1.135.8.10.104/dynamic

Person Group Observation

Id	1.2.276.0.76.10.4273	Gültigkeit	2017‑11‑29 14:46:01
Status	Entwurf	Versions-Label
Name	PersonGroupObservation	Bezeichnung	Person Group Observation
Beschreibung	Mit dieser Observation wird innerhalb der Coverage die Personengruppe angegeben.
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4273
Klassifikation	CDA Entry Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 1 Konzept Id Name Datensatz vomgt-data​element-632  Personengruppe  KV-Mustersammlung
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07) ref ad1bbr-
Item DT Kard Konf Beschreibung Label hl7:observation (Per...ion) @classCode cs 0 … 1 F OBS @moodCode cs 1 … 1 F EVN hl7:templateId II 1 … 1 M (Per...ion) @root uid 1 … 1 F 1.2.276.0.76.10.4273 hl7:code CD 1 … 1 M (Per...ion) @code CONF 1 … 1 F PRSNGRP @codeSystem 1 … 1 F 1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99) hl7:value CE 1 … 1 M (Per...ion)   vomgt-data​element-632  Personengruppe  KV-Mustersammlung   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.151 S_KBV_PERSONENGRUPPE (DYNAMIC)

Policy Activity

Id	1.2.276.0.76.10.4264	Gültigkeit	2016‑02‑25 19:07:54
Status	Entwurf	Versions-Label
Name	PolicyActivity	Bezeichnung	Policy Activity
Beschreibung Diese Aktivität ist der Aufhänger für die Informationen über den Kostenträger. Diese Details stammen primär von der eGK. Durch die Änderung der Versicherteninformation und der dazugehörigen Kodesysteme, so dass eine mehrstellige Information inkl. "00 - keine Angabe" übermittelt werden muss, werden die entsprechenden Details als "mandatory" deklariert.
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4264
Klassifikation	CDA Entry Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit	Assoziiert mit 3 Konzepte Id Name Datensatz vomgt-data​element-25  KrankenkassenName  KV-Mustersammlung vomgt-data​element-30  Kassen-IKNr  KV-Mustersammlung vomgt-data​element-31  eGK-Nummer  KV-Mustersammlung
Benutzt	Benutzt 5 Templates Benutzt als Name Version 1.2.276.0.76.10.4280 Containment Weitere Kennzeichen Observation DYNAMIC 1.2.276.0.76.10.4273 Containment Person Group Observation DYNAMIC 1.2.276.0.76.10.4271 Containment DMP Observation DYNAMIC 1.2.276.0.76.10.4275 Containment Kv-Zuordnung Observation DYNAMIC 1.2.276.0.76.10.4272 Containment eGK-Geschlecht Observation DYNAMIC
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.301 CDA Act (2005‑09‑07) ref ad1bbr-
Item DT Kard Konf Beschreibung Label hl7:act 1 … 1 R (Pol...ity)   vomgt-data​element-25  KrankenkassenName  KV-Mustersammlung vomgt-data​element-30  Kassen-IKNr  KV-Mustersammlung @classCode cs 1 … 1 F ACT @moodCode cs 1 … 1 F EVN hl7:templateId 1 … 1 M (Pol...ity) @root uid 1 … 1 F 1.2.276.0.76.10.4264 hl7:id 0 … * (Pol...ity) hl7:code CD 1 … 1 M (Pol...ity) @code CONF 1 … 1 F POLICY @codeSystem 1 … 1 F 1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99) hl7:statusCode 1 … 1 M (Pol...ity) @code CONF 1 … 1 F completed hl7:performer 1 … 1 M Dieser Performer repräsentiert die Krankenkasse (Pol...ity) @typeCode cs 1 … 1 F PRF hl7:assignedEntity 1 … 1 M (Pol...ity) hl7:id II 1 … 1 M Kostenträgerkennung (Pol...ity) @extension st 1 … 1 R @root uid 1 … 1 F 1.2.276.0.76.4.5 hl7:represented​Organization 0 … 1 R (Pol...ity) hl7:name 1 … 1 M Bezeichnung der Krankenkasse (Bedruckungsname) (Pol...ity) hl7:participant 1 … 1 M Information über den Versicherten (Eine Unterscheidung in Versicherungsnehmer/-versicherter ist an dieser Stelle nicht notwendig, da die Daten der eGK genutzt werden.) (Pol...ity) wo [@typeCode='COV'] @typeCode cs 1 … 1 F COV hl7:time 0 … 1 R (Pol...ity) hl7:low 0 … 1 R Versicherungsbeginn (Pol...ity) hl7:high 0 … 1 R Versicherungsende (Pol...ity) hl7:participantRole 1 … 1 M (Pol...ity) hl7:id II 1 … 1 M Versichertennummer (eGK-Nummer) (Pol...ity)   vomgt-data​element-31  eGK-Nummer  KV-Mustersammlung @extension st 1 … 1 R @root uid 1 … 1 F 1.2.276.0.76.4.8   Beispiel eGK Nummer als Patientenidentifikation <id extension="A123456789" root="1.2.276.0.76.4.8"/> hl7:id II 0 … 1 R In weiteren Wiederholungen können auch weitere Identifikatoren (ID aus Selektivvertrag, lokale Patientenidentifikation, etc.) übermittelt werden. (Pol...ity) @extension st 1 … 1 R @root uid 1 … 1 F 1.2.276.0.76.4.8   Beispiel lokale Patientennummer <id extension="186245" root="1.2.276.0.76.3.1.139.3.871"/>   Beispiel ID aus Selektivvertrag <id extension="SV124-5" root="1.2.276.0.76.99.1.5.6"/> hl7:code CD 1 … 1 Versichertenstatus (Pol...ity)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.162 S_KBV_VERSICHERTENSTATUS (DYNAMIC) hl7:addr 0 … 1 R (Pol...ity) hl7:playingEntity 0 … 1 R (Pol...ity) hl7:name 1 … * M Falls sich der Name der versicherten Person unterscheidet, bspw. durch Heirat. (Pol...ity) hl7:entryRelationship 1 … 1 M Beinhaltet 1.2.276.0.76.10.4280 Weitere Kennzeichen Observation (DYNAMIC) (Pol...ity) @typeCode cs 1 … 1 F COMP hl7:entryRelationship 1 … 1 M Beinhaltet 1.2.276.0.76.10.4273 Person Group Observation (DYNAMIC) (Pol...ity) @typeCode cs 1 … 1 F COMP hl7:entryRelationship 1 … 1 M Beinhaltet 1.2.276.0.76.10.4271 DMP Observation (DYNAMIC) (Pol...ity) @typeCode cs 1 … 1 F COMP hl7:entryRelationship 0 … 1 R Beinhaltet 1.2.276.0.76.10.4275 Kv-Zuordnung Observation (DYNAMIC) (Pol...ity) @typeCode cs 1 … 1 F COMP hl7:entryRelationship 0 … 1 R Die Übermittlung der Geschlechtsinformation von der eGK hängt von dem Muster ab. In einigen ist diese Information verpflichtend, in anderen wiederum verboten. Dies wird über entsprechende Regeln überprüft, die von dem classCode abhängig sind. Beinhaltet 1.2.276.0.76.10.4272 eGK-Geschlecht Observation (DYNAMIC) (Pol...ity) @typeCode cs 1 … 1 F COMP

Weitere Kennzeichen Observation

Id	1.2.276.0.76.10.4280	Gültigkeit	2018‑03‑08 17:32:15
Status	Entwurf	Versions-Label
Name	weitereKennzeichenObservation	Bezeichnung	Weitere Kennzeichen Observation
Beschreibung	Weitere Kennzeichen Observation
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4280
Klassifikation	CDA Entry Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07) ref ad1bbr-
Item DT Kard Konf Beschreibung Label hl7:observation (wei...ion) @classCode cs 0 … 1 F OBS @moodCode cs 1 … 1 F EVN hl7:templateId II 1 … 1 M (wei...ion) @root uid 1 … 1 F 1.2.276.0.76.10.4280 hl7:id II 0 … * (wei...ion) hl7:code CD 1 … 1 M (wei...ion) @code CONF 1 … 1 F KENNZEICHEN hl7:value CD 1 … 1 M (wei...ion)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.459 S_KBV_STATUSKENNZEICHEN (DYNAMIC)

WOP-Kennzeichen Observation

Id	1.2.276.0.76.10.4274	Gültigkeit	2018‑02‑23 17:05:11
Status	Entwurf	Versions-Label
Name	WOPObservation	Bezeichnung	WOP-Kennzeichen Observation
Beschreibung	Mit dieser Observation wird das WOP-Kennzeichen angegeben.
Kontext	Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4274
Klassifikation	CDA Entry Level Template
Offen/Geschlossen	Offen (auch andere als die definierten Elemente sind erlaubt)
Beziehung	Adaptation: Template 1.2.276.0.76.3.1.135.8.10.34 DMP Observation (2017‑11‑29 14:43:15) Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07) ref ad1bbr-
Item DT Kard Konf Beschreibung Label hl7:observation (WOP...ion) @classCode cs 0 … 1 F OBS @moodCode cs 1 … 1 F EVN hl7:templateId II 1 … 1 M (WOP...ion) @root uid 1 … 1 F 1.2.276.0.76.10.4274 hl7:code CD 1 … 1 M (WOP...ion) @code CONF 1 … 1 F WOP @codeSystem 1 … 1 F 1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99) hl7:value CE 1 … 1 M (WOP...ion)   CONF Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.172 S_KTS_WOP (DYNAMIC)

Terminologien

Folgende Terminologien werden verwendet.

eGK-Geschlecht

Diese Terminologie ist eine Momentaufnahme vom . Terminologien können sich im Laufe der Zeit weiterentwickeln. Wenn eine neuere (dynamische) Versionen dieser Terminologie benötigt wird, bitte von der Quelle abrufen.
Id	1.2.276.0.76.11.458	Gültigkeit	2018‑03‑06 14:14:42
Status	Entwurf	Versions-Label
Name	Geschlechtegk	Bezeichnung	Geschlecht (eGK)
Beschreibung	Code für das Geschlecht so wie auf der elektronischen Gesundheitskarte kodiert
Benutzung: 1 Id Name Typ Template 1.2.276.0.76.10.4272 eGK-Geschlecht Observation DYNAMIC
Quell-Codesystem	1.2.276.0.76.5.483 - FHIR: urn:oid:1.2.276.0.76.5.483
Level/ Typ Code Bezeichnung Codesystem 0‑L M männlich 1.2.276.0.76.5.483 0‑L W weiblich 1.2.276.0.76.5.483 0‑L X nicht angegeben 1.2.276.0.76.5.483
Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) schlägt Text in originalText vor. HL7 V3: NullFlavors werden im @nullFlavor Attribut statt in @code angegeben.

DMP

Diese Terminologie ist eine Momentaufnahme vom . Terminologien können sich im Laufe der Zeit weiterentwickeln. Wenn eine neuere (dynamische) Versionen dieser Terminologie benötigt wird, bitte von der Quelle abrufen.
Id	1.2.276.0.76.11.138	Gültigkeit	2019‑01‑01
Status	Definitiv	Versions-Label	1.03
Name	S_KBV_DMP	Bezeichnung	S_KBV_DMP
Beschreibung	DMP-Kennzeichen: gibt an, in welchen DMPs ein Versicherter eingeschrieben ist (§ 267 Abs. 2 Satz 4 SGB V). Die Angabe ist auf der EGK vorhanden und auf der KVK Teil des Feldes: Statusergänzung.
Benutzung: 2 Id Name Typ Datensatz konsab-data​element-130 DMP-Zuordnung DYNAMIC Template 1.2.276.0.76.10.4271 DMP Observation DYNAMIC
Quell-Codesystem	1.2.276.0.76.5.223 - FHIR: urn:oid:1.2.276.0.76.5.223
Level/ Typ Code Bezeichnung Codesystem 0‑L 00 nicht gesetzt 1.2.276.0.76.5.223 0‑L 01 DM2 1.2.276.0.76.5.223 0‑L 02 BRK 1.2.276.0.76.5.223 0‑L 03 KHK 1.2.276.0.76.5.223 0‑L 04 DM1 1.2.276.0.76.5.223 0‑L 05 Asthma 1.2.276.0.76.5.223 0‑L 06 COPD 1.2.276.0.76.5.223 0‑L 07 HI 1.2.276.0.76.5.223 0‑L 08 Depression 1.2.276.0.76.5.223 0‑L 09 Rueckenschmerz 1.2.276.0.76.5.223 0‑D 1 DM2 1.2.276.0.76.5.223 0‑D 2 BRK 1.2.276.0.76.5.223 0‑D 3 KHK 1.2.276.0.76.5.223 0‑D 4 DM1 1.2.276.0.76.5.223 0‑D 5 Asthma 1.2.276.0.76.5.223 0‑D 6 COPD 1.2.276.0.76.5.223
Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) schlägt Text in originalText vor. HL7 V3: NullFlavors werden im @nullFlavor Attribut statt in @code angegeben.

Personengruppe

Diese Terminologie ist eine Momentaufnahme vom . Terminologien können sich im Laufe der Zeit weiterentwickeln. Wenn eine neuere (dynamische) Versionen dieser Terminologie benötigt wird, bitte von der Quelle abrufen.
Id	1.2.276.0.76.11.151	Gültigkeit	2018‑07‑01
Status	Definitiv	Versions-Label	1.02
Name	S_KBV_PERSONENGRUPPE	Bezeichnung	S_KBV_PERSONENGRUPPE
Beschreibung	Personengruppe: kennzeichnet, zu welcher Personengruppe der Versicherte gehört (§ 264 SGB V). Die Angabe ist auf der EGK vorhanden und auf der KVK Teil des Feldes: Statusergänzung.
Benutzung: 2 Id Name Typ Datensatz konsab-data​element-124 Personengruppe DYNAMIC Template 1.2.276.0.76.10.4273 Person Group Observation DYNAMIC
Quell-Codesystem	1.2.276.0.76.5.222 - FHIR: urn:oid:1.2.276.0.76.5.222
Level/ Typ Code Bezeichnung Codesystem 0‑L 00 nicht gesetzt 1.2.276.0.76.5.222 0‑L 04 SOZ 1.2.276.0.76.5.222 0‑L 06 BVG 1.2.276.0.76.5.222 0‑L 07 SVA1 1.2.276.0.76.5.222 0‑L 08 SVA2 1.2.276.0.76.5.222 0‑L 09 ASY 1.2.276.0.76.5.222 0‑D 4 SOZ 1.2.276.0.76.5.222 0‑D 6 BVG 1.2.276.0.76.5.222 0‑D 7 SVA1 1.2.276.0.76.5.222 0‑D 8 SVA2 1.2.276.0.76.5.222
Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) schlägt Text in originalText vor. HL7 V3: NullFlavors werden im @nullFlavor Attribut statt in @code angegeben.

Versichertenstatus

Diese Terminologie ist eine Momentaufnahme vom . Terminologien können sich im Laufe der Zeit weiterentwickeln. Wenn eine neuere (dynamische) Versionen dieser Terminologie benötigt wird, bitte von der Quelle abrufen.
Id	1.2.276.0.76.11.162	Gültigkeit	2014‑01‑01
Status	Definitiv	Versions-Label
Name	S_KBV_VERSICHERTENSTATUS	Bezeichnung	S_KBV_VERSICHERTENSTATUS
Beschreibung	Versichertenstatus gibt an, ob ein Versicherter ein Familienversicherter, Mitglied oder Rentner ist. Auf der KVK ist diese Angabe Teil des Feldes VERSICHERTENSTATUS - die 1. Stelle.
Quell-Codesystem	2.16.840.1.113883.3.7.1.1 - KBV_CS_SFHIR_KBV_VERSICHERTENSTATUS
Level/ Typ Code Bezeichnung Codesystem 0‑L 1 Mitglied 2.16.840.1.113883.3.7.1.1 0‑L 3 Familienangehörige 2.16.840.1.113883.3.7.1.1 0‑L 5 Rentner 2.16.840.1.113883.3.7.1.1
Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) schlägt Text in originalText vor. HL7 V3: NullFlavors werden im @nullFlavor Attribut statt in @code angegeben.

FHIR-Profile

Basisstandard FHIR

Bundle

Das Bundle fasst die Composition zusammen.

StructureDefinition: medikationsplanplus-bundle

• Profile: https://simplifier.net/medikationsplanplus/bundle-1
• Canonical: http://fhir.de/StructureDefinition/medikationsplanplus/bundle

Composition

Die Composition stellt das FHIR-Gegenstück zum Dokument dar und beinhaltet alle anderen Resourcen.

StructureDefinition: medikationsplanplus-composition

• Profile: https://simplifier.net/medikationsplanplus/composition-1
• Canonical: http://fhir.de/StructureDefinition/medikationsplanplus/composition

Patient

Der Patient des Medikationsplans.

StructureDefinition: medikationsplanplus-patient

• Profile: https://simplifier.net/medikationsplanplus/patient-1
• Canonical: http://fhir.de/StructureDefinition/medikationsplanplus/patient

Practitioner (Author)

Der Ersteller/Ausdruckende des Medikationsplans.

StructureDefinition: medikationsplanplus-practitioner

• Profile: https://simplifier.net/medikationsplanplus/practitioner-1
• Canonical: http://fhir.de/StructureDefinition/medikationsplanplus/practitioner

Custodian (Organization)

Wird zunächst nicht verwendet.

Medikation

Anhang

Referenzen

Abbildungen