eRezept

Aus Hl7wiki
Implementierungsleitfaden
Wechseln zu: Navigation, Suche
K
K
Zeile 55: Zeile 55:
 
<div class="landscape">
 
<div class="landscape">
  
−
== Einleitung ==
+
{{HL7transclude| cdam16: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) technisch abgebildet werden können.
 
−
 
 
−
Die Verordnung/ das Rezept nutzt Module (Komponenten) aus den anderen Spezifikationen im Bereich Verordnungsmanagement.
 
−
 
 
−
===Muster 16: Arzneiverordnungsblatt (eRezept) ===
 
−
[[Datei:KBV_Muster_16.jpg|600px|Muster 16]]
 
−
 
 
−
[[Kategorie:cdarfr|Einleitung]]
 
  
 
{{HL7transclude| cdaab2:Transportaspekte}}
 
{{HL7transclude| cdaab2:Transportaspekte}}
Zeile 96: Zeile 85:
 
Weitere Wege?  
 
Weitere Wege?  
  
 +
{{HL7transclude| cdam16:Use Cases}}
  
−
 
+
=Übersicht CDA Header und Body=
−
==Übersicht CDA Header und Body==
 
 
Im Folgenden wird eine Übersicht über das CDA-Dokument gegeben.
 
Im Folgenden wird eine Übersicht über das CDA-Dokument gegeben.
  

Version vom 23. November 2018, 09:49 Uhr

Under construction icon-blue.svg This article or section is in the middle of an expansion or major restructuring and is not yet ready for use. You are welcome to assist in its construction by editing it as well. If this article has not been edited in several days, please remove this template.
This article was last edited by Foemig (talk| contribs) 6 years ago. (Purge)
Diese Seite oder Abschnitt ist derzeit ein Entwurf und ist noch nicht fertiggestellt. Du bist eingeladen, bei der Fertigstellung mitzuwirken. Wenn dieser Beitrag länger als einige Tage nicht editiert wurde, entferne diese Vorlage.
This article was last edited by Foemig (talk| contribs) 6 years ago. (Purge)
Logo-hl720.jpg
eRezept auf Basis der
HL7 Clinical Document Architecture Release 2
für das deutsche Gesundheitswesen
eRezept
Implementierungsleitfaden
vorgelegt von:
.
in Arbeit
Version: 0.1
Datum: 21. November 2018
Status: Entwicklung
Verfahren: {{{Verfahren}}}
Realm: Flag de.svg Deutschland
Copyright © 2018: HL7 Deutschland


Abstimmungsdokument 
Version Datum Status Realm
0.1 01.12.2018 in Arbeit Flag de.svg Deutschland
Document PDF.svg noch kein download verfügbar
Kontributoren 
Logo bvitg.JPG bvitg Berlin
Logo-hsnr.png HS Niederrhein Krefeld
Logo telekom healthcare.png DTHS Essen
Logo medatixx.jpg medatixx Eltville
100px Medisoft Hamburg

Dokumenteninformationen

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

Impressum

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

Ansprechpartner und Autoren

  • Elisabeth Pantazoglou, HS Niederrhein
  • Frank Oemig, DTHS


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

Disclaimer

Talk.svg Disclaimer
  • Der Inhalt dieses Dokumentes ist öffentlich. Zu beachten ist, dass Teile dieses Dokuments auf der Normative Edition 2005 von HL7 Version 3 bzw. dem ISO-Standard Clinical Document Architecture (CDA) Release 2 (ISO/HL7 27932:2009 Data Exchange Standards -- HL7 Clinical Document Architecture, Release 2) beruhen, für die © HL7 International gilt.
  • Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann HL7 Deutschland keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten.

Copyright-Hinweis, Nutzungshinweise

Nachnutzungs- bzw. Veröffentlichungsansprüche

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

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

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


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

Einleitung

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

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

Muster 16: Arzneiverordnungsblatt (eRezept)

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

Muster 16

[Abbildung 1] Muster 16

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

Rationale

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

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

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

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

Zweck

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

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

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

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

erläutert.

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

Vorarbeiten

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

Standardisierung

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

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

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

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

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

andere KV-Formulare

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

Nutzer

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

  • Haus- und Facharztpraxen
  • Apotheken
  • Krankenhäuser

Zu den möglichen Akteuren gehören:

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

Forderungen und Potenziale

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

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

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

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

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

Abgrenzung

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

Offene Punkte und Besonderheiten

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

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


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

Transportaspekte

Interaktionsdiagramm

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

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

Interaktionsdiagramm

[Abbildung 2] Interaktionsdiagramm

Dokumentenaustausch

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

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

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

Rechtssichere Übertragung

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

  • Datenschutz-/-sicherheit
  • IT-Sicherheit
  • Verschlüsselung
  • Signaturen
Information icon.svg Diese Aspekte Datenschutz/-sicherheit, IT-Sicherheit, Verschlüsselung und Signaturen sind nicht Bestandteil dieser Spezifikation. Es gibt dazu aber bereits entsprechende Ausarbeitungen und Vorgaben.

Rechtssichere Übertragung

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

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

Akteure

Folgende Akteure kommen in Kontakt mit einer Verordnung/ einem Rezept

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

Transportwege

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

Weitere Wege?


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

Use Case

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

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

ERezept Use Cases.jpg

[Abbildung 3] Use Cases

eVerschreibung durchführen

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

  • eRezept erstellen und eVerschreibung übergeben

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

eVerschreibung einlösen

  • Medikament ausgeben

eVerschreibung abrechnen

  • Medikament abrechnen

Stornierung einer Verschreibung

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

Übersicht CDA Header und Body

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

1.2.276.0.76.3.1.135.8.10.100/hgraph

[Abbildung 4] CDA-Dokument-Template

CDA Document Level Templates

16: eRezept

Under construction icon-blue.svg Hier fehlen noch die relevanten Sections

Vorlage:InfoBox

1.2.276.0.76.3.1.135.8.10.100/dynamic

16: eRezept für Sprechstundenbedarf

Under construction icon-blue.svg Hier fehlen noch die relevanten Sections

Dieses Dokumententemplate dient der Übermittlung des Sprechstundenbedarfs.

16: eAbgabe/eAbrechnung

Under construction icon-blue.svg Hier fehlen noch die relevanten Sections

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

CDA Header Level Templates

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

CDA author Person (vomgt)

Id1.2.276.0.76.10.2049Gültigkeit2016‑09‑06 10:43:05
StatusKyellow.png EntwurfVersions-Label
NameHeaderAuthorPersonBezeichnungCDA author Person (vomgt)
BeschreibungDieses Template spezifiziert, wie ein Mensch/Person als Autor des Dokumentes angegeben wird.
KlassifikationCDA Header Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 6 Konzepte
IdNameDatensatz
vomgt-data​element-3Kyellow.png Arztdaten Kyellow.png KV-Mustersammlung
vomgt-data​element-33Kyellow.png Betriebsstättennummer Kyellow.png KV-Mustersammlung
vomgt-data​element-34Kyellow.png Arzt-Nr Kyellow.png KV-Mustersammlung
vomgt-data​element-679Kyellow.png ASV-Teamnummer Kyellow.png KV-Mustersammlung
vomgt-data​element-755Kyellow.png Krankenhausaufnahme Kyellow.png KV-Mustersammlung
vomgt-data​element-756Kyellow.png Krankenhaus Kyellow.png KV-Mustersammlung
Benutzt
Benutzt 2 Templates
Benutzt als NameVersion
1.2.276.0.76.10.90010InklusionKgreen.png CDA Person ElementsDYNAMIC
1.2.276.0.76.10.90032InklusionKyellow.png CDA Organization Elements (vomgt)DYNAMIC
BeziehungSpezialisierung: Template 1.2.276.0.76.10.2002 CDA author (DYNAMIC)
ref
hl7de-

Spezialisierung: Template 2.16.840.1.113883.10.12.102 CDA author (DYNAMIC)
ref
ad1bbr-

Spezialisierung: Template 1.2.276.0.76.10.2007 CDA author Person (2013‑10‑11)
ref
hl7de-
Beispiel
Beispiel
<author typeCode="AUT">
  <templateId root="1.2.276.0.76.10.2049"/>  <functionCode code="DISPHYS" displayName="discharging physican" codeSystem="2.16.840.1.113883.5.88" codeSystemName="ParticipationFunction"/>  <time value="201304071300"/>  <assignedAuthor classCode="ASSIGNED">
    <id root="20cf14fb-b65c-4c8c-a54d-b0cca834c18c"/>    <assignedPerson classCode="PSN" determinerCode="INSTANCE">
      <name>
        <prefix>Dr.med.</prefix>        <given>Karl</given>        <family>Gebhardt</family>      </name>    </assignedPerson>    <representedOrganization>
      <id root="2.16.840.1.113883.19.5"/>      <name>Beispiel Krankenhaus</name>    </representedOrganization>  </assignedAuthor></author>
ItemDTKardKonfBeschreibungLabel
hl7:author
(Hea...son)
wo [hl7:templateId/@root='1.2.276.0.76.10.2049']
 
Target.png
vomgt-data​element-3Kyellow.png Arztdaten Kyellow.png KV-Mustersammlung
vomgt-data​element-33Kyellow.png Betriebsstättennummer Kyellow.png KV-Mustersammlung
vomgt-data​element-34Kyellow.png Arzt-Nr Kyellow.png KV-Mustersammlung
Treetree.png@typeCode
cs0 … 1FAUT
Treetree.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>
Treetree.pnghl7:templateId
II1 … 1M(Hea...son)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.2049
Treetree.pnghl7:functionCode
CE0 … 1(Hea...son)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10267 ParticipationFunction (DYNAMIC)
Treetree.pnghl7:time
TS.​DATE.​MIN1 … 1(Hea...son)
 
Target.png
vomgt-data​element-755Kyellow.png Krankenhausaufnahme Kyellow.png KV-Mustersammlung
Treetree.pnghl7:assignedAuthor
1 … 1(Hea...son)
Treeblank.pngTreetree.png@classCode
cs0 … 1FASSIGNED
Treeblank.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.(Hea...son)
Treeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1R
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.4.16
Treeblank.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!
(Hea...son)
 
Target.png
vomgt-data​element-679Kyellow.png ASV-Teamnummer Kyellow.png KV-Mustersammlung
Treeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1R
Treeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.4.200
Treeblank.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(Hea...son)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.101 S_BAR2_ARZTNRFACHGRUPPE (DYNAMIC)
Treeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...son)
Treeblank.pngTreetree.pnghl7:assigned​Person
1 … 1M(Hea...son)
Eingefügt von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
0 … 1FPSN
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
0 … 1FINSTANCE
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
PN1 … 1M(Hea...son)
Treeblank.pngTreetree.pnghl7:represented​Organization
1 … 1M(Hea...son)
 
Target.png
vomgt-data​element-756Kyellow.png Krankenhaus Kyellow.png KV-Mustersammlung
 Beispiel<representedOrganization classCode="ORG" determinerCode="INSTANCE">
  <id root="1.2.276.0.76.4.17" extension="123456700"/>  <name>
    <!-- ... -->
  </name></representedOrganization>
Eingefügt von 1.2.276.0.76.10.90032 CDA Organization Elements (vomgt) (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FORG
Treeblank.pngTreeblank.pngTreetree.png@determiner​Code
cs0 … 1FINSTANCE
Treeblank.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! 		(Hea...son)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st0 … 1 
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid0 … 1F1.2.276.0.76.4.17
Treeblank.pngTreeblank.pngTreetree.pnghl7:name
ON1 … 1M(Hea...son)
Treeblank.pngTreeblank.pngTreetree.pnghl7:telecom
TEL0 … *(Hea...son)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
AD0 … 1(Hea...son)

CDA recordTarget (vomgt)

Id1.2.276.0.76.10.2048Gültigkeit2016‑02‑19 15:12:48
StatusKyellow.png EntwurfVersions-Label
NameCDArecordTargetvomgtBezeichnungCDA 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)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
vomgt-data​element-4Kyellow.png Patientendaten Kyellow.png KV-Mustersammlung
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)
 
Target.png
vomgt-data​element-4Kyellow.png Patientendaten Kyellow.png KV-Mustersammlung
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.pngTreeblank.pngTreetree.png@classCode
cs0 … 1FPSN
Treeblank.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.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.
(CDA...mgt)
 
Target.png
vomgt-data​element-26Kyellow.png Name Kyellow.png KV-Mustersammlung
vomgt-data​element-773Kyellow.png Full Name Kyellow.png KV-Mustersammlung
 Beispiel
Dr. med. Sine Johanna Gräfin von Oberberg
<name>
  <prefix qualifier="AC">Dr. med. </prefix>  <given>Sine Johanna</given>  <prefix qualifier="NB">Gräfin </prefix>  <prefix qualifier="VV">von </prefix>  <family>Oberberg</family></name>
 Beispiel
Prof. Dr. med. Dr. rer. nat. Fritz Julius Karl Freiherr von und zu Rathenburg vor der Isar, MdB
<name>
  <prefix qualifier="AC">Prof. Dr. med. Dr. rer. nat. </prefix>  <given>Fritz</given>  <given>Julius</given>  <given>Karl</given>  <prefix qualifier="NB">Freiherr </prefix>  <prefix qualifier="VV">von und zu </prefix>  <family>Rathenburg vor der
Isar</family>  <suffix>, MdB</suffix></name>
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Titel(CDA...mgt)
wo [@qualifier='AC']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FAC
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:given
ENXP0 … *Vorname(CDA...mgt)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Namenszusatz(CDA...mgt)
wo [@qualifier='NB']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FNB
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:prefix
ENXP0 … *Vorsatzwort(CDA...mgt)
wo [@qualifier='VV']
Treeblank.pngTreeblank.pngTreeblank.pngTreeblank.pngTreetree.png@qualifier
set_cs1 … 1FVV
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:family
ENXP0 … *Nachname(CDA...mgt)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:suffix
ENXP0 … *Suffix(CDA...mgt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:administrative​Gender​Code
CENPHier sollte das administrative Geschlecht des Patienten übermittelt werden. In KBV-Formularen spielt allerdings nur die Information über das Geschlecht eine Rolle, was auf der eGK enthalten ist. Dies wird über eine separate Observation übermittelt. Deshalb entfällt diese Element.
(Weitere Informationen zu diesem Thema: http://wiki.hl7.de/index.php?title=Geschlecht)

(CDA...mgt)
Treeblank.pngTreeblank.pngTreetree.pnghl7:birthTime
TS.​DATE.​MIN1 … 1MGeburtsdatum des Patienten(CDA...mgt)
 Beispiel<birthTime value="19491224"/>


CDA Section Level Templates

Insurance Section

Id1.2.276.0.76.10.3103Gültigkeit2016‑02‑25 18:55:55
StatusKyellow.png EntwurfVersions-Label
NameInsuranceSectionBezeichnungInsurance Section
Beschreibung
In diesem Abschnitt werden die Versichertendaten untergebracht. 

Hintergrund: Durch das CDA RMIM ist es nicht möglich alle notwendigen Versicherteninformationen als Participant im Header unterzubringen.
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.3103
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
vomgt-data​element-24Kyellow.png Versichertendaten Kyellow.png KV-Mustersammlung
Benutzt
Benutzt 1 Template
Benutzt als NameVersion
1.2.276.0.76.10.4263ContainmentKyellow.png Coverage ActivityDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-

Adaptation: Template 2.16.840.1.113883.10.20.22.2.18 Payers Section (V3) (DYNAMIC)
ref
ccda-
Beispiel
Beispiel
<section>
  <templateId root="1.2.276.0.76.10.3103"/>  <code code="48768-0" codeSystem="2.16.840.1.113883.6.1"/>  <title>Versicherung</title>  <!-- Versicherung/Coverage -->
  <!-- .... -->
</section>
ItemDTKardKonfBeschreibungLabel
hl7:section
(Ins...ion)
 
Target.png
vomgt-data​element-24Kyellow.png Versichertendaten Kyellow.png KV-Mustersammlung
Treetree.pnghl7:templateId
II1 … 1M(Ins...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.3103
Treetree.pnghl7:code
1 … 1MPayment sources Document(Ins...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1F48768-6
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:title
ST1 … 1(Ins...ion)
 CONF
Elementinhalt muss "Versicherung" sein
Treetree.pnghl7:entry
1 … 1MBeinhaltet 1.2.276.0.76.10.4263 Coverage Activity (DYNAMIC)(Ins...ion)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treeblank.pngTreetree.png@context​Conduction​Ind
bl0 … 1 

Rezept Section

Under construction icon-blue.svg Hier fehlt die korrekte OID.

1.2.276.0.76.3.1.135.8.10.102/dynamic

wichtige Angaben Section

Id1.2.276.0.76.10.3042Gültigkeit2014‑11‑01
StatusKyellow.png EntwurfVersions-Label
NameInstructionsBezeichnungWichtige Angaben
BeschreibungWichtige Angaben/Hinweise für den Patienten
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.3042
Labelinstpmp
KlassifikationCDA Section level template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)
ref
ad1bbr-

Spezialisierung: Template 2.16.840.1.113883.10.20.21.2.45.2 (DYNAMIC)
ref
?
Beispiel
Beispiel
<section classCode="DOCSECT" moodCode="EVN">
  <templateId root="1.2.276.0.76.10.3042"/>  <code code="69730-0" codeSystem="2.16.840.1.113883.6.1" displayName="Instructions"/>  <title>Wichtige Angaben</title>  <text>
    Bitte messen Sie Ihren Blutdruck täglich!    <br/>     Nächster Impftermin: 24.12.2014    <br/>     Bei Rissen in der Hornhaut bitte Desinfektion auftragen.  </text></section>
ItemDTKardKonfBeschreibungLabel
hl7:section
0 … *instpmp
Treetree.png@classCode
0 … 1FDOCSECT
Treetree.png@moodCode
0 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1instpmp
Treeblank.pngTreetree.png@root
1 … 1F1.2.276.0.76.10.3042
Treetree.pnghl7:code
CE1 … 1Minstpmp
Treeblank.pngTreetree.png@code
CONF1 … 1F69730-0
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
 Beispiel<code code="69730-0" displayName="Instructions" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
Treetree.pnghl7:title
ST1 … 1Minstpmp
 CONF
Elementinhalt muss "Wichtige Angaben" sein
Treetree.pnghl7:text
SD.TEXT1 … 1Minstpmp


CDA Entry Level Templates

Coverage Activity

Id1.2.276.0.76.10.4263Gültigkeit2016‑02‑25 19:00:30
StatusKyellow.png EntwurfVersions-Label
NameCoverageActivityBezeichnungCoverage Activity
BeschreibungDieses Template ist der "Aufhänger" für die Detailangaben zum Versicherungsverhältnis, also insbesondere die Informationen von der Gesundheitskarte (eGK).
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.4263
KlassifikationCDA Entry 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.4264ContainmentKyellow.png Policy ActivityDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.301 CDA Act (2005‑09‑07)
ref
ad1bbr-

Spezialisierung: Template 2.16.840.1.113883.10.20.22.4.60 Coverage Activity (V3) (DYNAMIC)
ref
ccda-
ItemDTKardKonfBeschreibungLabel
hl7:act
(Cov...ity)
Treetree.png@classCode
cs1 … 1FACT
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(Cov...ity)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.4263
Treetree.pnghl7:id
0 … *(Cov...ity)
Treetree.pnghl7:code
1 … 1MPayment sources Document(Cov...ity)
Treeblank.pngTreetree.png@code
CONF1 … 1F48768-6
Treeblank.pngTreetree.png@codeSystem
1 … 1F2.16.840.1.113883.6.1 (LOINC)
Treetree.pnghl7:statusCode
1 … 1M(Cov...ity)
Treeblank.pngTreetree.png@code
CONF1 … 1Fcompleted
Treetree.pnghl7:entryRelationship
1 … 1MIm Verordnungsmanagement muss die Information zu genau einer Versicherung übermittelt werden.

Beinhaltet 1.2.276.0.76.10.4264 Policy Activity (DYNAMIC)		(Cov...ity)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP

DMP Observation

Id1.2.276.0.76.10.4271Gültigkeit2017‑12‑01 14:01:13
Andere Versionen mit dieser Id:
  • Kblank.png DMPObservation vom 2017‑11‑29 14:43:15
StatusKyellow.png EntwurfVersions-Label
NameDMPObservationBezeichnungDMP Observation
BeschreibungMit dieser Observation wird die DMP-Zuordnung angegeben.
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.4271
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungAdaptation: Template 1.2.276.0.76.3.1.135.8.10.34 DMP Observation (2017‑11‑29 14:43:15)
Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:observation
(DMP...ion)
Treetree.png@classCode
cs0 … 1FOBS
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(DMP...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.4271
Treetree.pnghl7:code
CD1 … 1M(DMP...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1FDMP
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99)
Treetree.pnghl7:value
CE1 … 1M(DMP...ion)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.138 S_KBV_DMP (DYNAMIC)

eGK-Geschlecht Observation

Id1.2.276.0.76.10.4272Gültigkeit2017‑11‑29 18:17:27
StatusKyellow.png EntwurfVersions-Label
NameeGKGeschlechtObservationBezeichnungeGK-Geschlecht Observation
Beschreibung
Mit dieser Observation wird das Geschlecht angegeben, das auf der eGK hinterlegt ist.
(Hier handelt es sich nicht um das administrative Geschlecht, für das recordTarget.administrativeGender vorgesehen ist.)
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.4272
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:observation
(eGK...ion)
Treetree.png@classCode
cs0 … 1FOBS
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(eGK...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.4272
Treetree.pnghl7:code
CD1 … 1M(eGK...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1FeGK_Gender
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99)
Treetree.pnghl7:value
CD1 … 1M(eGK...ion)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.458 Geschlecht (eGK) (DYNAMIC)
oder
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.3.1.135.8.11.25 Geschlecht2 (eGK) (DYNAMIC)

KV-Zuordnung Observation

Id1.2.276.0.76.10.4275Gültigkeit2018‑02‑27 12:35:11
StatusKyellow.png EntwurfVersions-Label
NameKVZuordnungObservationBezeichnungKv-Zuordnung Observation
BeschreibungMit dieser Observation wird die Zuordnung zur KV angegeben.
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.4275
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungAdaptation: Template 1.2.276.0.76.3.1.135.8.10.34 DMP Observation (2017‑11‑29 14:43:15)
Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:observation
(KVZ...ion)
Treetree.png@classCode
cs0 … 1FOBS
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(KVZ...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.4275
Treetree.pnghl7:code
CD1 … 1M(KVZ...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1FKV-Zuordnung
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99)
Treetree.pnghl7:value
CE1 … 1M(KVZ...ion)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.148 S_KBV_KV (DYNAMIC)


Rezept Entry

Under construction icon-blue.svg Hier fehlt noch die korrekte OID.

1.2.276.0.76.3.1.135.8.10.104/dynamic


Person Group Observation

Id1.2.276.0.76.10.4273Gültigkeit2017‑11‑29 14:46:01
StatusKyellow.png EntwurfVersions-Label
NamePersonGroupObservationBezeichnungPerson Group Observation
BeschreibungMit dieser Observation wird innerhalb der Coverage die Personengruppe angegeben.
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.4273
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 1 Konzept
IdNameDatensatz
vomgt-data​element-632Kyellow.png Personengruppe Kyellow.png KV-Mustersammlung
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:observation
(Per...ion)
Treetree.png@classCode
cs0 … 1FOBS
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(Per...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.4273
Treetree.pnghl7:code
CD1 … 1M(Per...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1FPRSNGRP
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99)
Treetree.pnghl7:value
CE1 … 1M(Per...ion)
 
Target.png
vomgt-data​element-632Kyellow.png Personengruppe Kyellow.png KV-Mustersammlung
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.151 S_KBV_PERSONENGRUPPE (DYNAMIC)

Policy Activity

Id1.2.276.0.76.10.4264Gültigkeit2016‑02‑25 19:07:54
StatusKyellow.png EntwurfVersions-Label
NamePolicyActivityBezeichnungPolicy Activity
Beschreibung
Diese Aktivität ist der Aufhänger für die Informationen über den Kostenträger. Diese Details stammen primär von der eGK.


Durch die Änderung der Versicherteninformation und der dazugehörigen Kodesysteme, so dass eine mehrstellige Information inkl. "00 - keine Angabe" übermittelt werden muss, werden die entsprechenden Details als "mandatory" deklariert.
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.4264
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
Assoziiert mit
Assoziiert mit 3 Konzepte
IdNameDatensatz
vomgt-data​element-25Kyellow.png KrankenkassenName Kyellow.png KV-Mustersammlung
vomgt-data​element-30Kyellow.png Kassen-IKNr Kyellow.png KV-Mustersammlung
vomgt-data​element-31Kyellow.png eGK-Nummer Kyellow.png KV-Mustersammlung
Benutzt
Benutzt 5 Templates
Benutzt als NameVersion
1.2.276.0.76.10.4280ContainmentKyellow.png Weitere Kennzeichen ObservationDYNAMIC
1.2.276.0.76.10.4273ContainmentKyellow.png Person Group ObservationDYNAMIC
1.2.276.0.76.10.4271ContainmentKyellow.png DMP ObservationDYNAMIC
1.2.276.0.76.10.4275ContainmentKyellow.png Kv-Zuordnung ObservationDYNAMIC
1.2.276.0.76.10.4272ContainmentKyellow.png eGK-Geschlecht ObservationDYNAMIC
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.301 CDA Act (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:act
1 … 1R(Pol...ity)
 
Target.png
vomgt-data​element-25Kyellow.png KrankenkassenName Kyellow.png KV-Mustersammlung
vomgt-data​element-30Kyellow.png Kassen-IKNr Kyellow.png KV-Mustersammlung
Treetree.png@classCode
cs1 … 1FACT
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
1 … 1M(Pol...ity)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.4264
Treetree.pnghl7:id
0 … *(Pol...ity)
Treetree.pnghl7:code
CD1 … 1M(Pol...ity)
Treeblank.pngTreetree.png@code
CONF1 … 1FPOLICY
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99)
Treetree.pnghl7:statusCode
1 … 1M(Pol...ity)
Treeblank.pngTreetree.png@code
CONF1 … 1Fcompleted
Treetree.pnghl7:performer
1 … 1MDieser Performer repräsentiert die Krankenkasse(Pol...ity)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FPRF
Treeblank.pngTreetree.pnghl7:assignedEntity
1 … 1M(Pol...ity)
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1MKostenträgerkennung(Pol...ity)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.4.5
Treeblank.pngTreeblank.pngTreetree.pnghl7:represented​Organization
0 … 1R(Pol...ity)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
1 … 1MBezeichnung der Krankenkasse (Bedruckungsname)
(Pol...ity)
Treetree.pnghl7:participant
1 … 1MInformation über den Versicherten
(Eine Unterscheidung in Versicherungsnehmer/-versicherter ist an dieser Stelle nicht notwendig, da die Daten der eGK genutzt werden.)
(Pol...ity)
wo [@typeCode='COV']
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOV
Treeblank.pngTreetree.pnghl7:time
0 … 1R(Pol...ity)
Treeblank.pngTreeblank.pngTreetree.pnghl7:low
0 … 1RVersicherungsbeginn
(Pol...ity)
Treeblank.pngTreeblank.pngTreetree.pnghl7:high
0 … 1RVersicherungsende
(Pol...ity)
Treeblank.pngTreetree.pnghl7:participantRole
1 … 1M(Pol...ity)
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II1 … 1MVersichertennummer (eGK-Nummer)
(Pol...ity)
 
Target.png
vomgt-data​element-31Kyellow.png eGK-Nummer 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.8
 Beispiel
eGK Nummer als Patientenidentifikation
<id extension="A123456789" root="1.2.276.0.76.4.8"/>
Treeblank.pngTreeblank.pngTreetree.pnghl7:id
II0 … 1RIn weiteren Wiederholungen können auch weitere Identifikatoren (ID aus Selektivvertrag, lokale Patientenidentifikation, etc.) übermittelt werden.
(Pol...ity)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@extension
st1 … 1R
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.4.8
 Beispiel
lokale Patientennummer
<id extension="186245" root="1.2.276.0.76.3.1.139.3.871"/>
 Beispiel
ID aus Selektivvertrag
<id extension="SV124-5" root="1.2.276.0.76.99.1.5.6"/>
Treeblank.pngTreeblank.pngTreetree.pnghl7:code
CD1 … 1Versichertenstatus(Pol...ity)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.162 S_KBV_VERSICHERTENSTATUS (DYNAMIC)
Treeblank.pngTreeblank.pngTreetree.pnghl7:addr
0 … 1R(Pol...ity)
Treeblank.pngTreeblank.pngTreetree.pnghl7:playingEntity
0 … 1R(Pol...ity)
Treeblank.pngTreeblank.pngTreeblank.pngTreetree.pnghl7:name
1 … *MFalls sich der Name der versicherten Person unterscheidet, bspw. durch Heirat.
(Pol...ity)
Treetree.pnghl7:entryRelationship
1 … 1MBeinhaltet 1.2.276.0.76.10.4280 Weitere Kennzeichen Observation (DYNAMIC)(Pol...ity)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treetree.pnghl7:entryRelationship
1 … 1MBeinhaltet 1.2.276.0.76.10.4273 Person Group Observation (DYNAMIC)(Pol...ity)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treetree.pnghl7:entryRelationship
1 … 1MBeinhaltet 1.2.276.0.76.10.4271 DMP Observation (DYNAMIC)(Pol...ity)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treetree.pnghl7:entryRelationship
0 … 1RBeinhaltet 1.2.276.0.76.10.4275 Kv-Zuordnung Observation (DYNAMIC)(Pol...ity)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP
Treetree.pnghl7:entryRelationship
0 … 1RDie Übermittlung der Geschlechtsinformation von der eGK hängt von dem Muster ab. In einigen ist diese Information verpflichtend, in anderen wiederum verboten. Dies wird über entsprechende Regeln überprüft, die von dem classCode abhängig sind.

Beinhaltet 1.2.276.0.76.10.4272 eGK-Geschlecht Observation (DYNAMIC)		(Pol...ity)
Treeblank.pngTreetree.png@typeCode
cs1 … 1FCOMP

Weitere Kennzeichen Observation

Id1.2.276.0.76.10.4280Gültigkeit2018‑03‑08 17:32:15
StatusKyellow.png EntwurfVersions-Label
NameweitereKennzeichenObservationBezeichnungWeitere Kennzeichen Observation
BeschreibungWeitere Kennzeichen Observation
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.4280
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungSpezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:observation
(wei...ion)
Treetree.png@classCode
cs0 … 1FOBS
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(wei...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.4280
Treetree.pnghl7:id
II0 … *(wei...ion)
Treetree.pnghl7:code
CD1 … 1M(wei...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1FKENNZEICHEN
Treetree.pnghl7:value
CD1 … 1M(wei...ion)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.459 S_KBV_STATUSKENNZEICHEN (DYNAMIC)

WOP-Kennzeichen Observation

Id1.2.276.0.76.10.4274Gültigkeit2018‑02‑23 17:05:11
StatusKyellow.png EntwurfVersions-Label
NameWOPObservationBezeichnungWOP-Kennzeichen Observation
BeschreibungMit dieser Observation wird das WOP-Kennzeichen angegeben.
KontextElternknoten des Template-Element mit Id 1.2.276.0.76.10.4274
KlassifikationCDA Entry Level Template
Offen/GeschlossenOffen (auch andere als die definierten Elemente sind erlaubt)
BeziehungAdaptation: Template 1.2.276.0.76.3.1.135.8.10.34 DMP Observation (2017‑11‑29 14:43:15)
Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07)
ref
ad1bbr-
ItemDTKardKonfBeschreibungLabel
hl7:observation
(WOP...ion)
Treetree.png@classCode
cs0 … 1FOBS
Treetree.png@moodCode
cs1 … 1FEVN
Treetree.pnghl7:templateId
II1 … 1M(WOP...ion)
Treeblank.pngTreetree.png@root
uid1 … 1F1.2.276.0.76.10.4274
Treetree.pnghl7:code
CD1 … 1M(WOP...ion)
Treeblank.pngTreetree.png@code
CONF1 … 1FWOP
Treeblank.pngTreetree.png@codeSystem
1 … 1F1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99)
Treetree.pnghl7:value
CE1 … 1M(WOP...ion)
 CONF
Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.172 S_KTS_WOP (DYNAMIC)


Terminologien

Folgende Terminologien werden verwendet.

eGK-Geschlecht

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


DMP

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


Personengruppe

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


Versichertenstatus

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


Anhang

Referenzen

  1. ↑ Abstimmungsverfahren (Regeln) des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Abstimmungsverfahren_(Regeln)
  2. ↑ HL7 Deutschland e. V. http://www.hl7.de

Abbildungen

  1. ↑ Muster 16
  2. ↑ Interaktionsdiagramm
  3. ↑ Use Cases
  4. ↑ CDA-Dokument-Template
Abgerufen von „https://wiki.hl7.de/index.php?title=IG:ERezept&oldid=54597“