eRezept

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche


Kontributoren 
Logo bvitg.JPG bvitg Berlin
Logo telekom healthcare.png DTHS Essen
Logo-Hcs.jpg Heitmann Consulting and Services GmbH, Gefyra GmbH Hürth, Berlin
Logo medatixx.jpg medatixx Eltville
Logo Medisoftware.png MediSoftware Kiel
Logo-hsnr.png HS Niederrhein Krefeld
Logo akdae.gif Arzneimittelkommission der deutschen Ärzteschaft (AkdÄ) Berlin
DHAEV logo.png HÄVG Hausärztliche Vertragsgemeinschaft AG Köln
Logo bitcom.png Bitkom e.V. Berlin

Inhaltsverzeichnis

Dokumenteninformationen

Dokumentenhistorie

Verordnungsmanagement
KBV-Muster 2 (Krankenhausverordnung) auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen
Status Typ Version Datum PDF Wiki ART-DECOR
Abstimmung
Si-reconc.svgAbgleich STU 0.97 30.11.2020 Download.png Link.png Link.png
Ergebnis 
Abstimmung von bisSymbol support vote.svgSymbol oppose vote.svgSymbol neutral vote.svgOhne VotumStimmenErgebnis
30.11.2020-11.01.2021 2 0 0 0 2 100%
Kommentare: Abstimmungsankündigung_20201030, Abstimmungseröffnung_20201130
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[1] und der Technischen Komitees von HL7 Deutschland e. V. [2]

Ansprechpartner und Autoren

  • Dr. Frank Oemig, DTHS, bvitg
  • Dr. med. Kai U. Heitmann, HL7 Deutschland e.V., Heitmann Consulting and Services, Gefyra GmbH
  • Rico Tetmeyer, medatixx
  • Elisabeth Pantazoglou, HS Niederrhein

Kontributoren

  • Daniel Grandt, Arzneimittelkommission der deutschen Ärzteschaft (AkdÄ), Berlin
  • HÄVG Hausärztliche Vertragsgemeinschaft AG, Köln
  • Bitkom e.V., Berlin
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 .

Disclaimer

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

[Abbildung 1] 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 [3] (wo möglich, sonst STU 3 [4]) 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" [5] und "Arztbrief Plus"[6]

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

  • HL7 Deutschland: FHIR Basisprofile[7]

Dieser Implementierungsleitfaden basiert weiterhin auf Vorarbeiten folgender Leitfäden:

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

Art-decor-logo2016.jpg

Es sei darauf verwiesen, dass alle CDA-spezifischen technischen Artefakte wie Templates und Value Sets auf ART-DECOR®[9] 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[10].

Pmp-templates.png

Pmp-templates.png

[Abbildung 2] Beispiel der Ansicht eines Templates und die zugehörige Navigation

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

Pmp-simplifier.png

Pmp-simplifier.png

[Abbildung 3] Frontseite des Projekts auf Simplifier.net (FHIR-Profile)

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

Pmp-fhirundartdecor.png

Pmp-fhirundartdecor.png

[Abbildung 4] 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 für die eVerordnung, d.h. wie diese inhaltlich strukturiert sind.

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

[Abbildung 5] 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
    • speziell die Integrationsprofile XDS, XDM und XDR
  • Telematikinfrastruktur (in Vorbereitung)
    • KOM-LE
    • ePA
  • KV-Connect
  • SafeMail
  • FTP
  • eRezept-Server
  • ...

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

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.

An dieser Stelle muss explizit darauf hingewiesen werden, dass es sich um ein elektronisches Dokument mit besonderen Anforderungen an Vertraulichkeit, Authentizität und Integrität handelt, da besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO enthalten sind und damit ein hoher Schutzbedarf besteht. Dies ist bei der Implementierung durch geeignete technische und organisatorische Maßnahmen zu berücksichtigen, die an dieser Stelle nicht eingehend betrachtet werden. Die Umsetzung entsprechender Maßnahmen liegt in der Zuständigkeit der beteiligten Akteure in ihrer Rolle als "Verantwortlicher" im Sinne des Art. 4 DSGVO.

Akteure

Folgende Akteure kommen in Kontakt mit einer Verordnung/ einem Rezept

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

(Bei allgemeineren Verordnungen würden dann auch weitere Akteure (z.B. Physiotherapeuten, Sanitätshäuser, ...) auftauchen. Dies wird in dem Informationsmodell berücksichtigt. In diesem IG geht es aber erstmal nur um Muster 16.)

Transportwege

  1. Arzt – Patient/Angehöriger/Bevollmächtigter – Apotheke – Apothekenrechenzentrum – Krankenkasse – Kassenärztliche Vereinigung
  2. Krankenhaus – Patient/Angehöriger/Bevollmächtigter – Apotheke – Apothekenrechenzentrum – Krankenkasse – Kassenärztliche Vereinigung
  3. Arzt – Patient/Angehöriger/Bevollmächtigter – Apotheke – Apothekenrechenzentrum – Berufsgenossenschaft – Kassenärztliche Vereinigung

Anstelle des Patienten können auch Bevollmächtigte oder Pflegedienste das Rezept überbringen.


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

ERezept Use Cases.jpg

[Abbildung 6] 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

[Abbildung 7] 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

Prozesshierarchie

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.

[Abbildung 8] 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.

Akteurshierachie

[Abbildung 9] 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

[Abbildung 10] Dokumentenhierarchie

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

Zusammenhang zwischen den Dokumenten

[Abbildung 11] Zusammenhang zwischen den Dokumenten

Damit ergeben sich in einer Template-Darstellung folgende Dokumentbeziehungen:

Dokumentbeziehungen

[Abbildung 12] Dokumentbeziehungen

Informationsmodell (als Domain Model)

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

Domänenmodell

[Abbildung 13] 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:

Headerdaten-Dataset

[Abbildung 14] Dataset Headerdaten

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

Cdam16 daten.jpg

[Abbildung 15] 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.

Hauptdaten-Dataset

[Abbildung 16] Domänenmodell CDA


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 .

Dosier-Beispiele

Im Folgenden sind die Dosierschemas aufgelistet und mit Beispielen (CDA-Instanzenfragmente) verdeutlicht. Ein Dosierschema besteht typischerweise aus Zeitangaben (der Einnahme) und der Dosis (Medikamentenmenge).

Unterstützte Dosierschemas (Zeitangaben):

  1. Zeitpunkt (einmalige Gabe)
  2. Ereignis-gesteuert, ggf. mit Offset (z. B. morgens, mittags, nach dem Frühstück, 1 h nach dem Mittagessen, etc.)
  3. Periodische Intervalle, ggf. mit Wiederholung (z. B. täglich, wöchentlich, alle 8 Stunden, donnerstags, etc.)
  4. Kombinationen aus 2 und 3 (z. B. donnerstags 30 Minuten vor dem Frühstück)

Unterstützte Dosierschemas (Dosis):

  1. Menge und (standardisierte) Einheit (100 mg, 1 Tablette, 2 Hübe, 10 ml)
  2. Mengenbereich von bis und (standardisierte) Einheit (1-2 Tabletten)
  3. Laufraten (Menge und Einheit pro Zeit, im ambulanten Setting eher unüblich)

Diese sollen durch die folgenden Beispiele erläutert werden.

Zeitpunkt (einmalige Gabe)

Einmalig Gabe

Die Einnahme der Dosis erfolgt einmalig. Über diesen Mechanismus kann auch angegeben werden, dass der Einnahmezeitpunkt unbekannt ist.

einmalig am 9. Januar 2019

<effectiveTime value="20190109"/>

einmalig 100 ml am 14. September 2018

<effectiveTime value="20180914"/>
<doseQuantity value="100" unit="ml"/>

Einnahmezeitpunkt unbekannt

<effectiveTime nullFlavor="UNK"/>

Ereignis-gesteuert, ggf. mit Offset

Zeitelement zur Aufnahme des Einnahmezeitpunkts, ausgedrückt als Ereignis, ggf. mit Offset

Macht die Angabe von ereignisbezogenen Wiederholungen (z. B. Morgens/Mittags/Abends/zur Nacht/Nachts) möglich und gibt ein periodisches Zeitintervall an, in dem die Wiederholung auf Aktivitäten des täglichen Lebens oder anderen wichtigen Ereignissen basiert, die zeitabhängig sind, jedoch nicht vollständig von der Zeit bestimmt werden.

mittags 10 mg

<effectiveTime xsi:type="EIVL_TS">
  <event code="CD"/>
</effectiveTime>
<doseQuantity value="10" unit="mg"/>

morgens 1 (Stück)

<effectiveTime xsi:type="EIVL_TS">
  <event code="CM"/>
</effectiveTime>
<doseQuantity value="1" unit="{Stück}"/>

abends 1-2 (Hübe)

<effectiveTime xsi:type="EIVL_TS">
  <event code="CV"/>
</effectiveTime>
<doseQuantity>
  <low value="1" unit="{Hübe}"/>
  <high value="2" unit="{Hübe}"/>
</doseQuantity>

30 Minuten nach dem Abendessen 1 Stück

<effectiveTime xsi:type="EIVL_TS">
  <event code="PCV"/>
  <offset value="30" unit="min"/>
</effectiveTime>
<doseQuantity value="1" unit="{Stück}"/>

Die folgenden Tabellen geben eine Übersicht über Einnahmezeitpunkte (Ereignisse bzw. die zu verwendenden Codes) sowie mögliche Mahlzeitenhinweisen.

Morgens Mittags Abends zur Nacht
CM CD CV HS
Frühstück Mittagessen Abendessen (Nachtruhe)
Vor der Mahlzeit ACM ACD ACV -
Während der Mahlzeit CM CD CV -
Nach der Mahlzeit PCM PCD PCV -
Zwischen Frühstück und Mittagessen ICM - -
Zwischen Mittagessen und Abendessen - ICD -
Zwischen Abendessen und Nachtruhe - - ICV

Das zugehörige Value Set (mit deutschen Übersetzungen) findet sich hier.


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.
Id1.2.276.0.76.11.463Gültigkeit2018‑09‑11 21:05:52
StatusKyellow.png EntwurfVersions-Label
NameTimingEventBezeichnungTimingEvent
BeschreibungOriginal TimingEvent Value Set von HL7 mit deutschen Designationen
Benutzung: 3
IdNameTyp
Template
hl7de-template-4023Einzeldosierungen (mpp 2018) DYNAMIC
hl7de-template-4023Einzeldosierungen (mpp 2018) DYNAMIC
hl7de-template-4023Einzeldosierungen (mpp 2018) DYNAMIC
2 Quell-Codesysteme
2.16.840.1.113883.5.139 - TimingEvent - FHIR: http://terminology.hl7.org/CodeSystem/v3-TimingEvent
2.16.840.1.113883.3.1937.99.61.48.5.1 - FHIR: urn:oid:2.16.840.1.113883.3.1937.99.61.48.5.1
Level/ TypCodeBezeichnungCodesystemDesignationsBeschreibung
0‑L
AC
AC
TimingEvent
DE-DE.png vor der Mahlzeit (vom lat. ante cibus)
0‑L
ACD
ACD
TimingEvent
DE-DE.png vor dem Mittagessen (vom lat. ante cibus diurnus)
0‑L
ACM
ACM
TimingEvent
DE-DE.png vor dem Frühstück (vom lat. ante cibus matutinus)
0‑L
ACV
ACV
TimingEvent
DE-DE.png vor dem Abendessen (vom lat. ante cibus vespertinus)
0‑S
C
C
TimingEvent
DE-DE.png Mahlzeit (vom lat. cibus)
1‑L
CD
CD
TimingEvent
DE-DE.png Mittagessen (vom llat. cibus diurnus)
1‑L
CM
CM
TimingEvent
DE-DE.png Frühstück (vom lat. cibus matutinus)
1‑L
CV
CV
TimingEvent
DE-DE.png Abendessen (vom llat. cibus vespertinus)
0‑L
HS
HS
TimingEvent
DE-DE.png Vor dem Schlafengehen (einer regulären Phase Schlaf, also kein Nickerchen)
0‑L
IC
IC
TimingEvent
DE-DE.png zwischen Mahlzeiten (vom lat. inter cibus)
0‑L
ICD
ICD
TimingEvent
DE-DE.png zwischen Mittagessen und Abendessen
0‑L
ICM
ICM
TimingEvent
DE-DE.png zwischen Frühstück und Mittagessen
0‑L
ICV
ICV
TimingEvent
DE-DE.png zwischen Abendessen und vor dem Schlafengehen
0‑L
PC
PC
TimingEvent
DE-DE.png nach der Mahlzeit (vom lat. post cibus)
0‑L
PCD
PCD
TimingEvent
DE-DE.png nach dem Mittagessen (vom lat. post cibus diurnus)
0‑L
PCM
PCM
TimingEvent
DE-DE.png nach dem Frühstück (vom lat. post cibus matutinus)
0‑L
PCV
PCV
TimingEvent
DE-DE.png nach dem Abendessen (vom lat. post cibus vespertinus)
0‑L
WAKE
WAKE
TimingEvent
DE-DE.png Nach dem Aufwachen von einer regulären Phase Schlaf
0‑L
NOC
NOC
2.16.840.1.113883.3.1937.99.61.48.5.1
DE-DE.png In der Nacht

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.


Periodische Intervalle, ggf. mit Wiederholung

Zeitintervall, das sich periodisch wiederholt.

Periodische Intervalle haben zwei Eigenschaften, Phase und Periode. Die Phase gibt den "Typ" Intervall" an, der sich jede Periode wiederholt.

Wiederholungsintervall (periodische Intervallsequenz), gibt an

  • die Dauer jedes Vorkommens bzw. der Zeit zwischen den Vorkommnissen (period)
  • der Ankerzeitpunkt (Startzeitpunkt als Datum oder Datum und Uhrzeit), an dem die periodische Intervallsequenz beginnt (phase).

Zeitelement zur Aufnahme des Einnahmezeitpunkts, ausgedrückt als Phase, ggf. mit Wiederholungsintervall

Alle 8 Stunden 1 Stück (beginnend am 12.09.2018 um 06:00 Uhr)

<effective_time xsi:type="PIVL_TS">
   <phase value="201809120600"/>
   <!-- Beginn: 12.09.2018 06:00 Uhr -->
   <period value="8" unit="h"/>
   <!-- Wiederholperiode 8 Stunden -->
</effective_time>
<doseQuantity value="1" unit="{Stück}"/>

1x täglich 10 ml (beginnend am 10.09.2018)

<effective_time xsi:type="PIVL_TS">
   <phase value="20180913"/>
   <!-- Beginn: 10.09.2018 -->
   <period value="1" unit="d"/>
   <!-- Wiederholperiode 1 Tag -->
</effective_time>
<doseQuantity value="10" unit="ml"/>

Jeden Donnerstag 1 Stück

<effectiveTime xsi:type="PIVL_TS">
  <phase value="20180913"/>
  <!-- Jeden Donnerstag (der 13.09.2018 ist der erste Donnerstag innerhalb der Gebrauchsperiode) -->
  <period value="1" unit="wk"/>
  <!-- Wiederholperiode 1 Woche -->
</effectiveTime>
<doseQuantity value="1" unit="{Stück}"/>

Jeden Donnerstag um 14:00 Uhr 200 mg

<effectiveTime xsi:type="PIVL_TS">
  <phase value="201809131400"/>
  <!-- Jeden Donnerstag (der 13.09.2018 ist der erste Donnerstag innerhalb der Gebrauchsperiode), hier mit Zeitangabe 14:00 Uhr -->
  <period value="1" unit="wk"/>
  <!-- Wiederholperiode 1 Woche -->
</effectiveTime>
<doseQuantity value="200" unit="mg"/>

Jeden zweiten Tag (ab dem 9. Februar 2019) um 8:00 Uhr 1 Stück

<effectiveTime xsi:type="PIVL_TS">
  <phase value="201902090800"/>
  <!-- der 09.02.2019 ist der Starttag innerhalb der Gebrauchsperiode), hier mit Zeitangabe 8:00 Uhr -->
  <period value="2" unit="d"/>
  <!-- Wiederholperiode 2 Tage -->
</effectiveTime>
<doseQuantity value="1" unit="{Stück}"/>

Einmal in der Woche 100 ml (ohne spezifische Tagesangabe, im Zeitraum von Mai bis August 2019)

<effectiveTime xsi:type="PIVL_TS">
  <phase>
    <low value="201905"/>
    <high value="201908"/>
  </phase>
  <!-- Angabe der Gebrauchsperiode: Mai 2019 bis August 2019 -->
  <period value="1" unit="wk"/>
  <!-- Wiederholperiode 1 Woche -->
</effectiveTime>
<doseQuantity value="100" unit="ml"/>

Die folgende Tabelle gibt eine Übersicht über die möglichen Zeiteinheiten (UCUM).

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.
Id1.2.276.0.76.11.452Gültigkeit2017‑04‑01
StatusKyellow.png EntwurfVersions-Label
NameZeiteinheitenBezeichnungZeiteinheiten (UCUM)
Benutzung: 7
IdNameTyp
Template
hl7de-template-4023Einzeldosierungen (mpp 2018) DYNAMIC
hl7de-template-4023Einzeldosierungen (mpp 2018) DYNAMIC
hl7de-template-4023Einzeldosierungen (mpp 2018) DYNAMIC
hl7de-template-4023Einzeldosierungen (mpp 2018) DYNAMIC
hl7de-template-4023Einzeldosierungen (mpp 2018) DYNAMIC
hl7de-template-4023Einzeldosierungen (mpp 2017) DYNAMIC
hl7de-template-90023Einnahmedauer DYNAMIC
Quell-Codesystem
2.16.840.1.113883.6.8 - Unified Code for Units of Measure - FHIR: http://unitsofmeasure.org - HL7 V2: UCUM
Level/ TypCodeBezeichnungCodesystem
0‑L
d
Day
Unified Code for Units of Measure
0‑L
a
Year
Unified Code for Units of Measure
0‑L
h
Hour
Unified Code for Units of Measure
0‑L
min
Minute
Unified Code for Units of Measure
0‑L
mo
Month
Unified Code for Units of Measure
0‑L
s
Second
Unified Code for Units of Measure
0‑L
wk
Week
Unified Code for Units of Measure

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.


Periodische Intervalle mit Ereignis, ggf. mit Wiederholung

Zeitelement zur Aufnahme des Einnahmezeitpunkts, ausgedrückt als Phase und Ereignis, ggf. mit Wiederholungsintervall

Die beiden vorhergehenden Dosierschema-Typen können auch kombiniert werden, um komplexere Dosierangaben zu spezifizieren.

Jeden Donnerstag 30 Minuten vor dem Frühstück

<effectiveTime xsi:type="SXPR_TS">
  <comp xsi:type="PIVL_TS">
    <phase value="20180913"/>
    <!-- Jeden Donnerstag (der 13.9.2018 ist der erste Donnerstag innerhalb der Gebrauchsperiode) -->
    <period value="1" unit="wk"/>
    <!-- Wiederholperiode 1 Woche -->
  </comp>
  <comp xsi:type="EIVL_TS" operator="A">
    <!-- 30 Minuten vor dem Frühstück -->
    <event code="ACM"/>
    <offset value="30" unit="min"/>
  </comp>
</effectiveTime>


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 .

Komplexe Dosierangaben

Im Folgenden finden sich weitere komplexere Dosierbeispiele, die ergänzend zum Implementierungsleitfaden „Medikationsmanagement“ der AG eMedikation prägnante Beispiele von komplexen Dosierschemata auflisten. Die Beispiele sind im Rahmen des Projekts Digitales Gesundheitsnetzwerk (DiGeN) des AOK BV entstanden.

Phenprocoumon

Phenprocoumon (Marcumar®, Falithrom®, div. Generika; ATC: B01AA04)

Mo Di Mi Do Fr Sa So
Patient A 1 1 1 1/2 1 0,25 1

[Tabelle 1] Beispiel 1a Phenprocoumon

Mo Di Mi Do Fr Sa So
Patient B 1 0,5 1 0,5 1 0,5 1

[Tabelle 2] Beispiel 1b Phenprocoumon

Mo Di Mi Do Fr Sa So
Patient B 1,5 1,5 1 1 1,5 1 1,5

[Tabelle 3] Beispiel 1c Phenprocoumon

Therapie des Multiplen Myeloms

Therapie des Multiplen Myeloms mit

  • Bortezomib (Velcade ®, ATC: L01XX32)
  • Melphalan (Alkeran®, ATC: L01AA03)
  • Prednisolon (div. Anbieter, ATC: H02AB06)
  • Aciclovir (div. Anbieter, ATC: J05AB01)
Mo Di Mi Do Fr Sa So Anmerkung
Velcade Lösung 2.067 mg in Zubereitung 2.067 mg in Zubereitung s.c Gabe in Praxis
Alkeran 2 mg Tabl. 8-0-0-0 8-0-0-0 8-0-0-0 8-0-0-0 oral
Prednisolon 50 mg Tabl. 2-0-0-0 2-0-0-0 2-0-0-0 2-0-0-0 oral
Aciclovir 400 mg Tabl. 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 oral

[Tabelle 4] Beispiel 2 Woche 1 Multiples Myelom

Mo Di Mi Do Fr Sa So Anmerkung
Velcade Lösung 2.067 mg in Zubereitung 2.067 mg in Zubereitung s.c Gabe in Praxis
Alkeran 2 mg Tabl.
Prednisolon 50 mg Tabl.
Aciclovir 400 mg Tabl. 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 oral

[Tabelle 5] Beispiel 2 Woche 2 Multiples Myelom

Mo Di Mi Do Fr Sa So Anmerkung
Velcade Lösung
Alkeran 2 mg Tabl.
Prednisolon 50 mg Tabl.
Aciclovir 400 mg Tabl. 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 oral

[Tabelle 6] Beispiel 2 Woche 3 Multiples Myelom

Mo Di Mi Do Fr Sa So Anmerkung
Velcade Lösung 2.067 mg in Zubereitung 2.067 mg in Zubereitung s.c Gabe in Praxis
Alkeran 2 mg Tabl.
Prednisolon 50 mg Tabl.
Aciclovir 400 mg Tabl. 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 oral

[Tabelle 7] Beispiel 2 Woche 4 und 5 Multiples Myelom

Mo Di Mi Do Fr Sa So Anmerkung
Velcade Lösung
Alkeran 2 mg Tabl.
Prednisolon 50 mg Tabl.
Aciclovir 400 mg Tabl. 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 oral

[Tabelle 8] Beispiel 2 Woche 6 Multiples Myelom

Mo Di Mi Do Fr Sa So Anmerkung
Velcade Lösung 2.067 mg in Zubereitung s.c Gabe in Praxis
Alkeran 2 mg Tabl. 8-0-0-0 8-0-0-0 8-0-0-0 8-0-0-0 oral
Prednisolon 50 mg Tabl. 2-0-0-0 2-0-0-0 2-0-0-0 2-0-0-0 oral
Aciclovir 400 mg Tabl. 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 oral

[Tabelle 9] Beispiel 2 Woche 7 Multiples Myelom

Mo Di Mi Do Fr Sa So Anmerkung
Velcade Lösung 2.067 mg in Zubereitung s.c Gabe in Praxis
Alkeran 2 mg Tabl.
Prednisolon 50 mg Tabl.
Aciclovir 400 mg Tabl. 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 oral

[Tabelle 10] Beispiel 2 Woche 8 Multiples Myelom

Mo Di Mi Do Fr Sa So Anmerkung
Velcade Lösung
Alkeran 2 mg Tabl.
Prednisolon 50 mg Tabl.
Aciclovir 400 mg Tabl. 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 oral

[Tabelle 11] Beispiel 2 Woche 9 Multiples Myelom

Mo Di Mi Do Fr Sa So Anmerkung
Velcade Lösung 2.067 mg in Zubereitung s.c Gabe in Praxis
Alkeran 2 mg Tabl.
Prednisolon 50 mg Tabl.
Aciclovir 400 mg Tabl. 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 oral

[Tabelle 12] Beispiel 2 Woche 10 und 11 Multiples Myelom

Mo Di Mi Do Fr Sa So Anmerkung
Velcade Lösung
Alkeran 2 mg Tabl.
Prednisolon 50 mg Tabl.
Aciclovir 400 mg Tabl. 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 oral

[Tabelle 13] Beispiel 2 Woche 12 bis 14 Multiples Myelom

Patient mit Dialysebehandlung

Mo Di - Dialysetag Mi Do Fr - Dialysetag Sa So Anmerkung
Furosemid 500 mg Tabl (ATC: C03CA01) 0,5-0,5-0-0 0,5-0,5-0-0 0,5-0,5-0-0 0,5-0,5-0-0 0,5-0,5-0-0 0,5-0,5-0-0 0,5-0,5-0-0 oral
Ramipril 5 mg Tabl (ATC: C09AA05) 1-0-0,5-0 1-0-0-0 1-0-0,5-0 1-0-0,5-0 1-0-0-0 1-0-0,5-0 1-0-0,5-0 oral
Metoprolol 47,5 mg Retardtbl (ATC: C07AB02) 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 1-0-1-0 oral
Amlodipin 5 mg Tabl (ATC: C08CA01) 1-0-0-0 1-0-0-0 1-0-0-0 1-0-0-0 1-0-0-0 Oral
Calcitriol 0,25 mg Tabl (ATC: A11CC04) 1-0-0-0 1-0-0-0 Oral
Sevelamercarbonat 800 mg Tabl (ATC: V03AE02) 2 2 2 2 2 2 2 Oral zur Hauptmahlzeit
Calciumacetat 475 mg Tabl (ATC: V03AE07) 1-2-1-0 1-2-1-0 1-2-1-0 1-2-1-0 1-2-1-0 1-2-1-0 1-2-1-0 oral
Eisen(III)-gluconat 40 mg (ATC: B03AC07) 0-1-0-0 i.v. in der Praxis
Erythropoetin 3000 IE Fspr (ATC: B03XA01) 1 1 i.v. in der Praxis
Gabapentin 300 mg Hartkaps (ATC: N03AX12) 1-0-0-0 0-2-0-0 1-0-0-0 1-0-0-0 0-2-0-0 1-0-0-0 1-0-0-0 Oral NACH der Dialyse

[Tabelle 14] Beispiel 3 Dialysepatient

  1. Beispiel 1a Phenprocoumon
  2. Beispiel 1b Phenprocoumon
  3. Beispiel 1c Phenprocoumon
  4. Beispiel 2 Woche 1 Multiples Myelom
  5. Beispiel 2 Woche 2 Multiples Myelom
  6. Beispiel 2 Woche 3 Multiples Myelom
  7. Beispiel 2 Woche 4 und 5 Multiples Myelom
  8. Beispiel 2 Woche 6 Multiples Myelom
  9. Beispiel 2 Woche 7 Multiples Myelom
  10. Beispiel 2 Woche 8 Multiples Myelom
  11. Beispiel 2 Woche 9 Multiples Myelom
  12. Beispiel 2 Woche 10 und 11 Multiples Myelom
  13. Beispiel 2 Woche 12 bis 14 Multiples Myelom
  14. Beispiel 3 Dialysepatient
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 .

Mapping-Tabelle

Die nachfolgende Tabelle stellt eine Übersicht dar, welche Informationen wo wie zusammengehören. Ein Mapping zwischen den Schemata aus der TI und den beschriebenen CDA-Templates ist möglich.

Die Tabelle ist hierbei über die Spalte ART-DECOR Data-Set sortiert:

Feld-Nr. Muster 16 KBV-Bezeichnung / Feldinhalt ART-DECOR-Dataset Informationsmodell Klasse.Attribut CDA-Template OID TI Bemerkung
1 Codierleiste - - - -   nicht zu spezifizieren
9a Apothekennummer Apotheken-Nummer / IK Leistungserbringer .KassenNr        
19 Ausstellungsdatum Ausstellungsdatum eVerschreibung .Ausgabedatum ClinicalDocument .effectiveTime      
12 Fälschungssicheres Ausfüllen des Vordrucks - - -     Diese Eigenschaft kann durch elektronische Signatur der Dokumente erreicht werden, was aber außerhalb des Skopes dieses Leitfadens liegt.
13 Position des Vertragsarztstempels Arztdaten Autor author.id      
13a + 18 Arzt-Nummer (LANR) LANR Person.id author .assignedAuthor .id .[root="1.2.276.0.76.4.16"] .id.@extension 1.2.276.0.76.4.16    
13b   Name Person.Name author .assignedAuthor .assignedPerson .name.family      
13c   Vorname Person.Vorname author .assignedAuthor .assignedPerson .name.given      
13d   Telefon (Arzt) Person.Kontaktdaten author .assignedAuthor .telecom      
13e   Berufsbezeichnung Autor .Berufsbezeichnung        
13f   Titel Person.Name author .assignedAuthor .assignedPerson .name.given      
17 Betriebsstätten-Nummer Betriebsstätte BSNR Organisation .Identifikation author .representedOrganisation .id      
17a   Betriebs stättenanschrift Organisation.Adresse author .representedOrganisation .addr      
17b   Betriebsstättenname Organisation.Name author .assignedAuthor .representedOrganisation .name      
17c   Betriebsstätte Telefon Organisation.Adresse author .assignedAuthor .representedOrganisation .telecom      
17f   ASV-Teamnummer Team.Identifikation author .assignedAuthor .id.[root= "1.2.276.0.76.4.99999"] .id.@extension 1.2.276.0.76.4.99999   noch die richtige OID für das Codesystem zuordnen
14 Personalienfeld Patientendaten Person recordTarget     wie in den anderen Formularen
- Name des Versicherten Name Person.Name recordTarget .name      
14c Vorname des Versicherten Vorname Person.Name .Vorname recordTarget .name.given   VSD.Versicherter .Person.Vorname  
14b   Nachname Person.Name .Nachname recordTarget .name.family   VSD.Versicherter .Person.Nachname  
14f   Vorsatzwort Person.Name .Vorsatzwort recordTarget .name.prefix + "VV"   VSD.Versicherter .Person .Vorsatzwort  
14g   Namenszusatz Person.Name .Namenszusatz recordTarget .name.prefix + "NB"   VSD.Versicherter .Person .Namenszusatz  
14h   Titel Person.Name.Titel recordTarget .name.prefix + "AC"      
14i   PostfachAdresse (PLZ, Postfach, Ort, Land) Person.Ort recordTarget .addr/postBox      
14j   Strassenadresse (Strasse, Hausnummer, PLZ, Ort, Land, Anschriftenzusatz) Person.Ort .Straße recordTarget .addr/streetName      
-   Versichertendaten - PolicyActivity      
14a Krankenkasse bzw. Kostenträger KrankenkassenName Kostenträger PolicyActivity .performer .assignedEntity.id     wird indirekt über die Verschreibung realisiert
14e Kostenträgerkennung Kassen-IKNr Kostenträger .KassenNr PolicyActivity .performer .assignedEntity .representedOrganisation .name      
14k KV-Zuordnung KV-Zuordnung - PolicyActivity .entryRelationship .observation [code/@code="KV-Zuordnung"] .value 1.2.276.0.76.3.1 .135.8.5.99   im Modell weggelassen
14l WOP-Kennzeichen WOP-Kennzeichen - PolicyActivity .entryRelationship .observation [code/@code="WOP"] .value 1.2.276.0.76.3.1 .135.8.5.99   im Modell weggelassen
15 Versicherten-Nummer eGK-Nummer Person.id PolicyActivity .participant .participantRole .id      
16 Status Status (1=Mitglied, 3=Familie, 5=Rentner) Patient .Versichertenstatus PolicyActivity .participant .participantRole .code 2.16.840.1.113883 .3.7.1.1    
24 weitere Kennzeichen Weitere Kennzeichen: 1=ASV, 4=Entlassmangement, 7=Terminservice unklar eVerschreibung .weitereKennzeichen PolicyActivity .entryRelationship .observation [code/@code= "KENNZEICHEN"] .value 1.2.276.0.76.5.484   wo das genutzt wird
25 besondere Personengruppe Besondere Personengruppe Patient .besondere Personengruppe PolicyActivity .entryRelationship .observation [code/@code= "PRSNGRP"] .value 1.2.276.0.76.5.222    
26 DMP-Zuordnung DMP-Zuordnung Patient.DMP-Kennzeichnung DMPObservation .value 1.2.276.0.76.11.138    
14d Geburtsdatum des Versicherten Geburtsdatum Person.Geburtsdatum recordTarget.birthTime -    
-   Geschlecht Person.Geschlecht eGK-GeschlechtObservation .value 1.2.276.0.76.11.458    
-   eVerschreibung eVerschreibung ClinicalDocument .code=57833-6 1.2.276.0.76.10.1030"    
7 Sonder- kennzeichen bei der Verordnung von Arznei-, Verband- und Hilfsmitteln Sonder- kennzeichnungen = Rezeptmerkmale          
7a Hilfsmittel   Hilfsmittelrezept Spezialisierung von ClinicalDocument .code?     Feld 7=7,
Value Set für ClinicalDocument .code definieren
7b Impfstoff   Inhaltsstoff.Inhaltsstoff       Feld 8=8,
Value Set für ClinicalDocument .code definieren, oder Kennzeichen bei dem Medikament?
7c Sprechstunden Bedarf   Praxisrezept anderes recordTarget Template 1.2.276.0.76.3.1. 135.8.10.118   Arznei-/ Verbandmittel: Feld9=9
Hilfsmittel: Feld7=7 + Feld9=9
Impfstoff: Feld8=8 + Feld9=9
23 Verordnungszeile Verordnungszeile ist unterteilt in strukturiert und unstrukturiert Medikament RezeptSection .text.paragraph     mit Referenz auf das Medikament
23a   Strukturiert: - Medikament      
10 + 23a1 Aut idem Autidem BL => verschieben zu verordnetes Medikament Item.Substitution SubstitutionPermission .act.code   Medikament  
23a2   Menge Item.Menge .substanceAdministration .consumable .manufacturedProduct .manufacturedMaterial .quantity      
9d + 23a3 Arzneimittel- /Hilfsmittel-Nummer PZN Produkt.Identifier .substanceAdministration .consumable .manufacturedProduct .manufacturedMaterial .code 1.2.276.0.76.4.6    
23a4   Handelsname (kurz oder lang) Produkt.Handelsname .substanceAdministration .consumable .manufacturedProduct .manufacturedMaterial .name      
23a4a - Chargennummer   .substanceAdministration .consumable .manufacturedProduct .manufacturedMaterial .lotNumber      
23a6 - Packungsgröße- Menge Container .Packungsgröße- Menge        
23a7 - Packungsgröße- Einheit Container .Packungsgröße- Einheit   UCUM?    
23a8 - Darreichungsform: IFA-Code Medikament .Darreichungsform .substanceAdministration .consumable .manufacturedProduct .manufacturedMaterial .formCode      
23a8a - Art der Anwendung Einnahme.routing .substanceAdministration .routeCode      
23a11 - Wirkstoffmenge Inhaltsstoff .Menge+Einheit .substanceAdministration .consumable .manufacturedProduct .manufacturedMaterial .ingredient .quantity      
23a9 - Dosierung: Mo/Mi/Ab/zN => unter Medikament aufnehmen Einnahme Subordinate Substance Administration: effectiveTime + doseQuantity      
23a9a   wann einnehmen Einzelanwendung Subordinate Substance Administration: effectiveTime UCUM?    
23a9b   wieviel einnehmen Einzelanwendung Subordinate Substance Administration: doseQuantity UCUM?    
23a9c - Einnahmedauer (von-bis) Einnahme (Start- + Enddatum / Dauer) .substanceAdministration .effectiveTime      
23a10 - Zusatzinfo Item.Textzeile wichtige Angaben Section      
23b - Unstrukturiert - RezeptSection .text.paragraph      
23b1   Freitext (in Kombination mit aut idem) Rezeptur.Freitext "      
- Patienteninstruktionen   Einnahmehinweis Patienteninstruktionen Entry      
11 Verordnungen im Rahmen einer „künstlichen Befruchtung“ noch abbilden         mit in die Gebühren-Section?
2 Gebühr frei bzw. Gebührenpflichtig Zuzahlungsstatus: geb.pfl / geb.frei eVerordnung .Gebührenpflicht GebührenObservation.value 1.2.276.0.76.11.462   Abbildung über Value Set
2a Gebührenfrei " " GEBFREI 1.2.276.0.76.3.1 .135.8.11.25    
2b Gebührenpflichtig " " PFLICHTIG 1.2.276.0.76.3.1 .135.8.11.25    
3 Befreiung von der Notdienstgebühr " " NOCTU 1.2.276.0.76.3.1 .135.8.11.25    
4 Sonstige " "   über OTH abbilden    
8 Begründungspflicht noch abbilden         nicht verwenden
5 Unfall / Arbeitsunfall Unfallbetrieb Unfall -      
5a Unfall Unfall/Arbeitsunfall Unfall.Arbeitsunfall AccidentObservation .value     Accident Observation fehlt im IG
5b Arbeitsunfall Unfall/Arbeitsunfall " AccidentObservation .value     Abbildung als Value Set
5c Unfalltag Unfalltag Unfall.Unfallzeitpunkt AccidentObservation .effectiveTime      
5d Unfallbetrieb oder Arbeitgeber- nummer Unfallbetrieb = string Unfall .Unfallbetrieb AccidentSection.text      
6 Anspruchs- berechtigte nach dem Bundes- entschädigungs- gesetz / Bundes- versorgungs- gesetz noch abbilden         mit in die Gebühren-Section?
    eAbgabe eAbgabe   1.2.276.0.76.10.1031    
    Apotheken-Nummer/IK Kostenträger.KassenNr        
20 Abgabedatum in der Apotheke Abgabedatum eAbgabe.datum        
    Empfangsgestätigung - -     Unterschrift des Patienten
9 Abrechnungsfelder eAbrechnung eAbrechnung nicht exportiert? 1.2.276.0.76.10.1032    
9b Zuzahlung Zuzahlung eAbrechnung .Zuzahlung Zuzahlung Observation .value      
- Notdienstgebühr eAbgabe .Notdienstgebühr Notdienstgebühr Observation .value      
9c Gesamtbrutto Gesamt-Brutto eAbrechnung .Gesamtbrutto Gesamtbrutto Observation .value      
    Abgerechnetes Medikament -        
    Medikament siehe eVerschreibung        
9e Faktor Faktor eAbrechnung .Faktor        
9f Taxe Taxe eAbrechnung .Taxe        
    Vermerke der Krankenkasse eAbrechnung .Vermerk        

[Tabelle 1] Mappingtabelle

CDA-Spezifikation

Besonderheiten bei der CDA-Spezifikation "eRezept"

Erläuterungen zu Kardinalität, Konformität, NullFlavor

Es wird auf die Erläuterungen andernorts zu den Themen

  • Kardinalität, Konformität [1]
  • NullFlavor [2]

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 (IKNR) z. B. für Abrechnungen und Qualitätssicherungsmaßnahmen im Bereich der deutschen Sozialversicherung.

Hinweise zu den Identifikationen und Best Practice finden sich im Wiki des Interoperabilitätsforums[13], [14].

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.

<recordTarget typeCode="RCT" contextControlCode="OP">
  <patientRole classCode="PAT">
    <id root="1.2.276.0.76.4.8" extension="G970865268"/>
    ...
  </patientRole>
</recordTarget>

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.

<assignedAuthor>
     <id root="1.2.276.0.76.4.16" extension="381259301"/>
    ...
</assignedAuthor >

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.

<representedOrganization>
      <id root="1.2.276.0.76.4.17" extension="981069211"/>
      <name>Beispiel Arztpraxis</name>
</representedOrganization>

Institutionskennzeichen (IKNR)

Für die Angabe eines Institutionskennzeichens enthält im id-Element das @extension Attribut das Institutionskennzeichen (IKNR) und @root = 1.2.276.0.76.4.5, die OID für IK-Nummern in Deutschland

<scopingOrganization>
      <id root="1.2.276.0.76.4.5" extension="302205023"/>
      <name>Beispiel Krankenhaus</name>
</scopingOrganization >

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 wird an einer Stelle eine solche Informelle Erweiterung genutzt:

  • Bei Wirkstoff- und Packungsangaben zum Medikament

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 urn:hl7-org:pharm behandelt und verwenden in der Regel das Namespacepräfix pharm:.

Übersicht CDA Header und Body

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

eRezept

  1. Document
     16: eRezept (1.2.276.0.76.10.1030)
    1. Header
       CDA recordTarget (vomgt) (1.2.276.0.76.10.2048)
      1. *
         Personenname (1.2.276.0.76.10.90030)
    2. Header
       CDA recordTarget Praxis (vomgt) (1.2.276.0.76.10.2051)
      1. *
         CDA Organization (2.16.840.1.113883.10.12.151)
    3. Header
       CDA author Person (vomgt) (1.2.276.0.76.10.2049)
      1. Header
         CDA Person Elements (1.2.276.0.76.10.90010)
      2. Header
         CDA Organization Elements (vomgt) (1.2.276.0.76.10.90032)
    4. Header
       CDA author software (pmp) (1.2.276.0.76.10.2031)
    5. Header
       CDA custodian (1.2.276.0.76.10.2004)
    6. Header
       CDA legalAuthenticator (1.2.276.0.76.10.2020)
      1. Header
         CDA Assigned Entity Elements (1.2.276.0.76.10.90012)
        1. Header
           CDA Person Elements (1.2.276.0.76.10.90010)
        2. Header
           CDA Organization Elements (1.2.276.0.76.10.90011)
    7. Section
       Insurance Section (1.2.276.0.76.10.3103)
      1. Entry
         Coverage Activity (1.2.276.0.76.10.4263)
        1. Entry
           Policy Activity (1.2.276.0.76.10.4264)
          1. Entry
             Weitere Kennzeichen Observation (1.2.276.0.76.10.4280)
          2. Entry
             Person Group Observation (1.2.276.0.76.10.4273)
          3. Entry
             DMP Observation (1.2.276.0.76.10.4271)
          4. Entry
             Kv-Zuordnung Observation (1.2.276.0.76.10.4275)
          5. Entry
             eGK-Geschlecht Observation (1.2.276.0.76.10.4272)
    8. Section
       Rezept Section (16) (1.2.276.0.76.10.3134)
      1. Entry
         Medikation Verordnung Entry (16) (1.2.276.0.76.10.4298)
        1. Entry
           Einnahmedauer (1.2.276.0.76.10.90023)
        2. Entry
           Medikament (1.2.276.0.76.10.4025)
          1. Entry
             Material (1.2.276.0.76.10.90022)
        3. Entry
           Einzeldosierungen (1.2.276.0.76.10.4023)
          1. Entry
             Medikation Vorbedingung (1.2.276.0.76.10.90028)
        4. Entry
           UV Dispense Request (2.16.840.1.113883.10.21.4.2)
          1. Entry
             CDA Subject (Body) (2.16.840.1.113883.10.12.320)
          2. Entry
             CDA ManufacturedProduct (2.16.840.1.113883.10.12.312)
            1. Entry
               CDA LabeledDrug (2.16.840.1.113883.10.12.310)
            2. Entry
               CDA Material (2.16.840.1.113883.10.12.311)
            3. *
               CDA Organization (2.16.840.1.113883.10.12.151)
          3. Entry
             CDA Performer (Body) (2.16.840.1.113883.10.12.323)
            1. *
               CDA AssignedEntity (2.16.840.1.113883.10.12.153)
              1. *
                 CDA Person (2.16.840.1.113883.10.12.152)
              2. *
                 CDA Organization (2.16.840.1.113883.10.12.151)
          4. Entry
             CDA Participant (Body) (2.16.840.1.113883.10.12.321)
            1. Entry
               CDA Device (2.16.840.1.113883.10.12.315)
            2. Entry
               CDA PlayingEntity (2.16.840.1.113883.10.12.313)
          5. Entry
             CDA Participant (Body) (2.16.840.1.113883.10.12.321)
            1. Entry
               CDA Device (2.16.840.1.113883.10.12.315)
            2. Entry
               CDA PlayingEntity (2.16.840.1.113883.10.12.313)
          6. Entry
             CDA Participant (Body) (2.16.840.1.113883.10.12.321)
            1. Entry
               CDA Device (2.16.840.1.113883.10.12.315)
            2. Entry
               CDA PlayingEntity (2.16.840.1.113883.10.12.313)
          7. Entry
             CDA Participant (Body) (2.16.840.1.113883.10.12.321)
            1. Entry
               CDA Device (2.16.840.1.113883.10.12.315)
            2. Entry
               CDA PlayingEntity (2.16.840.1.113883.10.12.313)
        5. Entry
           UV Substitution Permission (2.16.840.1.113883.10.21.4.5)
        6. Entry
           Dosierung Freitext (1.2.276.0.76.10.4024)
    9. Section
       Wichtige Angaben (1.2.276.0.76.10.3042)
    10. Section
       Accident Section (16) (1.2.276.0.76.10.3135)
      1. Entry
         Accident Observation (06) (1.2.276.0.76.10.4281)
    11. Section
       Gebührenpflicht Section (16) (1.2.276.0.76.10.3136)
      1. Entry
         Gebührenpflicht (16) (1.2.276.0.76.10.4299)


[Abbildung 17] CDA-Dokument-Template für das eRezept

eAbgabe

  1. Document
     16: eAbgabe (1.2.276.0.76.10.1031)
    1. Header
       CDA recordTarget (vomgt) (1.2.276.0.76.10.2048)
      1. *
         Personenname (1.2.276.0.76.10.90030)
    2. Header
       CDA recordTarget Praxis (vomgt) (1.2.276.0.76.10.2051)
      1. *
         CDA Organization (2.16.840.1.113883.10.12.151)
    3. Header
       CDA author Person (vomgt) (1.2.276.0.76.10.2049)
      1. Header
         CDA Person Elements (1.2.276.0.76.10.90010)
      2. Header
         CDA Organization Elements (vomgt) (1.2.276.0.76.10.90032)
    4. Header
       CDA author software (pmp) (1.2.276.0.76.10.2031)
    5. Header
       CDA custodian (1.2.276.0.76.10.2004)
    6. Header
       CDA legalAuthenticator (1.2.276.0.76.10.2020)
      1. Header
         CDA Assigned Entity Elements (1.2.276.0.76.10.90012)
        1. Header
           CDA Person Elements (1.2.276.0.76.10.90010)
        2. Header
           CDA Organization Elements (1.2.276.0.76.10.90011)
    7. Header
       CDA relatedDocument eRezept (1.2.276.0.76.3.1.135.8.10.116)
    8. Section
       Insurance Section (1.2.276.0.76.10.3103)
      1. Entry
         Coverage Activity (1.2.276.0.76.10.4263)
        1. Entry
           Policy Activity (1.2.276.0.76.10.4264)
          1. Entry
             Weitere Kennzeichen Observation (1.2.276.0.76.10.4280)
          2. Entry
             Person Group Observation (1.2.276.0.76.10.4273)
          3. Entry
             DMP Observation (1.2.276.0.76.10.4271)
          4. Entry
             Kv-Zuordnung Observation (1.2.276.0.76.10.4275)
          5. Entry
             eGK-Geschlecht Observation (1.2.276.0.76.10.4272)
    9. Section
       Abgabe Section (16) (1.2.276.0.76.10.3137)
      1. Entry
         Medikation Abgabe Entry (16) (1.2.276.0.76.10.4301)
        1. Entry
           CDA ManufacturedProduct (2.16.840.1.113883.10.12.312)
          1. Entry
             CDA LabeledDrug (2.16.840.1.113883.10.12.310)
          2. Entry
             CDA Material (2.16.840.1.113883.10.12.311)
          3. *
             CDA Organization (2.16.840.1.113883.10.12.151)
        2. Entry
           Faktor (16) (1.2.276.0.76.10.4303)
        3. Entry
           Taxe (16) (1.2.276.0.76.10.4304)


[Abbildung 18] CDA-Dokument-Template für die eAbgabe

eAbrechnung

  1. Document
     16: eAbrechnung (1.2.276.0.76.10.1032)
    1. Header
       CDA recordTarget (vomgt) (1.2.276.0.76.10.2048)
      1. *
         Personenname (1.2.276.0.76.10.90030)
    2. Header
       CDA recordTarget Praxis (vomgt) (1.2.276.0.76.10.2051)
      1. *
         CDA Organization (2.16.840.1.113883.10.12.151)
    3. Header
       CDA author Person (vomgt) (1.2.276.0.76.10.2049)
      1. Header
         CDA Person Elements (1.2.276.0.76.10.90010)
      2. Header
         CDA Organization Elements (vomgt) (1.2.276.0.76.10.90032)
    4. Header
       CDA author software (pmp) (1.2.276.0.76.10.2031)
    5. Header
       CDA custodian (1.2.276.0.76.10.2004)
    6. Header
       CDA legalAuthenticator (1.2.276.0.76.10.2020)
      1. Header
         CDA Assigned Entity Elements (1.2.276.0.76.10.90012)
        1. Header
           CDA Person Elements (1.2.276.0.76.10.90010)
        2. Header
           CDA Organization Elements (1.2.276.0.76.10.90011)
    7. Header
       CDA relatedDocument eRezept (1.2.276.0.76.3.1.135.8.10.116)
    8. Header
       CDA relatedDocument eAbgabe (1.2.276.0.76.3.1.135.8.10.117)
    9. Section
       Insurance Section (1.2.276.0.76.10.3103)
      1. Entry
         Coverage Activity (1.2.276.0.76.10.4263)
        1. Entry
           Policy Activity (1.2.276.0.76.10.4264)
          1. Entry
             Weitere Kennzeichen Observation (1.2.276.0.76.10.4280)
          2. Entry
             Person Group Observation (1.2.276.0.76.10.4273)
          3. Entry
             DMP Observation (1.2.276.0.76.10.4271)
          4. Entry
             Kv-Zuordnung Observation (1.2.276.0.76.10.4275)
          5. Entry
             eGK-Geschlecht Observation (1.2.276.0.76.10.4272)
    10. Section
       Abgabe Section (16) (1.2.276.0.76.10.3137)
      1. Entry
         Medikation Abgabe Entry (16) (1.2.276.0.76.10.4301)
        1. Entry
           CDA ManufacturedProduct (2.16.840.1.113883.10.12.312)
          1. Entry
             CDA LabeledDrug (2.16.840.1.113883.10.12.310)
          2. Entry
             CDA Material (2.16.840.1.113883.10.12.311)
          3. *
             CDA Organization (2.16.840.1.113883.10.12.151)
        2. Entry
           Faktor (16) (1.2.276.0.76.10.4303)
        3. Entry
           Taxe (16) (1.2.276.0.76.10.4304)
    11. Section
       Zahlung Section (16) (1.2.276.0.76.10.3138)
      1. Entry
         Zuzahlung Observation (16) (1.2.276.0.76.10.4302)
      2. Entry
         Notdienstgebühr Observation (16) (1.2.276.0.76.3.1.135.8.10.132)
      3. Entry
         Gesamtbrutto Observation (16) (1.2.276.0.76.10.4300)


[Abbildung 19] CDA-Dokument-Template für die eAbrechnung

CDA Document Level Templates

Dieser Leitfaden enthält die Spezifikation für die drei eRezept-relevanten Dokumenttypen: eVerschreibung, eAbgabe und eAbrechnung.

Die Übermittlung des Sprechstundenbedarfs erfolgt mit Hilfe derselben Dokument-Templates, in dem unterschiedliche recordTarget-Templates über eine Choice diese Differenzierung vornehmen.

Personenbezogenes eRezept

Dieses Template verwendet dieselben Headertemplates wie alle anderen KV-Musterformulare. Für den rezeptbezogenen Anteil werden Strukturen analog zu dem EU-eRezept verwendet.

Id1.2.276.0.76.10.1030Gültigkeit2018‑11‑02 09:43:51
Andere Versionen mit dieser Id:
  • Kblank.png F16eRezept vom 2018‑11‑02 09:37:45
StatusKyellow.png EntwurfVersions-Label
NameF16eRezeptBezeichnung16: eRezept
BeschreibungKBV Muster 16: eRezept (Arzneiverordnungsblatt)
KontextPfadname //
KlassifikationCDA Document Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 11 Templates
Benutzt als NameVersion
1.2.276.0.76.10.2048InklusionKyellow.png CDA recordTarget (vomgt)DYNAMIC
1.2.276.0.76.10.2051InklusionKyellow.png CDA recordTarget Praxis (vomgt)DYNAMIC
1.2.276.0.76.10.2049InklusionKyellow.png CDA author Person (vomgt)DYNAMIC
1.2.276.0.76.10.2031InklusionKyellow.png CDA author software (pmp)DYNAMIC
1.2.276.0.76.10.2004InklusionKgreen.png CDA custodianDYNAMIC
1.2.276.0.76.10.2020InklusionKyellow.png CDA legalAuthenticatorDYNAMIC
1.2.276.0.76.10.3103ContainmentKyellow.png Insurance SectionDYNAMIC
1.2.276.0.76.10.3134ContainmentKyellow.png Rezept Section (16)DYNAMIC
1.2.276.0.76.10.3042ContainmentKyellow.png Wichtige AngabenDYNAMIC
1.2.276.0.76.10.3135ContainmentKyellow.png Accident Section (16)DYNAMIC
1.2.276.0.76.10.3136ContainmentKyellow.png Gebührenpflicht Section (16)DYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.2 CDA ClinicalDocument (with StructuredBody) (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:ClinicalDocument
(F16...ept)
Treetree.png@classCode
cs0 … 1FDOCCLIN
Treetree.png@moodCode
cs0 … 1FEVN
Treetree.pnghl7:realmCode
CS0 … 1R(F16...ept)
Treetree.pnghl7:typeId
II1 … 1R(F16...ept)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.1.3
Treeblank.pngTreetree.png@extension
st1 … 1FPOCD_HD000040
Treetree.pnghl7:templateId
II1 … 1M(F16...ept)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.1030
Treetree.pnghl7:id
II1 … 1M(F16...ept)
Treetree.pnghl7:code
CE (erforderlich)1 … 1M(F16...ept)
Treeblank.pngTreetree.png@codeSystemName
st0 … 1FLOINC
Treeblank.pngTreetree.png@codeSystem
oid0 … 1F2.16.840.1.113883.6.1
Treeblank.pngTreetree.png@code
cs0 … 1F57833-6
 Beispiel<code code="57833-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Prescription for medication"/>
Treetree.pnghl7:title
ST1 … 1R(F16...ept)
 CONF
Elementinhalt muss "Arzneiverordnungsblatt" sein
Treetree.pnghl7:effectiveTime
TS1 … 1RZeitpunkt, zu dem das Dokument elektronisch erzeugt wurde.(F16...ept)
Treetree.pnghl7:confidentialityCode
CE1 … 1R(F16...ept)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.16926 HL7 BasicConfidentialityKind (DYNAMIC)
Treetree.pnghl7:setId
II0 … 1R(F16...ept)
Treetree.pnghl7:versionNumber
INT0 … 1R(F16...ept)
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:recordTarget eingefügt vom Template 1.2.276.0.76.10.2048 CDA recordTarget (vomgt) (DYNAMIC)
  • hl7:recordTarget eingefügt vom Template 1.2.276.0.76.10.2051 CDA recordTarget Praxis (vomgt) (DYNAMIC)
Eingefügt0 … 1R von 1.2.276.0.76.10.2048 CDA recordTarget (vomgt) (DYNAMIC)
Treeblank.pngTreetree.pnghl7:recordTarget
0 … 1R(F16...ept)
 
Target.png
vomgt-data​element-4Kyellow.png Patientendaten Kyellow.png KV-Mustersammlung
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FRCT
Treeblank.pngTreeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
 Beispiel<recordTarget typeCode="RCT" contextControlCode="OP">
  <templateId root="1.2.276.0.76.10.2048"/>  <patientRole classCode="PAT">
    <!-- ... -->
  </patientRole>
</recordTarget>
Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
1 … 1M(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2048
Treeblank.pngTreeblank.pngTreetree.pnghl7:patientRole
1 … 1(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPAT
 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>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
0 … *R(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1MAdresse des Patienten(F16...ept)
 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>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:patient
0 … 1(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
 Beispiel<patient classCode="PSN" determinerCode="INSTANCE">
  <name>
    <!-- ... -->
  </name>
  <birthTime value="19541223"/></patient>
Eingefügt1 … 1M von 1.2.276.0.76.10.90030 Personenname (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1MDie 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.
(F16...ept)
 
Target.png
vomgt-data​element-26Kyellow.png Name Kyellow.png KV-Mustersammlung
vomgt-data​element-773Kyellow.png Full Name Kyellow.png 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>
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Titel(F16...ept)
wo [@qualifier='AC']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FAC
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:given
ENXP0 … *Vorname(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Namenszusatz(F16...ept)
wo [@qualifier='NB']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FNB
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Vorsatzwort(F16...ept)
wo [@qualifier='VV']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FVV
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:family
ENXP0 … *Nachname(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:suffix
ENXP0 … *Suffix(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CENPHier 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)

(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.​DATE.​MIN1 … 1MGeburtsdatum des Patienten(F16...ept)
 Beispiel<birthTime value="19491224"/>
Eingefügt0 … 1R von 1.2.276.0.76.10.2051 CDA recordTarget Praxis (vomgt) (DYNAMIC)
Treeblank.pngTreetree.pnghl7:recordTarget
0 … 1R(F16...ept)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FRCT
Treeblank.pngTreeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
 Beispiel<recordTarget typeCode="RCT" contextControlCode="OP">
  <templateId root="1.2.276.0.76.10.2048"/>  <patientRole classCode="PAT">
    <!-- ... -->
  </patientRole>
</recordTarget>
Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
1 … 1M(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2051
Treeblank.pngTreeblank.pngTreetree.pnghl7:patientRole
1 … 1(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPAT
 Beispiel<patientRole classCode="PAT">
  <!-- lokale Patientennummer -->
  <id extension="186245" root="1.2.276.0.76.3.1.139.3.871"/>  <patient classCode="ORG" determinerCode="INSTANCE">
    <!-- ... -->
  </patient>
</patientRole>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
0 … *R(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1MAdresse der Praxis(F16...ept)
 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>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:providerOrganization
1 … 1MBeinhaltet 2.16.840.1.113883.10.12.151 CDA Organization (DYNAMIC)(F16...ept)
Eingefügt1 … 1R von 1.2.276.0.76.10.2049 CDA author Person (vomgt) (DYNAMIC)
Treetree.pnghl7:author
1 … 1R(F16...ept)
wo [hl7:templateId/@root='1.2.276.0.76.10.2049']
 
Target.png
vomgt-data​element-3Kyellow.png Arztdaten Kyellow.png KV-Mustersammlung
vomgt-data​element-33Kyellow.png Betriebsstättennummer Kyellow.png KV-Mustersammlung
vomgt-data​element-34Kyellow.png Arzt-Nr Kyellow.png KV-Mustersammlung
Treeblank.pngTreetree.png@typeCode
cs0 … 1FAUT
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
 Beispiel<author typeCode="AUT" contextControlCode="OP">
  <templateId root="1.2.276.0.76.10.2049"/>  <time value="201306101654"/>  <assignedAuthor classCode="ASSIGNED">
    <!-- ... -->
  </assignedAuthor>
</author>
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1M(F16...ept)
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2049
Treeblank.pngTreetree.pnghl7:functionCode
CE0 … 1(F16...ept)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10267 ParticipationFunction (DYNAMIC)
Treeblank.pngTreetree.pnghl7:time
TS.​DATE.​MIN1 … 1(F16...ept)
 
Target.png
vomgt-data​element-755Kyellow.png Krankenhausaufnahme Kyellow.png KV-Mustersammlung
Treeblank.pngTreetree.pnghl7:assignedAuthor
1 … 1(F16...ept)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1Die 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.(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.4.16
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1RDie 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!
(F16...ept)
 
Target.png
vomgt-data​element-679Kyellow.png ASV-Teamnummer Kyellow.png KV-Mustersammlung
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.4.200
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1Fachgebiet/Spezialität des Gesundheitsdienstleister, z. B. Ärztin/Arzt für Allgemeinmedizin, Approbierte Ärztin/Approbierter Arzt, Fachärztin/Facharzt für Anästhesiologie und Intensivmedizin(F16...ept)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.101 S_BAR2_ARZTNRFACHGRUPPE (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(F16...ept)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(F16...ept)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(F16...ept)
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
1 … 1M(F16...ept)
 
Target.png
vomgt-data​element-756Kyellow.png Krankenhaus Kyellow.png 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1RDie 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!
(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid0 … 1F1.2.276.0.76.4.17
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(F16...ept)
Eingefügt0 … 1R von 1.2.276.0.76.10.2031 CDA author software (pmp) (DYNAMIC)
Treetree.pnghl7:author
0 … 1Rhhsoftpmp
wo [hl7:templateId/@root='1.2.276.0.76.10.2031']
Treeblank.pngTreetree.png@typeCode
cs0 … 1FAUT
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1Mhhsoftpmp
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2031
Treeblank.pngTreetree.pnghl7:time
TS.​DATE.​MIN1 … 1Mhhsoftpmp
Treeblank.pngTreetree.pnghl7:assignedAuthor
1 … 1Mhhsoftpmp
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1Rhhsoftpmp
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Authoring​Device
1 … 1Rhhsoftpmp
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FDEV
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:manufacturer​Model​Name
SC0 … 1hhsoftpmp
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:softwareName
SC1 … 1RSoftware Name und Version, die bei der Erstellung des Dokuments verwendet wurdehhsoftpmp
Eingefügt1 … 1R von 1.2.276.0.76.10.2004 CDA custodian (DYNAMIC)
Treetree.pnghl7:custodian
1 … 1R(F16...ept)
Treeblank.pngTreetree.png@typeCode
0 … 1FCST
 Beispiel<custodian typeCode="CST">
  <assignedCustodian classCode="ASSIGNED">
    <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">
      <!-- ... -->
    </representedCustodianOrganization>
  </assignedCustodian>
</custodian>
Treeblank.pngTreetree.pnghl7:assignedCustodian
1 … 1M(F16...ept)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FASSIGNED
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Custodian​Organization
1 … 1M(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1M(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … 1(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(F16...ept)
Eingefügt0 … 1 von 1.2.276.0.76.10.2020 CDA legalAuthenticator (DYNAMIC)
Treetree.pnghl7:legalAuthenticator
0 … 1(F16...ept)
 
Target.png
vomgt-data​element-849Kyellow.png Legal Entity Kyellow.png KV-Mustersammlung
Treeblank.pngTreetree.png@typeCode
0 … 1FLA
Treeblank.pngTreetree.png@context​Control​Code
0 … 1FOP
Treeblank.pngTreetree.pnghl7:time
TS1 … 1R(F16...ept)
Treeblank.pngTreetree.pnghl7:signatureCode
CS1 … 1R(F16...ept)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC)
Treeblank.pngTreetree.pnghl7:assignedEntity
1 … 1R(F16...ept)
Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *R(F16...ept)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1R(F16...ept)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *R(F16...ept)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(F16...ept)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(F16...ept)
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
0 … 1(F16...ept)
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
 
Target.png
vomgt-data​element-770Kyellow.png Hospital Information Kyellow.png KV-Mustersammlung
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(F16...ept)
Treetree.pnghl7:component
1 … 1R(F16...ept)
Treeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreetree.png@context​Conduction​Ind
bl1 … 1R
Treeblank.pngTreetree.pnghl7:structuredBody
1 … 1R(F16...ept)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FDOCBODY
Treeblank.pngTreeblank.pngTreetree.png@moodCode
cs0 … 1FEVN
Treeblank.pngTreeblank.pngTreetree.pnghl7:component
1 … 1MBeinhaltet 1.2.276.0.76.10.3103 Insurance Section (DYNAMIC)(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@context​Conduction​Ind
bl1 … 1R
Treeblank.pngTreeblank.pngTreetree.pnghl7:component
1 … 1MBeinhaltet 1.2.276.0.76.10.3134 Rezept Section (16) (DYNAMIC)(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@context​Conduction​Ind
bl1 … 1R
Treeblank.pngTreeblank.pngTreetree.pnghl7:component
0 … 1RBeinhaltet 1.2.276.0.76.10.3042 Wichtige Angaben (DYNAMIC)(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@context​Conduction​Ind
bl1 … 1R
Treeblank.pngTreeblank.pngTreetree.pnghl7:component
0 … 1RBeinhaltet 1.2.276.0.76.10.3135 Accident Section (16) (DYNAMIC)(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@context​Conduction​Ind
bl1 … 1R
Treeblank.pngTreeblank.pngTreetree.pnghl7:component
0 … 1RBeinhaltet 1.2.276.0.76.10.3136 Gebührenpflicht Section (16) (DYNAMIC)(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@context​Conduction​Ind
bl1 … 1R


eAbgabe

Dieses Dokumententemplate dokumentiert, welche Medikamente an den Patienten abgegeben worden sind.

Id1.2.276.0.76.10.1031Gültigkeit2019‑03‑18 15:39:10
StatusKyellow.png EntwurfVersions-Label
NameF16eAbgabeBezeichnung16: eAbgabe
BeschreibungKBV Muster 16: eAbgabe (Arzneiverordnungsblatt)
KontextPfadname //
KlassifikationCDA Document Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 9 Templates
Benutzt als NameVersion
1.2.276.0.76.10.2048InklusionKyellow.png CDA recordTarget (vomgt)DYNAMIC
1.2.276.0.76.10.2051InklusionKyellow.png CDA recordTarget Praxis (vomgt)DYNAMIC
1.2.276.0.76.10.2049InklusionKyellow.png CDA author Person (vomgt)DYNAMIC
1.2.276.0.76.10.2031InklusionKyellow.png CDA author software (pmp)DYNAMIC
1.2.276.0.76.10.2004InklusionKgreen.png CDA custodianDYNAMIC
1.2.276.0.76.10.2020InklusionKyellow.png CDA legalAuthenticatorDYNAMIC
1.2.276.0.76.3.1.135.8.10.116InklusionKyellow.png CDA relatedDocument eRezeptDYNAMIC
1.2.276.0.76.10.3103ContainmentKyellow.png Insurance SectionDYNAMIC
1.2.276.0.76.10.3137ContainmentKyellow.png Abgabe Section (16)DYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.2 CDA ClinicalDocument (with StructuredBody) (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:ClinicalDocument
(F16...abe)
Treetree.png@classCode
cs0 … 1FDOCCLIN
Treetree.png@moodCode
cs0 … 1FEVN
Treetree.pnghl7:realmCode
CS0 … 1R(F16...abe)
Treetree.pnghl7:typeId
II1 … 1R(F16...abe)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.1.3
Treeblank.pngTreetree.png@extension
st1 … 1FPOCD_HD000040
Treetree.pnghl7:templateId
II1 … 1M(F16...abe)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.1025
Treetree.pnghl7:id
II1 … 1M(F16...abe)
Treetree.pnghl7:code
CE (erforderlich)1 … 1M(F16...abe)
Treeblank.pngTreetree.png@codeSystemName
st0 … 1FLOINC
Treeblank.pngTreetree.png@codeSystem
oid0 … 1F2.16.840.1.113883.6.1
Treeblank.pngTreetree.png@code
cs0 … 1F60593-1
 Beispiel<code code="60593-1" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Medication dispensed.extended Document"/>
Treetree.pnghl7:title
ST1 … 1R(F16...abe)
 CONF
Elementinhalt muss "Abgabe" sein
Treetree.pnghl7:effectiveTime
TS1 … 1RZeitpunkt, zu dem das Dokument elektronisch erzeugt wurde.(F16...abe)
Treetree.pnghl7:confidentialityCode
CE1 … 1R(F16...abe)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.16926 HL7 BasicConfidentialityKind (DYNAMIC)
Treetree.pnghl7:setId
II0 … 1R(F16...abe)
Treetree.pnghl7:versionNumber
INT0 … 1R(F16...abe)
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:recordTarget eingefügt vom Template 1.2.276.0.76.10.2048 CDA recordTarget (vomgt) (DYNAMIC)
  • hl7:recordTarget eingefügt vom Template 1.2.276.0.76.10.2051 CDA recordTarget Praxis (vomgt) (DYNAMIC)
Eingefügt0 … 1R von 1.2.276.0.76.10.2048 CDA recordTarget (vomgt) (DYNAMIC)
Treeblank.pngTreetree.pnghl7:recordTarget
0 … 1R(F16...abe)
 
Target.png
vomgt-data​element-4Kyellow.png Patientendaten Kyellow.png KV-Mustersammlung
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FRCT
Treeblank.pngTreeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
 Beispiel<recordTarget typeCode="RCT" contextControlCode="OP">
  <templateId root="1.2.276.0.76.10.2048"/>  <patientRole classCode="PAT">
    <!-- ... -->
  </patientRole>
</recordTarget>
Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
1 … 1M(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2048
Treeblank.pngTreeblank.pngTreetree.pnghl7:patientRole
1 … 1(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPAT
 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>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
0 … *R(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1MAdresse des Patienten(F16...abe)
 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>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:patient
0 … 1(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
 Beispiel<patient classCode="PSN" determinerCode="INSTANCE">
  <name>
    <!-- ... -->
  </name>
  <birthTime value="19541223"/></patient>
Eingefügt1 … 1M von 1.2.276.0.76.10.90030 Personenname (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1MDie 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.
(F16...abe)
 
Target.png
vomgt-data​element-26Kyellow.png Name Kyellow.png KV-Mustersammlung
vomgt-data​element-773Kyellow.png Full Name Kyellow.png 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>
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Titel(F16...abe)
wo [@qualifier='AC']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FAC
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:given
ENXP0 … *Vorname(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Namenszusatz(F16...abe)
wo [@qualifier='NB']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FNB
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Vorsatzwort(F16...abe)
wo [@qualifier='VV']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FVV
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:family
ENXP0 … *Nachname(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:suffix
ENXP0 … *Suffix(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CENPHier 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)

(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.​DATE.​MIN1 … 1MGeburtsdatum des Patienten(F16...abe)
 Beispiel<birthTime value="19491224"/>
Eingefügt0 … 1R von 1.2.276.0.76.10.2051 CDA recordTarget Praxis (vomgt) (DYNAMIC)
Treeblank.pngTreetree.pnghl7:recordTarget
0 … 1R(F16...abe)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FRCT
Treeblank.pngTreeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
 Beispiel<recordTarget typeCode="RCT" contextControlCode="OP">
  <templateId root="1.2.276.0.76.10.2048"/>  <patientRole classCode="PAT">
    <!-- ... -->
  </patientRole>
</recordTarget>
Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
1 … 1M(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2051
Treeblank.pngTreeblank.pngTreetree.pnghl7:patientRole
1 … 1(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPAT
 Beispiel<patientRole classCode="PAT">
  <!-- lokale Patientennummer -->
  <id extension="186245" root="1.2.276.0.76.3.1.139.3.871"/>  <patient classCode="ORG" determinerCode="INSTANCE">
    <!-- ... -->
  </patient>
</patientRole>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
0 … *R(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1MAdresse der Praxis(F16...abe)
 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>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:providerOrganization
1 … 1MBeinhaltet 2.16.840.1.113883.10.12.151 CDA Organization (DYNAMIC)(F16...abe)
Eingefügt1 … 1R von 1.2.276.0.76.10.2049 CDA author Person (vomgt) (DYNAMIC)
Treetree.pnghl7:author
1 … 1R(F16...abe)
wo [hl7:templateId/@root='1.2.276.0.76.10.2049']
 
Target.png
vomgt-data​element-3Kyellow.png Arztdaten Kyellow.png KV-Mustersammlung
vomgt-data​element-33Kyellow.png Betriebsstättennummer Kyellow.png KV-Mustersammlung
vomgt-data​element-34Kyellow.png Arzt-Nr Kyellow.png KV-Mustersammlung
Treeblank.pngTreetree.png@typeCode
cs0 … 1FAUT
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
 Beispiel<author typeCode="AUT" contextControlCode="OP">
  <templateId root="1.2.276.0.76.10.2049"/>  <time value="201306101654"/>  <assignedAuthor classCode="ASSIGNED">
    <!-- ... -->
  </assignedAuthor>
</author>
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1M(F16...abe)
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2049
Treeblank.pngTreetree.pnghl7:functionCode
CE0 … 1(F16...abe)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10267 ParticipationFunction (DYNAMIC)
Treeblank.pngTreetree.pnghl7:time
TS.​DATE.​MIN1 … 1(F16...abe)
 
Target.png
vomgt-data​element-755Kyellow.png Krankenhausaufnahme Kyellow.png KV-Mustersammlung
Treeblank.pngTreetree.pnghl7:assignedAuthor
1 … 1(F16...abe)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1Die 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.(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.4.16
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1RDie 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!
(F16...abe)
 
Target.png
vomgt-data​element-679Kyellow.png ASV-Teamnummer Kyellow.png KV-Mustersammlung
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.4.200
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1Fachgebiet/Spezialität des Gesundheitsdienstleister, z. B. Ärztin/Arzt für Allgemeinmedizin, Approbierte Ärztin/Approbierter Arzt, Fachärztin/Facharzt für Anästhesiologie und Intensivmedizin(F16...abe)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.101 S_BAR2_ARZTNRFACHGRUPPE (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(F16...abe)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(F16...abe)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(F16...abe)
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
1 … 1M(F16...abe)
 
Target.png
vomgt-data​element-756Kyellow.png Krankenhaus Kyellow.png 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1RDie 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!
(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid0 … 1F1.2.276.0.76.4.17
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(F16...abe)
Eingefügt0 … 1R von 1.2.276.0.76.10.2031 CDA author software (pmp) (DYNAMIC)
Treetree.pnghl7:author
0 … 1Rhhsoftpmp
wo [hl7:templateId/@root='1.2.276.0.76.10.2031']
Treeblank.pngTreetree.png@typeCode
cs0 … 1FAUT
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1Mhhsoftpmp
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2031
Treeblank.pngTreetree.pnghl7:time
TS.​DATE.​MIN1 … 1Mhhsoftpmp
Treeblank.pngTreetree.pnghl7:assignedAuthor
1 … 1Mhhsoftpmp
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1Rhhsoftpmp
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Authoring​Device
1 … 1Rhhsoftpmp
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FDEV
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:manufacturer​Model​Name
SC0 … 1hhsoftpmp
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:softwareName
SC1 … 1RSoftware Name und Version, die bei der Erstellung des Dokuments verwendet wurdehhsoftpmp
Eingefügt1 … 1R von 1.2.276.0.76.10.2004 CDA custodian (DYNAMIC)
Treetree.pnghl7:custodian
1 … 1R(F16...abe)
Treeblank.pngTreetree.png@typeCode
0 … 1FCST
 Beispiel<custodian typeCode="CST">
  <assignedCustodian classCode="ASSIGNED">
    <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">
      <!-- ... -->
    </representedCustodianOrganization>
  </assignedCustodian>
</custodian>
Treeblank.pngTreetree.pnghl7:assignedCustodian
1 … 1M(F16...abe)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FASSIGNED
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Custodian​Organization
1 … 1M(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1M(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … 1(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(F16...abe)
Eingefügt0 … 1 von 1.2.276.0.76.10.2020 CDA legalAuthenticator (DYNAMIC)
Treetree.pnghl7:legalAuthenticator
0 … 1(F16...abe)
 
Target.png
vomgt-data​element-849Kyellow.png Legal Entity Kyellow.png KV-Mustersammlung
Treeblank.pngTreetree.png@typeCode
0 … 1FLA
Treeblank.pngTreetree.png@context​Control​Code
0 … 1FOP
Treeblank.pngTreetree.pnghl7:time
TS1 … 1R(F16...abe)
Treeblank.pngTreetree.pnghl7:signatureCode
CS1 … 1R(F16...abe)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC)
Treeblank.pngTreetree.pnghl7:assignedEntity
1 … 1R(F16...abe)
Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *R(F16...abe)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1R(F16...abe)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *R(F16...abe)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(F16...abe)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(F16...abe)
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
0 … 1(F16...abe)
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
 
Target.png
vomgt-data​element-770Kyellow.png Hospital Information Kyellow.png KV-Mustersammlung
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(F16...abe)
Eingefügt0 … 1R von 1.2.276.0.76.3.1.135.8.10.116 CDA relatedDocument eRezept (DYNAMIC)
Treetree.pnghl7:relatedDocument
0 … 1R(F16...abe)
Treeblank.pngTreetree.png@typeCode
cs1 … 1R
 CONF
Der Wert von @typeCode muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.11610 x_ActRelationshipDocument (DYNAMIC)
Treeblank.pngTreetree.pnghl7:parentDocument
1 … 1R(F16...abe)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FDOCCLIN
Treeblank.pngTreeblank.pngTreetree.png@moodCode
cs0 … 1FEVN
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1MIdentifikationsnummer des eRezepts(F16...abe)
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CD0 … 1(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
CONF0 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:setId
II0 … 1(F16...abe)
Treeblank.pngTreeblank.pngTreetree.pnghl7:versionNumber
INT0 … 1(F16...abe)
Treetree.pnghl7:component
1 … 1R(F16...abe)
Treeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreetree.png@context​Conduction​Ind
bl1 … 1R
Treeblank.pngTreetree.pnghl7:structuredBody
1 … 1R(F16...abe)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FDOCBODY
Treeblank.pngTreeblank.pngTreetree.png@moodCode
cs0 … 1FEVN
Treeblank.pngTreeblank.pngTreetree.pnghl7:component
1 … 1MBeinhaltet 1.2.276.0.76.10.3103 Insurance Section (DYNAMIC)(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@context​Conduction​Ind
bl1 … 1R
Treeblank.pngTreeblank.pngTreetree.pnghl7:component
1 … 1MBeinhaltet 1.2.276.0.76.10.3137 Abgabe Section (16) (DYNAMIC)(F16...abe)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@context​Conduction​Ind
bl1 … 1R


eAbrechnung

Dieses Dokumententemplate dokumentiert die abrechnungsrelevanten Daten.

Id1.2.276.0.76.10.1032Gültigkeit2019‑03‑18 17:11:07
StatusKyellow.png EntwurfVersions-Label
NameF16eAbrechnungBezeichnung16: eAbrechnung
BeschreibungKBV Muster 16: eAbgabe (Arzneiverordnungsblatt)
KontextPfadname //
KlassifikationCDA Document Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 11 Templates
Benutzt als NameVersion
1.2.276.0.76.10.2048InklusionKyellow.png CDA recordTarget (vomgt)DYNAMIC
1.2.276.0.76.10.2051InklusionKyellow.png CDA recordTarget Praxis (vomgt)DYNAMIC
1.2.276.0.76.10.2049InklusionKyellow.png CDA author Person (vomgt)DYNAMIC
1.2.276.0.76.10.2031InklusionKyellow.png CDA author software (pmp)DYNAMIC
1.2.276.0.76.10.2004InklusionKgreen.png CDA custodianDYNAMIC
1.2.276.0.76.10.2020InklusionKyellow.png CDA legalAuthenticatorDYNAMIC
1.2.276.0.76.3.1.135.8.10.116InklusionKyellow.png CDA relatedDocument eRezeptDYNAMIC
1.2.276.0.76.3.1.135.8.10.117InklusionKyellow.png CDA relatedDocument eAbgabeDYNAMIC
1.2.276.0.76.10.3103ContainmentKyellow.png Insurance SectionDYNAMIC
1.2.276.0.76.10.3137ContainmentKyellow.png Abgabe Section (16)DYNAMIC
1.2.276.0.76.10.3138ContainmentKyellow.png Zahlung Section (16)DYNAMIC
ItemDTKardKonfBeschreibungLabel
hl7:ClinicalDocument
(F16...ung)
Treetree.png@classCode
cs0 … 1FDOCCLIN
Treetree.png@moodCode
cs0 … 1FEVN
Treetree.pnghl7:realmCode
CS0 … 1R(F16...ung)
Treetree.pnghl7:typeId
II1 … 1R(F16...ung)
Treeblank.pngTreetree.png@root
uid1 … 1F2.16.840.1.113883.1.3
Treeblank.pngTreetree.png@extension
st1 … 1FPOCD_HD000040
Treetree.pnghl7:templateId
II1 … 1M(F16...ung)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.1032
Treetree.pnghl7:id
II1 … 1M(F16...ung)
Treetree.pnghl7:code
CE (erforderlich)1 … 1M(F16...ung)
Treeblank.pngTreetree.png@codeSystemName
st0 … 1FLOINC
Treeblank.pngTreetree.png@codeSystem
oid0 … 1F2.16.840.1.113883.6.1
Treeblank.pngTreetree.png@code
cs0 … 1FxABRECHNUNG
 Beispiel<code code="xABRECHNUNG" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Medication charged Document"/>
Treetree.pnghl7:title
ST1 … 1R(F16...ung)
 CONF
Elementinhalt muss "Abrechnung" sein
Treetree.pnghl7:effectiveTime
TS1 … 1RZeitpunkt, zu dem das Dokument elektronisch erzeugt wurde.(F16...ung)
Treetree.pnghl7:confidentialityCode
CE1 … 1R(F16...ung)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.16926 HL7 BasicConfidentialityKind (DYNAMIC)
Treetree.pnghl7:setId
II0 … 1R(F16...ung)
Treetree.pnghl7:versionNumber
INT0 … 1R(F16...ung)
Auswahl1 … 1Elemente in der Auswahl:
  • hl7:recordTarget eingefügt vom Template 1.2.276.0.76.10.2048 CDA recordTarget (vomgt) (DYNAMIC)
  • hl7:recordTarget eingefügt vom Template 1.2.276.0.76.10.2051 CDA recordTarget Praxis (vomgt) (DYNAMIC)
Eingefügt0 … 1R von 1.2.276.0.76.10.2048 CDA recordTarget (vomgt) (DYNAMIC)
Treeblank.pngTreetree.pnghl7:recordTarget
0 … 1R(F16...ung)
 
Target.png
vomgt-data​element-4Kyellow.png Patientendaten Kyellow.png KV-Mustersammlung
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FRCT
Treeblank.pngTreeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
 Beispiel<recordTarget typeCode="RCT" contextControlCode="OP">
  <templateId root="1.2.276.0.76.10.2048"/>  <patientRole classCode="PAT">
    <!-- ... -->
  </patientRole>
</recordTarget>
Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
1 … 1M(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2048
Treeblank.pngTreeblank.pngTreetree.pnghl7:patientRole
1 … 1(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPAT
 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>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
0 … *R(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1MAdresse des Patienten(F16...ung)
 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>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:patient
0 … 1(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
 Beispiel<patient classCode="PSN" determinerCode="INSTANCE">
  <name>
    <!-- ... -->
  </name>
  <birthTime value="19541223"/></patient>
Eingefügt1 … 1M von 1.2.276.0.76.10.90030 Personenname (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1MDie 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.
(F16...ung)
 
Target.png
vomgt-data​element-26Kyellow.png Name Kyellow.png KV-Mustersammlung
vomgt-data​element-773Kyellow.png Full Name Kyellow.png 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>
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Titel(F16...ung)
wo [@qualifier='AC']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FAC
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:given
ENXP0 … *Vorname(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Namenszusatz(F16...ung)
wo [@qualifier='NB']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FNB
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Vorsatzwort(F16...ung)
wo [@qualifier='VV']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FVV
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:family
ENXP0 … *Nachname(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:suffix
ENXP0 … *Suffix(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CENPHier 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)

(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.​DATE.​MIN1 … 1MGeburtsdatum des Patienten(F16...ung)
 Beispiel<birthTime value="19491224"/>
Eingefügt0 … 1R von 1.2.276.0.76.10.2051 CDA recordTarget Praxis (vomgt) (DYNAMIC)
Treeblank.pngTreetree.pnghl7:recordTarget
0 … 1R(F16...ung)
Treeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FRCT
Treeblank.pngTreeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
 Beispiel<recordTarget typeCode="RCT" contextControlCode="OP">
  <templateId root="1.2.276.0.76.10.2048"/>  <patientRole classCode="PAT">
    <!-- ... -->
  </patientRole>
</recordTarget>
Treeblank.pngTreeblank.pngTreetree.pnghl7:templateId
1 … 1M(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2051
Treeblank.pngTreeblank.pngTreetree.pnghl7:patientRole
1 … 1(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPAT
 Beispiel<patientRole classCode="PAT">
  <!-- lokale Patientennummer -->
  <id extension="186245" root="1.2.276.0.76.3.1.139.3.871"/>  <patient classCode="ORG" determinerCode="INSTANCE">
    <!-- ... -->
  </patient>
</patientRole>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
0 … *R(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD1 … 1MAdresse der Praxis(F16...ung)
 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>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:providerOrganization
1 … 1MBeinhaltet 2.16.840.1.113883.10.12.151 CDA Organization (DYNAMIC)(F16...ung)
Eingefügt1 … 1R von 1.2.276.0.76.10.2049 CDA author Person (vomgt) (DYNAMIC)
Treetree.pnghl7:author
1 … 1R(F16...ung)
wo [hl7:templateId/@root='1.2.276.0.76.10.2049']
 
Target.png
vomgt-data​element-3Kyellow.png Arztdaten Kyellow.png KV-Mustersammlung
vomgt-data​element-33Kyellow.png Betriebsstättennummer Kyellow.png KV-Mustersammlung
vomgt-data​element-34Kyellow.png Arzt-Nr Kyellow.png KV-Mustersammlung
Treeblank.pngTreetree.png@typeCode
cs0 … 1FAUT
Treeblank.pngTreetree.png@context​Control​Code
cs0 … 1FOP
 Beispiel<author typeCode="AUT" contextControlCode="OP">
  <templateId root="1.2.276.0.76.10.2049"/>  <time value="201306101654"/>  <assignedAuthor classCode="ASSIGNED">
    <!-- ... -->
  </assignedAuthor>
</author>
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1M(F16...ung)
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2049
Treeblank.pngTreetree.pnghl7:functionCode
CE0 … 1(F16...ung)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10267 ParticipationFunction (DYNAMIC)
Treeblank.pngTreetree.pnghl7:time
TS.​DATE.​MIN1 … 1(F16...ung)
 
Target.png
vomgt-data​element-755Kyellow.png Krankenhausaufnahme Kyellow.png KV-Mustersammlung
Treeblank.pngTreetree.pnghl7:assignedAuthor
1 … 1(F16...ung)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1Die 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.(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.4.16
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1RDie 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!
(F16...ung)
 
Target.png
vomgt-data​element-679Kyellow.png ASV-Teamnummer Kyellow.png KV-Mustersammlung
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.4.200
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CE0 … 1Fachgebiet/Spezialität des Gesundheitsdienstleister, z. B. Ärztin/Arzt für Allgemeinmedizin, Approbierte Ärztin/Approbierter Arzt, Fachärztin/Facharzt für Anästhesiologie und Intensivmedizin(F16...ung)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.101 S_BAR2_ARZTNRFACHGRUPPE (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(F16...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(F16...ung)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(F16...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
1 … 1M(F16...ung)
 
Target.png
vomgt-data​element-756Kyellow.png Krankenhaus Kyellow.png 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1RDie 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!
(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid0 … 1F1.2.276.0.76.4.17
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(F16...ung)
Eingefügt0 … 1R von 1.2.276.0.76.10.2031 CDA author software (pmp) (DYNAMIC)
Treetree.pnghl7:author
0 … 1Rhhsoftpmp
wo [hl7:templateId/@root='1.2.276.0.76.10.2031']
Treeblank.pngTreetree.png@typeCode
cs0 … 1FAUT
Treeblank.pngTreetree.pnghl7:templateId
II1 … 1Mhhsoftpmp
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2031
Treeblank.pngTreetree.pnghl7:time
TS.​DATE.​MIN1 … 1Mhhsoftpmp
Treeblank.pngTreetree.pnghl7:assignedAuthor
1 … 1Mhhsoftpmp
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1Rhhsoftpmp
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Authoring​Device
1 … 1Rhhsoftpmp
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FDEV
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:manufacturer​Model​Name
SC0 … 1hhsoftpmp
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:softwareName
SC1 … 1RSoftware Name und Version, die bei der Erstellung des Dokuments verwendet wurdehhsoftpmp
Eingefügt1 … 1R von 1.2.276.0.76.10.2004 CDA custodian (DYNAMIC)
Treetree.pnghl7:custodian
1 … 1R(F16...ung)
Treeblank.pngTreetree.png@typeCode
0 … 1FCST
 Beispiel<custodian typeCode="CST">
  <assignedCustodian classCode="ASSIGNED">
    <representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">
      <!-- ... -->
    </representedCustodianOrganization>
  </assignedCustodian>
</custodian>
Treeblank.pngTreetree.pnghl7:assignedCustodian
1 … 1M(F16...ung)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FASSIGNED
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Custodian​Organization
1 … 1M(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1M(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … 1(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(F16...ung)
Eingefügt0 … 1R von 1.2.276.0.76.10.2020 CDA legalAuthenticator (DYNAMIC)
Treetree.pnghl7:legalAuthenticator
0 … 1R(F16...ung)
 
Target.png
vomgt-data​element-849Kyellow.png Legal Entity Kyellow.png KV-Mustersammlung
Treeblank.pngTreetree.png@typeCode
0 … 1FLA
Treeblank.pngTreetree.png@context​Control​Code
0 … 1FOP
Treeblank.pngTreetree.pnghl7:time
TS1 … 1R(F16...ung)
Treeblank.pngTreetree.pnghl7:signatureCode
CS1 … 1R(F16...ung)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10282 ParticipationSignature (DYNAMIC)
Treeblank.pngTreetree.pnghl7:assignedEntity
1 … 1R(F16...ung)
Eingefügt von 1.2.276.0.76.10.90012 CDA Assigned Entity Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … *R(F16...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1R(F16...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *R(F16...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(F16...ung)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(F16...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
0 … 1(F16...ung)
Eingefügt von 1.2.276.0.76.10.90011 CDA Organization Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FORG
 
Target.png
vomgt-data​element-770Kyellow.png Hospital Information Kyellow.png KV-Mustersammlung
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … *(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(F16...ung)
Eingefügt0 … 1R von 1.2.276.0.76.3.1.135.8.10.116 CDA relatedDocument eRezept (DYNAMIC)
Treetree.pnghl7:relatedDocument
0 … 1R(F16...ung)
Treeblank.pngTreetree.png@typeCode
cs1 … 1R
 CONF
Der Wert von @typeCode muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.11610 x_ActRelationshipDocument (DYNAMIC)
Treeblank.pngTreetree.pnghl7:parentDocument
1 … 1R(F16...ung)
Treeblank.pngTreeblank.png