eRezept

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche
[gesichtete Version][gesichtete Version]
K
K (UV Subordinate Subtance Administration => Einzeldosierungen)
 
Zeile 281: Zeile 281:
 
==Medikament Verordnung Entry==
 
==Medikament Verordnung Entry==
 
{{:1.2.276.0.76.10.4298/dynamic}}
 
{{:1.2.276.0.76.10.4298/dynamic}}
 +
== Einzeldosierungen ==
 +
{{:1.2.276.0.76.10.4023/dynamic}}
 
==Dosierung Freitext Entry==
 
==Dosierung Freitext Entry==
 
{{:1.2.276.0.76.10.4024/dynamic}}
 
{{:1.2.276.0.76.10.4024/dynamic}}
Zeile 312: Zeile 314:
  
 
==importierte Templates==
 
==importierte Templates==
=== UV Subordinate Substance Administration ===
 
{{:2.16.840.1.113883.10.21.4.6/dynamic}}
 
 
=== UV Dispense Request ===
 
=== UV Dispense Request ===
 
{{:2.16.840.1.113883.10.21.4.2/dynamic}}
 
{{:2.16.840.1.113883.10.21.4.2/dynamic}}

Aktuelle Version vom 9. Juli 2019, 10:40 Uhr


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

Arzneimittelverordnung
eRezept (Arzneimittelverordnung) auf Basis der HL7 Clinical Document Architecture Release 2 für das deutsche Gesundheitswesen
Status Typ Version Datum PDF Wiki ART-DECOR
Abstimmung
Si-vote.svgAbstimmung STU 0.80 07.05.2019 Download.png Link.png Link.png
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 ist im Rahmen des Interoperabilitätsforums und der Technischen Komitees von HL7 Deutschland e. V. sowie der entsprechenden Projektgruppen zusammengestellt 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


Disclaimer

Dieser Implementierungsleitfaden darf nicht als durch die GKV-SV/KBV bestätigter Leitfaden aufgefasst werden. Die Nutzung der digitalen Umsetzung der Muster 10 und Muster 10A im kollektivertraglichen ambulanten Bereich ist deshalb derzeit nicht möglich. Die im vorliegenden Leitfaden beschriebene Umsetzung dieser Mustervorlagen ist zudem nicht interoperabel zu der von KBV und GKV-SV vorgegebenen Umsetzung bestehender digitaler Muster. Die von GKV-SV und KBV vorgegebene Umsetzung basiert auf dem ISO-Standard 19005 (PDF/A). Dieser Implementierungsleitfaden ist daher nicht geeignet, ihn als digitales Muster gemäß BMV-Ä umzusetzen.

Das primäre Ziel dieses Leitfadens ist zu demonstrieren, dass eine standardbasierte Umsetzung möglich ist. Rückmeldungen aus der Industrie legen nahe, dass diese Form einer elektronischen Fassung gegenüber einer PDF-basierten favorisiert wird. Deshalb wird der Fokus auf eine Spezifikation der fachlichen Inhalte und nicht auf begleitende Fragestellungen wie Transport oder Signatur (QES) gelegt. Für letztere werden Zusatzspezifkationen benötigt, die nicht Gegenstand dieses Leitfadens sind.

Copyright-Hinweis, Nutzungshinweise

Nachnutzungs- bzw. Veröffentlichungsansprüche

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

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

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


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

Einleitung

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

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

Muster 16: Arzneiverordnungsblatt (eRezept)

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

Muster 16

Dieses Formular wird jedoch zur Realisierung mehreren 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 Leitfaden 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 in den Abschnitt "Aufbau" und "Technische Spezifikationen" erläutert,

  • Festlegung definierter semantische Bezugssysteme (insbesondere Klassifikationen, Terminologien), im Abschnitt "Terminologien" erläutert,
  • Aufzeigen der Möglichkeiten des Mapping 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 Ihren 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.
  • Eine ganze Reihe ausgewählter Templates aus dem Projekt Medikationsplan PLUS bzw. dem Medikationsmanagement wurden für diese Spezifikation entweder gänzlich übernommen oder adaptiert. Ihre Passgenauigkeit muss noch diskutiert werden, da die Verordnung ein etwas anders gelagerter Anwendungsfall ist.


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

Aufbau

Aufbau dieses Implementierungsleitfadens

Dieser Leitfaden eRezept beinhaltet die folgenden Spezifikationen:

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

Verwendete Standards und Spezifikationen

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

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

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

  • HL7 Deutschland: Elektronischer Arztbrief 2015[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 gestellte 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®[8] 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[9].

Pmp-templates.png
Pmp-templates.png

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

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

Pmp-simplifier.png
Pmp-simplifier.png

[Abbildung 2] 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 3] und dort mit den Funktionalen Definitionen verbunden.

Pmp-fhirundartdecor.png
Pmp-fhirundartdecor.png

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

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

Akteure

Folgende Akteure kommen in Kontakt mit einer Verordnung/ einem Rezept

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

Transportwege

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

Weitere Wege?


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

Use Case: eVerordnung

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

  • durchführen (verordnen)
  • ausgeben
  • abrechnen

ERezept Use Cases.jpg

Medikation verordnen

Für die Verordnung einer Medikation wird es spezialisiert als:

  • eRezept erstellen und ausgeben
  • Medikament ausgeben
  • Medikament abrechnen

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.

Darüber hinaus sind folgende Transaktionen zu diskutieren:

  • eRezept stornieren
  • ...


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 Localisation wird durch HL7 Deutschland übernommen.

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

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

Vorgehensweise

Hierarchien

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

Prozesshierarchie

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

  • eVerordnung: Arzt - Patient
  • eAbgabe: Patient - Leistungserbringer - Patient
  • eAbrechnung: Leistungserbringer - Kostenträger

Prozesshierarchie

Zwischen diesen Akteuren werden die entsprechenden Dokumente ausgetauscht.

Akteurhierarchie

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

Akteurshierachie

Dokumentenhierarchie

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

Dokumentenhierarchie

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

Zusammenhang zwischen den Dokumenten

Damit ergeben sich in einer Template-Darstellung folgende Dokumentbeziehungen:

Dokumentbeziehungen

Domänenmodell

Die im Falle von Verordnungen relevanten Informationen lassen sich in ein gemeinsames Informationsmodell einordnen:

Domänenmodell

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

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

Cdam16 daten.jpg

Das eigentliche Informationsmodell lässt sich daraus ableiten. Auf der linken Seite stehen die drei Dokumente, die spezifiiert werden müssen. Inhaltlich beinhalten diese die Medikation mit den Details zum Medikament.

Hauptdaten-Dataset

Dosier-Beispiele

Im Folgenden sind die Dosierschemas aufgelistet und mit Beispielen (CDA-Instanzenfragmente) verdeutlicht. Ein Dosierschemas 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öglichen 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.


Id1.2.276.0.76.11.463Gültigkeit2018‑09‑11 21:05:52
StatusKyellow.png EntwurfVersions-Label
NameTimingEventAnzeigenameTimingEvent
BeschreibungOriginal TimingEvent Value Set von HL7 mit deutschen Designationen
2 Quell-Codesysteme
2.16.840.1.113883.5.139 - TimingEvent - http://terminology.hl7.org/CodeSystem/v3-TimingEvent
2.16.840.1.113883.3.1937.99.61.48.5.1 - urn:oid:2.16.840.1.113883.3.1937.99.61.48.5.1
Level/ TypCodeAnzeigenameCodesystemDesignationsBeschreibung
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. 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

<effective_time xsi:type="PIVL_TS">
   <period value="8" unit="h"/>
   <!-- Wiederholperiode 8 Stunden -->
</effective_time>
<doseQuantity value="1" unit="{Stück}"/>

1x täglich 10 ml

<effective_time xsi:type="PIVL_TS">
   <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. September 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. September 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 (z. B. ab dem 9. Februar 2019) um 8:00 Uhr 1 Stück

<effectiveTime xsi:type="PIVL_TS">
  <phase value="201902090800"/>
  <!-- der 9. Februar 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)

<effectiveTime xsi:type="PIVL_TS">
  <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).

Id1.2.276.0.76.11.452
ref
hl7de-
Gültigkeit2017‑04‑01
StatusKyellow.png EntwurfVersions-Label
NameZeiteinheitenAnzeigenameZeiteinheiten (UCUM)
Quell-Codesystem
2.16.840.1.113883.6.8 - Unified Code for Units of Measure - http://unitsofmeasure.org
Level/ TypCodeAnzeigenameCodesystem
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. 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>

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 dem 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 Kostenträger .KassenNr        
19 Ausstellungsdatum Ausstellungsdatum eVerschreibung .Ausgabedatum ClinicalDocument .effectiveTime      
12 Fälschungssicheres Ausfüllen des Vordrucks - - -      
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 " 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      
13f   ASV-Teamnummer Person.id 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 " recordTarget .name.given   VSD.Versicherter .Person.Vorname  
14b   Nachname " recordTarget .name.family   VSD.Versicherter .Person.Nachname  
14f   Vorsatzwort " recordTarget .name.prefix + "VV"   VSD.Versicherter .Person .Vorsatzwort  
14g   Namenszusatz " recordTarget .name.prefix + "NB"   VSD.Versicherter .Person .Namenszusatz  
14h   Titel " recordTarget .name.prefix + "AC"      
14i   PostfachAdresse (PLZ, Postfach, Ort, Land) Person.Ort recordTarget .addr/postBox      
14j   Strassenadresse (Strasse, Hausnummer, PLZ, Ort, Land, Anschriftenzusatz) " 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ößeMenge Container .PackungsgrößeMenge        
23a7 - PackungsgrößeEinheit Container .PackungsgrößeEinheit   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        
9c Gesamtbrutto Gesamt-Brutto eAbrechnung .Gesamtbrutto GesamtbruttoObservation .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 Practive finden sich im Wiki des Interoperabilitätsforums[12], [13].

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ühren Section (16) (1.2.276.0.76.10.3136)
      1. Entry
         Gebühren (16) (1.2.276.0.76.10.4299)

[Abbildung 5] 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 6] 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
         Gesamtbrutto Observation (16) (1.2.276.0.76.10.4300)

[Abbildung 7] 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
NameF16eRezeptAnzeigename16: 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ühren 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)
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)
 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.png 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.png 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.png 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.

(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)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.png wo [not(@nullFlavor)]
Eingefügt1 … 1R von 1.2.276.0.76.10.2049 CDA author Person (vomgt) (DYNAMIC)
Treetree.pnghl7:author
1 … 1R(F16...ept)
Treeblank.png 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-34Kyellow.png Arzt-Nr Kyellow.png KV-Mustersammlung
vomgt-data​element-33Kyellow.png Betriebsstättennummer 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)
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)
 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
Treeblank.png 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 … 1(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)
Eingefügt0 … 1 von 1.2.276.0.76.10.2020 CDA legalAuthenticator (DYNAMIC)
Treetree.pnghl7:legalAuthenticator
0 … 1(F16...ept)
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
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.png wo [hl7:section [hl7:code [(@code = '48768-6' and @codeSystem = '2.16.840.1.113883.6.1')]]]
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.png wo [hl7:section [hl7:code [(@code = '57828-6' and @codeSystem = '2.16.840.1.113883.6.1')]]]
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.png wo [hl7:section [hl7:code [(@code = '69730-0' and @codeSystem = '2.16.840.1.113883.6.1')]]]
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.png wo [hl7:section]
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ühren Section (16) (DYNAMIC)(F16...ept)
Treeblank.pngTreeblank.pngTreeblank.png wo [hl7:section [hl7:code [(@code = 'GEBUEHR' and @codeSystem = '1.2.276.0.76.3.1.135.8.5.99')]]]
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
NameF16eAbgabeAnzeigename16: 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)
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)
 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.png 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.png 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.png 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.

(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)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.png wo [not(@nullFlavor)]
Eingefügt1 … 1R von 1.2.276.0.76.10.2049 CDA author Person (vomgt) (DYNAMIC)
Treetree.pnghl7:author
1 … 1R(F16...abe)
Treeblank.png 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-34Kyellow.png Arzt-Nr Kyellow.png KV-Mustersammlung
vomgt-data​element-33Kyellow.png Betriebsstättennummer 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)
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)
 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
Treeblank.png 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 … 1(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 … 1 von 1.2.276.0.76.10.2020 CDA legalAuthenticator (DYNAMIC)
Treetree.pnghl7:legalAuthenticator
0 … 1(F16...abe)
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
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.png wo [hl7:section [hl7:code [(@code = '48768-6' and @codeSystem = '2.16.840.1.113883.6.1')]]]
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.png wo [hl7:section [hl7:code [(@code = '60590-7' and @codeSystem = '2.16.840.1.113883.6.1')]]]
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
NameF16eAbrechnungAnzeigename16: 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)
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)
 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.png 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.png 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)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreeblank.png 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.

(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)
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.png wo [not(@nullFlavor)]
Eingefügt1 … 1R von 1.2.276.0.76.10.2049 CDA author Person (vomgt) (DYNAMIC)
Treetree.pnghl7:author
1 … 1R(F16...ung)
Treeblank.png 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-34Kyellow.png Arzt-Nr Kyellow.png KV-Mustersammlung
vomgt-data​element-33Kyellow.png Betriebsstättennummer 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)
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)
 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
Treeblank.png 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 … 1(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.10.2020 CDA legalAuthenticator (DYNAMIC)
Treetree.pnghl7:legalAuthenticator
0 … 1R(F16...ung)
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
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.pngTreetree.png@classCode
cs0 … 1FDOCCLIN
Treeblank.pngTreeblank.pngTreetree.png@moodCode
cs0 … 1FEVN
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1MIdentifikationsnummer des eRezepts(F16...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CD0 … 1(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
CONF0 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:setId
II0 … 1(F16...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:versionNumber
INT0 … 1(F16...ung)
Eingefügt0 … 1R von 1.2.276.0.76.3.1.135.8.10.117 CDA relatedDocument eAbgabe (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.pngTreetree.png@classCode
cs0 … 1FDOCCLIN
Treeblank.pngTreeblank.pngTreetree.png@moodCode
cs0 … 1FEVN
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1MIdentifikationsnummer der eAbgabe(F16...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CD0 … 1(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@codeSystem
CONF0 … 1F2.16.840.1.113883.6.1 (LOINC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:setId
II0 … 1(F16...ung)
Treeblank.pngTreeblank.pngTreetree.pnghl7:versionNumber
INT0 … 1(F16...ung)
Treetree.pnghl7:component
1 … 1R(F16...ung)
Treeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreetree.png@context​Conduction​Ind
bl1 … 1R
Treeblank.pngTreetree.pnghl7:structuredBody
1 … 1R(F16...ung)
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...ung)
Treeblank.pngTreeblank.pngTreeblank.png wo [hl7:section [hl7:code [(@code = '48768-6' and @codeSystem = '2.16.840.1.113883.6.1')]]]
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...ung)
Treeblank.pngTreeblank.pngTreeblank.png wo [hl7:section [hl7:code [(@code = '60590-7' and @codeSystem = '2.16.840.1.113883.6.1')]]]
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.3138 Zahlung Section (16) (DYNAMIC)(F16...ung)
Treeblank.pngTreeblank.pngTreeblank.png wo [not(@nullFlavor)] [hl7:section]
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@typeCode
cs0 … 1FCOMP
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@context​Conduction​Ind
bl1 … 1R

CDA Header Level Templates

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

CDA recordTarget (vomgt)

Id1.2.276.0.76.10.2048Gültigkeit2016‑02‑19 15:12:48
StatusKyellow.png EntwurfVersions-Label
NameCDArecordTargetvomgtAnzeigenameCDA recordTarget (vomgt)
BeschreibungDas recordTarget repräsentiert die Person, über die dokumentiert wird. recordTarget umfasst IDs und dem Namen, Geschlecht, Adressen etc.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.276.0.76.10.90030InklusionKgreen.png PersonennameDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.101 CDA recordTarget (DYNAMIC)
ref
ad1bbr-

Spezialisierung: Template 1.2.276.0.76.10.2001 CDA recordTarget (2013‑07‑10)
ref
hl7de-
ItemDTKardKonfBeschreibungLabel
hl7:recordTarget
(CDA...mgt)
Treetree.png@typeCode
cs0 … 1FRCT
Treetree.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>
Treetree.pnghl7:templateId
1 … 1M(CDA...mgt)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2048
Treetree.pnghl7:patientRole
1 … 1(CDA...mgt)
Treeblank.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.pngTreetree.pnghl7:id
0 … *R(CDA...mgt)
Treeblank.pngTreetree.pnghl7:addr
AD1 … 1MAdresse des Patienten(CDA...mgt)
 Beispiel
normale Adresse
<addr use="HP">
  <streetName>Dorfstraße</streetName>  <houseNumber>54</houseNumber>  <postalCode>51371</postalCode>  <city>Leverkusen</city>  <country>D</country></addr>
 Beispiel
Postfach
<addr use="HP">
  <postBox>654321</postBox>  <postalCode>51371</postalCode>  <city>Leverkusen</city>  <country>D</country></addr>
Treeblank.pngTreetree.pnghl7:patient
0 … 1(CDA...mgt)
Treeblank.png