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)

	Dieses Dokument gibt wieder: Implementierungsleitfaden eRezept (0.1). Die Teilmaterialien gehören der Kategorie cdam16 an.

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:	Deutschland

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

Kontributoren
	bvitg	Berlin
	HS Niederrhein	Krefeld
	DTHS	Essen
	medatixx	Eltville
100px	Medisoft	Hamburg

Inhaltsverzeichnis

1 Dokumenteninformationen
2 Einleitung
3 Transportaspekte
- 3.1 Interaktionsdiagramm
- 3.2 Dokumentenaustausch
4 Rechtssichere Übertragung
5 Use Case
6 Übersicht CDA Header und Body
7 CDA Document Level Templates
8 CDA Header Level Templates
- 8.1 CDA author Person (vomgt)
- 8.2 CDA recordTarget (vomgt)
9 CDA Section Level Templates
10 CDA Entry Level Templates
11 Terminologien
12 Anhang
- 12.1 Referenzen
- 12.2 Abbildungen

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

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.

^{[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:

^{[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

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

Arzt – Patient – Apotheke – Apothekenrechenzentrum – Krankenkasse – Kassenärztliche Vereinigung
Krankenhaus – Patient – Apotheke – Apothekenrechenzentrum – Krankenkasse – Kassenärztliche Vereinigung
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

^{[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

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

Hier fehlen noch die relevanten Sections

Dieses Dokumententemplate dient der Übermittlung des Sprechstundenbedarfs.

16: eAbgabe/eAbrechnung

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)

Id

1.2.276.0.76.10.2049

Gültigkeit

2016‑09‑06 10:43:05

Status

Entwurf

Versions-Label

Name

HeaderAuthorPerson

Bezeichnung

CDA author Person (vomgt)

Beschreibung

Dieses Template spezifiziert, wie ein Mensch/Person als Autor des Dokumentes angegeben wird.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 6 Konzepte

Id	Name	Datensatz
vomgt-dataelement-3	Arztdaten	KV-Mustersammlung
vomgt-dataelement-33	Betriebsstättennummer	KV-Mustersammlung
vomgt-dataelement-34	Arzt-Nr	KV-Mustersammlung
vomgt-dataelement-679	ASV-Teamnummer	KV-Mustersammlung
vomgt-dataelement-755	Krankenhausaufnahme	KV-Mustersammlung
vomgt-dataelement-756	Krankenhaus	KV-Mustersammlung

Benutzt

Benutzt 2 Templates

Benutzt	als	Name	Version
1.2.276.0.76.10.90010	Inklusion	CDA Person Elements	DYNAMIC
1.2.276.0.76.10.90032	Inklusion	CDA Organization Elements (vomgt)	DYNAMIC

Beziehung

Spezialisierung: Template 1.2.276.0.76.10.2002 CDA author (DYNAMIC)

ref

hl7de-

Spezialisierung: Template 2.16.840.1.113883.10.12.102 CDA author (DYNAMIC)

ref

ad1bbr-

Spezialisierung: Template 1.2.276.0.76.10.2007 CDA author Person (2013‑10‑11)

ref

hl7de-

Beispiel

<author typeCode="AUT">
  <templateId root="1.2.276.0.76.10.2049"/>  <functionCode code="DISPHYS" displayName="discharging physican" codeSystem="2.16.840.1.113883.5.88" codeSystemName="ParticipationFunction"/>  <time value="201304071300"/>  <assignedAuthor classCode="ASSIGNED">
    <id root="20cf14fb-b65c-4c8c-a54d-b0cca834c18c"/>    <assignedPerson classCode="PSN" determinerCode="INSTANCE">
      <name>
        <prefix>Dr.med.</prefix>        <given>Karl</given>        <family>Gebhardt</family>      </name>    </assignedPerson>    <representedOrganization>
      <id root="2.16.840.1.113883.19.5"/>      <name>Beispiel Krankenhaus</name>    </representedOrganization>  </assignedAuthor></author>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:author

(Hea...son)

wo [hl7:templateId/@root='1.2.276.0.76.10.2049']


vomgt-dataelement-3	Arztdaten	KV-Mustersammlung
vomgt-dataelement-33	Betriebsstättennummer	KV-Mustersammlung
vomgt-dataelement-34	Arzt-Nr	KV-Mustersammlung

@typeCode

cs

0 … 1

F

AUT

@contextControlCode

cs

0 … 1

F

OP

Beispiel

hl7:templateId

II

1 … 1

M

(Hea...son)

@root

uid

1 … 1

F

1.2.276.0.76.10.2049

hl7:functionCode

CE

0 … 1

(Hea...son)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 2.16.840.1.113883.1.11.10267 ParticipationFunction (DYNAMIC)

hl7:time

TS.DATE.MIN

1 … 1

(Hea...son)


	vomgt-dataelement-755	Krankenhausaufnahme	KV-Mustersammlung

hl7:assignedAuthor

1 … 1

(Hea...son)

@classCode

cs

0 … 1

F

ASSIGNED

hl7:id

II

1 … 1

Die LANR des Arztes wird im id-Element der Rolle (... etc.) in der @extension angegeben. Das Identifikationssystem LANR hat die registrierte OID 1.2.276.0.76.4.16 und wird im @root-Attribut gekennzeichnet.

(Hea...son)

@extension

st

1 … 1

R

@root

uid

1 … 1

F

1.2.276.0.76.4.16

hl7:id

II

0 … 1

R

Die ASV-Teamnummer wird in einer eigenen Wiederholung untergebracht. Die OID dafür ist beantragt, aber noch nicht zugewiesen.

Es muss entweder die ASV-Teamnummer oder die BSNR übermittelt werden!

(Hea...son)


	vomgt-dataelement-679	ASV-Teamnummer	KV-Mustersammlung

@extension

st

1 … 1

R

@root

uid

1 … 1

F

1.2.276.0.76.4.200

hl7:code

CE

0 … 1

Fachgebiet/Spezialität des Gesundheitsdienstleister, z. B. Ärztin/Arzt für Allgemeinmedizin, Approbierte Ärztin/Approbierter Arzt, Fachärztin/Facharzt für Anästhesiologie und Intensivmedizin

(Hea...son)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.101 S_BAR2_ARZTNRFACHGRUPPE (DYNAMIC)

hl7:telecom

TEL

0 … *

(Hea...son)

hl7:assignedPerson

1 … 1

M

(Hea...son)

Eingefügt

von 1.2.276.0.76.10.90010 CDA Person Elements (DYNAMIC)

@classCode

0 … 1

F

PSN

@determinerCode

0 … 1

F

INSTANCE

hl7:name

PN

1 … 1

M

(Hea...son)

hl7:representedOrganization

1 … 1

M

(Hea...son)


	vomgt-dataelement-756	Krankenhaus	KV-Mustersammlung

Beispiel

Eingefügt

von 1.2.276.0.76.10.90032 CDA Organization Elements (vomgt) (DYNAMIC)

@classCode

cs

0 … 1

F

ORG

@determinerCode

cs

0 … 1

F

INSTANCE

hl7:id

II

0 … 1

R

Die BSNR für die entsprechende Betriebsstätte wird im id-Element in @extension angegeben. Das Identifikationssystem BSNR hat die registrierte OID 1.2.276.0.76.4.17 und wird im @root-Attribut gekennzeichnet.
Es muss entweder die BSNR oder die ASV-Teamnummer übermittelt werden!

(Hea...son)

@extension

st

0 … 1

@root

uid

0 … 1

F

1.2.276.0.76.4.17

hl7:name

ON

1 … 1

M

(Hea...son)

hl7:telecom

TEL

0 … *

(Hea...son)

hl7:addr

AD

0 … 1

(Hea...son)

CDA recordTarget (vomgt)

Id

1.2.276.0.76.10.2048

Gültigkeit

2016‑02‑19 15:12:48

Status

Entwurf

Versions-Label

Name

CDArecordTargetvomgt

Bezeichnung

CDA recordTarget (vomgt)

Beschreibung

Das recordTarget repräsentiert die Person, über die dokumentiert wird. recordTarget umfasst IDs und dem Namen, Geschlecht, Adressen etc.

Klassifikation

CDA Header Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
vomgt-dataelement-4	Patientendaten	KV-Mustersammlung

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.276.0.76.10.90030	Inklusion	Personenname	DYNAMIC

Beziehung

Spezialisierung: Template 2.16.840.1.113883.10.12.101 CDA recordTarget (DYNAMIC)

ref

ad1bbr-

Spezialisierung: Template 1.2.276.0.76.10.2001 CDA recordTarget (2013‑07‑10)

ref

hl7de-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:recordTarget

(CDA...mgt)


	vomgt-dataelement-4	Patientendaten	KV-Mustersammlung

@typeCode

cs

0 … 1

F

RCT

@contextControlCode

cs

0 … 1

F

OP

Beispiel

hl7:templateId

1 … 1

M

(CDA...mgt)

@root

uid

1 … 1

F

1.2.276.0.76.10.2048

hl7:patientRole

1 … 1

(CDA...mgt)

@classCode

cs

0 … 1

F

PAT

Beispiel

hl7:id

0 … *

R

(CDA...mgt)

hl7:addr

AD

1 … 1

M

Adresse des Patienten

(CDA...mgt)

Beispiel

normale Adresse

<addr use="HP">
<streetName>Dorfstraße</streetName> <houseNumber>54</houseNumber> <postalCode>51371</postalCode> <city>Leverkusen</city> <country>D</country></addr>

Beispiel

Postfach

<addr use="HP">
<postBox>654321</postBox> <postalCode>51371</postalCode> <city>Leverkusen</city> <country>D</country></addr>

hl7:patient

0 … 1

(CDA...mgt)

@classCode

cs

0 … 1

F

PSN

@determinerCode

cs

0 … 1

F

INSTANCE

Beispiel

Eingefügt

1 … 1

M

von 1.2.276.0.76.10.90030 Personenname (DYNAMIC)

hl7:name

PN

1 … 1

M

Die Reihenfolge der Namensbestandteile soll der typischen Schreibweise entsprechen. Zu beachten ist, dass prefix- und suffix-Elemente mit einem Leerzeichen enden müssen, wenn sie nicht unmittelbar an den folgenden Namensbestandteil anschließen sollen.

(CDA...mgt)


vomgt-dataelement-26	Name	KV-Mustersammlung
vomgt-dataelement-773	Full Name	KV-Mustersammlung

Beispiel

Dr. med. Sine Johanna Gräfin von Oberberg

<name>
<prefix qualifier="AC">Dr. med. </prefix> <given>Sine Johanna</given> <prefix qualifier="NB">Gräfin </prefix> <prefix qualifier="VV">von </prefix> <family>Oberberg</family></name>

Beispiel

Prof. Dr. med. Dr. rer. nat. Fritz Julius Karl Freiherr von und zu Rathenburg vor der Isar, MdB

<name>
<prefix qualifier="AC">Prof. Dr. med. Dr. rer. nat. </prefix> <given>Fritz</given> <given>Julius</given> <given>Karl</given> <prefix qualifier="NB">Freiherr </prefix> <prefix qualifier="VV">von und zu </prefix> <family>Rathenburg vor der
Isar</family> <suffix>, MdB</suffix></name>

hl7:prefix

ENXP

0 … *

Titel

(CDA...mgt)

wo [@qualifier='AC']

@qualifier

set_cs

1 … 1

F

AC

hl7:given

ENXP

0 … *

Vorname

(CDA...mgt)

hl7:prefix

ENXP

0 … *

Namenszusatz

(CDA...mgt)

wo [@qualifier='NB']

@qualifier

set_cs

1 … 1

F

NB

hl7:prefix

ENXP

0 … *

Vorsatzwort

(CDA...mgt)

wo [@qualifier='VV']

@qualifier

set_cs

1 … 1

F

VV

hl7:family

ENXP

0 … *

Nachname

(CDA...mgt)

hl7:suffix

ENXP

0 … *

Suffix

(CDA...mgt)

hl7:administrativeGenderCode

CE

NP

Hier sollte das administrative Geschlecht des Patienten übermittelt werden. In KBV-Formularen spielt allerdings nur die Information über das Geschlecht eine Rolle, was auf der eGK enthalten ist. Dies wird über eine separate Observation übermittelt. Deshalb entfällt diese Element.
(Weitere Informationen zu diesem Thema: http://wiki.hl7.de/index.php?title=Geschlecht)

(CDA...mgt)

hl7:birthTime

TS.DATE.MIN

1 … 1

M

Geburtsdatum des Patienten

(CDA...mgt)

Beispiel

CDA Section Level Templates

Insurance Section

Id

1.2.276.0.76.10.3103

Gültigkeit

2016‑02‑25 18:55:55

Status

Entwurf

Versions-Label

Name

InsuranceSection

Bezeichnung

Insurance Section

Beschreibung

In diesem Abschnitt werden die Versichertendaten untergebracht.

Hintergrund: Durch das CDA RMIM ist es nicht möglich alle notwendigen Versicherteninformationen als Participant im Header unterzubringen.

Kontext

Elternknoten des Template-Element mit Id 1.2.276.0.76.10.3103

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
vomgt-dataelement-24	Versichertendaten	KV-Mustersammlung

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.276.0.76.10.4263	Containment	Coverage Activity	DYNAMIC

Beziehung

Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)

ref

ad1bbr-

Adaptation: Template 2.16.840.1.113883.10.20.22.2.18 Payers Section (V3) (DYNAMIC)

ref

ccda-

Beispiel

<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> 

</section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

(Ins...ion)


	vomgt-dataelement-24	Versichertendaten	KV-Mustersammlung

hl7:templateId

II

1 … 1

M

(Ins...ion)

@root

uid

1 … 1

F

1.2.276.0.76.10.3103

hl7:code

1 … 1

M

Payment sources Document

(Ins...ion)

@code

CONF

1 … 1

F

48768-6

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

hl7:title

ST

1 … 1

(Ins...ion)

CONF

Elementinhalt muss "Versicherung" sein

hl7:entry

1 … 1

M

Beinhaltet 1.2.276.0.76.10.4263 Coverage Activity (DYNAMIC)

(Ins...ion)

@typeCode

cs

1 … 1

F

COMP

@contextConductionInd

bl

0 … 1

Rezept Section

Hier fehlt die korrekte OID.

1.2.276.0.76.3.1.135.8.10.102/dynamic

wichtige Angaben Section

Id

1.2.276.0.76.10.3042

Gültigkeit

2014‑11‑01

Status

Entwurf

Versions-Label

Name

Instructions

Bezeichnung

Wichtige Angaben

Beschreibung

Wichtige Angaben/Hinweise für den Patienten

Kontext

Elternknoten des Template-Element mit Id 1.2.276.0.76.10.3042

Label

instpmp

Klassifikation

CDA Section level template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Spezialisierung: Template 2.16.840.1.113883.10.12.201 CDA Section (2005‑09‑07)

ref

ad1bbr-

Spezialisierung: Template 2.16.840.1.113883.10.20.21.2.45.2 (DYNAMIC)

ref

?

Beispiel

<section classCode="DOCSECT" moodCode="EVN">
<templateId root="1.2.276.0.76.10.3042"/> <code code="69730-0" codeSystem="2.16.840.1.113883.6.1" displayName="Instructions"/> <title>Wichtige Angaben</title> <text>
Bitte messen Sie Ihren Blutdruck täglich! <br/> Nächster Impftermin: 24.12.2014 <br/> Bei Rissen in der Hornhaut bitte Desinfektion auftragen. </text></section>

Item

DT

Kard

Konf

Beschreibung

Label

hl7:section

0 … *

instpmp

@classCode

0 … 1

F

DOCSECT

@moodCode

0 … 1

F

EVN

hl7:templateId

II

1 … 1

instpmp

@root

1 … 1

F

1.2.276.0.76.10.3042

hl7:code

CE

1 … 1

M

instpmp

@code

CONF

1 … 1

F

69730-0

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

Beispiel

hl7:title

ST

1 … 1

M

instpmp

CONF

Elementinhalt muss "Wichtige Angaben" sein

hl7:text

SD.TEXT

1 … 1

M

instpmp

CDA Entry Level Templates

Coverage Activity

Id

1.2.276.0.76.10.4263

Gültigkeit

2016‑02‑25 19:00:30

Status

Entwurf

Versions-Label

Name

CoverageActivity

Bezeichnung

Coverage Activity

Beschreibung

Dieses Template ist der "Aufhänger" für die Detailangaben zum Versicherungsverhältnis, also insbesondere die Informationen von der Gesundheitskarte (eGK).

Kontext

Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4263

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Benutzt

Benutzt 1 Template

Benutzt	als	Name	Version
1.2.276.0.76.10.4264	Containment	Policy Activity	DYNAMIC

Beziehung

Spezialisierung: Template 2.16.840.1.113883.10.12.301 CDA Act (2005‑09‑07)

ref

ad1bbr-

Spezialisierung: Template 2.16.840.1.113883.10.20.22.4.60 Coverage Activity (V3) (DYNAMIC)

ref

ccda-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:act

(Cov...ity)

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

M

(Cov...ity)

@root

uid

1 … 1

F

1.2.276.0.76.10.4263

hl7:id

0 … *

(Cov...ity)

hl7:code

1 … 1

M

Payment sources Document

(Cov...ity)

@code

CONF

1 … 1

F

48768-6

@codeSystem

1 … 1

F

2.16.840.1.113883.6.1 (LOINC)

hl7:statusCode

1 … 1

M

(Cov...ity)

@code

CONF

1 … 1

F

completed

hl7:entryRelationship

1 … 1

M

Im Verordnungsmanagement muss die Information zu genau einer Versicherung übermittelt werden.

Beinhaltet 1.2.276.0.76.10.4264 Policy Activity (DYNAMIC)

(Cov...ity)

@typeCode

cs

1 … 1

F

COMP

DMP Observation

Id

1.2.276.0.76.10.4271

Gültigkeit

2017‑12‑01 14:01:13

Andere Versionen mit dieser Id:

DMPObservation vom 2017‑11‑29 14:43:15

Status

Entwurf

Versions-Label

Name

DMPObservation

Bezeichnung

DMP Observation

Beschreibung

Mit dieser Observation wird die DMP-Zuordnung angegeben.

Kontext

Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4271

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.276.0.76.3.1.135.8.10.34 DMP Observation (2017‑11‑29 14:43:15)
Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07)

ref

ad1bbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:observation

(DMP...ion)

@classCode

cs

0 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

M

(DMP...ion)

@root

uid

1 … 1

F

1.2.276.0.76.10.4271

hl7:code

CD

1 … 1

M

(DMP...ion)

@code

CONF

1 … 1

F

DMP

@codeSystem

1 … 1

F

1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99)

hl7:value

CE

1 … 1

M

(DMP...ion)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.138 S_KBV_DMP (DYNAMIC)

eGK-Geschlecht Observation

Id

1.2.276.0.76.10.4272

Gültigkeit

2017‑11‑29 18:17:27

Status

Entwurf

Versions-Label

Name

eGKGeschlechtObservation

Bezeichnung

eGK-Geschlecht Observation

Beschreibung

Mit dieser Observation wird das Geschlecht angegeben, das auf der eGK hinterlegt ist.
(Hier handelt es sich nicht um das administrative Geschlecht, für das recordTarget.administrativeGender vorgesehen ist.)

Kontext

Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4272

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07)

ref

ad1bbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:observation

(eGK...ion)

@classCode

cs

0 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

M

(eGK...ion)

@root

uid

1 … 1

F

1.2.276.0.76.10.4272

hl7:code

CD

1 … 1

M

(eGK...ion)

@code

CONF

1 … 1

F

eGK_Gender

@codeSystem

1 … 1

F

1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99)

hl7:value

CD

1 … 1

M

(eGK...ion)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.458 Geschlecht (eGK) (DYNAMIC)

oder

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.3.1.135.8.11.25 Geschlecht2 (eGK) (DYNAMIC)

KV-Zuordnung Observation

Id

1.2.276.0.76.10.4275

Gültigkeit

2018‑02‑27 12:35:11

Status

Entwurf

Versions-Label

Name

KVZuordnungObservation

Bezeichnung

Kv-Zuordnung Observation

Beschreibung

Mit dieser Observation wird die Zuordnung zur KV angegeben.

Kontext

Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4275

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.276.0.76.3.1.135.8.10.34 DMP Observation (2017‑11‑29 14:43:15)
Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07)

ref

ad1bbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:observation

(KVZ...ion)

@classCode

cs

0 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

M

(KVZ...ion)

@root

uid

1 … 1

F

1.2.276.0.76.10.4275

hl7:code

CD

1 … 1

M

(KVZ...ion)

@code

CONF

1 … 1

F

KV-Zuordnung

@codeSystem

1 … 1

F

1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99)

hl7:value

CE

1 … 1

M

(KVZ...ion)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.148 S_KBV_KV (DYNAMIC)

Rezept Entry

Hier fehlt noch die korrekte OID.

1.2.276.0.76.3.1.135.8.10.104/dynamic

Person Group Observation

Id

1.2.276.0.76.10.4273

Gültigkeit

2017‑11‑29 14:46:01

Status

Entwurf

Versions-Label

Name

PersonGroupObservation

Bezeichnung

Person Group Observation

Beschreibung

Mit dieser Observation wird innerhalb der Coverage die Personengruppe angegeben.

Kontext

Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4273

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 1 Konzept

Id	Name	Datensatz
vomgt-dataelement-632	Personengruppe	KV-Mustersammlung

Beziehung

Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07)

ref

ad1bbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:observation

(Per...ion)

@classCode

cs

0 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

M

(Per...ion)

@root

uid

1 … 1

F

1.2.276.0.76.10.4273

hl7:code

CD

1 … 1

M

(Per...ion)

@code

CONF

1 … 1

F

PRSNGRP

@codeSystem

1 … 1

F

1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99)

hl7:value

CE

1 … 1

M

(Per...ion)


	vomgt-dataelement-632	Personengruppe	KV-Mustersammlung

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.151 S_KBV_PERSONENGRUPPE (DYNAMIC)

Policy Activity

Id

1.2.276.0.76.10.4264

Gültigkeit

2016‑02‑25 19:07:54

Status

Entwurf

Versions-Label

Name

PolicyActivity

Bezeichnung

Policy Activity

Beschreibung

Diese Aktivität ist der Aufhänger für die Informationen über den Kostenträger. Diese Details stammen primär von der eGK.

Durch die Änderung der Versicherteninformation und der dazugehörigen Kodesysteme, so dass eine mehrstellige Information inkl. "00 - keine Angabe" übermittelt werden muss, werden die entsprechenden Details als "mandatory" deklariert.

Kontext

Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4264

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Assoziiert mit

Assoziiert mit 3 Konzepte

Id	Name	Datensatz
vomgt-dataelement-25	KrankenkassenName	KV-Mustersammlung
vomgt-dataelement-30	Kassen-IKNr	KV-Mustersammlung
vomgt-dataelement-31	eGK-Nummer	KV-Mustersammlung

Benutzt

Benutzt 5 Templates

Benutzt	als	Name	Version
1.2.276.0.76.10.4280	Containment	Weitere Kennzeichen Observation	DYNAMIC
1.2.276.0.76.10.4273	Containment	Person Group Observation	DYNAMIC
1.2.276.0.76.10.4271	Containment	DMP Observation	DYNAMIC
1.2.276.0.76.10.4275	Containment	Kv-Zuordnung Observation	DYNAMIC
1.2.276.0.76.10.4272	Containment	eGK-Geschlecht Observation	DYNAMIC

Beziehung

Spezialisierung: Template 2.16.840.1.113883.10.12.301 CDA Act (2005‑09‑07)

ref

ad1bbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:act

1 … 1

R

(Pol...ity)


vomgt-dataelement-25	KrankenkassenName	KV-Mustersammlung
vomgt-dataelement-30	Kassen-IKNr	KV-Mustersammlung

@classCode

cs

1 … 1

F

ACT

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

1 … 1

M

(Pol...ity)

@root

uid

1 … 1

F

1.2.276.0.76.10.4264

hl7:id

0 … *

(Pol...ity)

hl7:code

CD

1 … 1

M

(Pol...ity)

@code

CONF

1 … 1

F

POLICY

@codeSystem

1 … 1

F

1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99)

hl7:statusCode

1 … 1

M

(Pol...ity)

@code

CONF

1 … 1

F

completed

hl7:performer

1 … 1

M

Dieser Performer repräsentiert die Krankenkasse

(Pol...ity)

@typeCode

cs

1 … 1

F

PRF

hl7:assignedEntity

1 … 1

M

(Pol...ity)

hl7:id

II

1 … 1

M

Kostenträgerkennung

(Pol...ity)

@extension

st

1 … 1

R

@root

uid

1 … 1

F

1.2.276.0.76.4.5

hl7:representedOrganization

0 … 1

R

(Pol...ity)

hl7:name

1 … 1

M

Bezeichnung der Krankenkasse (Bedruckungsname)

(Pol...ity)

hl7:participant

1 … 1

M

Information über den Versicherten
(Eine Unterscheidung in Versicherungsnehmer/-versicherter ist an dieser Stelle nicht notwendig, da die Daten der eGK genutzt werden.)

(Pol...ity)

wo [@typeCode='COV']

@typeCode

cs

1 … 1

F

COV

hl7:time

0 … 1

R

(Pol...ity)

hl7:low

0 … 1

R

Versicherungsbeginn

(Pol...ity)

hl7:high

0 … 1

R

Versicherungsende

(Pol...ity)

hl7:participantRole

1 … 1

M

(Pol...ity)

hl7:id

II

1 … 1

M

Versichertennummer (eGK-Nummer)

(Pol...ity)


	vomgt-dataelement-31	eGK-Nummer	KV-Mustersammlung

@extension

st

1 … 1

R

@root

uid

1 … 1

F

1.2.276.0.76.4.8

Beispiel

eGK Nummer als Patientenidentifikation

hl7:id

II

0 … 1

R

In weiteren Wiederholungen können auch weitere Identifikatoren (ID aus Selektivvertrag, lokale Patientenidentifikation, etc.) übermittelt werden.

(Pol...ity)

@extension

st

1 … 1

R

@root

uid

1 … 1

F

1.2.276.0.76.4.8

Beispiel

lokale Patientennummer

Beispiel

ID aus Selektivvertrag

hl7:code

CD

1 … 1

Versichertenstatus

(Pol...ity)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.162 S_KBV_VERSICHERTENSTATUS (DYNAMIC)

hl7:addr

0 … 1

R

(Pol...ity)

hl7:playingEntity

0 … 1

R

(Pol...ity)

hl7:name

1 … *

M

Falls sich der Name der versicherten Person unterscheidet, bspw. durch Heirat.

(Pol...ity)

hl7:entryRelationship

1 … 1

M

Beinhaltet 1.2.276.0.76.10.4280 Weitere Kennzeichen Observation (DYNAMIC)

(Pol...ity)

@typeCode

cs

1 … 1

F

COMP

hl7:entryRelationship

1 … 1

M

Beinhaltet 1.2.276.0.76.10.4273 Person Group Observation (DYNAMIC)

(Pol...ity)

@typeCode

cs

1 … 1

F

COMP

hl7:entryRelationship

1 … 1

M

Beinhaltet 1.2.276.0.76.10.4271 DMP Observation (DYNAMIC)

(Pol...ity)

@typeCode

cs

1 … 1

F

COMP

hl7:entryRelationship

0 … 1

R

Beinhaltet 1.2.276.0.76.10.4275 Kv-Zuordnung Observation (DYNAMIC)

(Pol...ity)

@typeCode

cs

1 … 1

F

COMP

hl7:entryRelationship

0 … 1

R

Die Übermittlung der Geschlechtsinformation von der eGK hängt von dem Muster ab. In einigen ist diese Information verpflichtend, in anderen wiederum verboten. Dies wird über entsprechende Regeln überprüft, die von dem classCode abhängig sind.

Beinhaltet 1.2.276.0.76.10.4272 eGK-Geschlecht Observation (DYNAMIC)

(Pol...ity)

@typeCode

cs

1 … 1

F

COMP

Weitere Kennzeichen Observation

Id

1.2.276.0.76.10.4280

Gültigkeit

2018‑03‑08 17:32:15

Status

Entwurf

Versions-Label

Name

weitereKennzeichenObservation

Bezeichnung

Weitere Kennzeichen Observation

Beschreibung

Weitere Kennzeichen Observation

Kontext

Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4280

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07)

ref

ad1bbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:observation

(wei...ion)

@classCode

cs

0 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

M

(wei...ion)

@root

uid

1 … 1

F

1.2.276.0.76.10.4280

hl7:id

II

0 … *

(wei...ion)

hl7:code

CD

1 … 1

M

(wei...ion)

@code

CONF

1 … 1

F

KENNZEICHEN

hl7:value

CD

1 … 1

M

(wei...ion)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.459 S_KBV_STATUSKENNZEICHEN (DYNAMIC)

WOP-Kennzeichen Observation

Id

1.2.276.0.76.10.4274

Gültigkeit

2018‑02‑23 17:05:11

Status

Entwurf

Versions-Label

Name

WOPObservation

Bezeichnung

WOP-Kennzeichen Observation

Beschreibung

Mit dieser Observation wird das WOP-Kennzeichen angegeben.

Kontext

Elternknoten des Template-Element mit Id 1.2.276.0.76.10.4274

Klassifikation

CDA Entry Level Template

Offen/Geschlossen

Offen (auch andere als die definierten Elemente sind erlaubt)

Beziehung

Adaptation: Template 1.2.276.0.76.3.1.135.8.10.34 DMP Observation (2017‑11‑29 14:43:15)
Spezialisierung: Template 2.16.840.1.113883.10.12.303 CDA Observation (2005‑09‑07)

ref

ad1bbr-

Item

DT

Kard

Konf

Beschreibung

Label

hl7:observation

(WOP...ion)

@classCode

cs

0 … 1

F

OBS

@moodCode

cs

1 … 1

F

EVN

hl7:templateId

II

1 … 1

M

(WOP...ion)

@root

uid

1 … 1

F

1.2.276.0.76.10.4274

hl7:code

CD

1 … 1

M

(WOP...ion)

@code

CONF

1 … 1

F

WOP

@codeSystem

1 … 1

F

1.2.276.0.76.3.1.135.8.5.99 (vomgt-codesystem-99)

hl7:value

CE

1 … 1

M

(WOP...ion)

CONF

Der Wert von @code muss gewählt werden aus dem Value Set 1.2.276.0.76.11.172 S_KTS_WOP (DYNAMIC)

Terminologien

Folgende Terminologien werden verwendet.

eGK-Geschlecht

Diese Terminologie ist eine Momentaufnahme vom . Terminologien können sich im Laufe der Zeit weiterentwickeln. Wenn eine neuere (dynamische) Versionen dieser Terminologie benötigt wird, bitte von der Quelle abrufen.

Id

1.2.276.0.76.11.458

Gültigkeit

2018‑03‑06 14:14:42

Status

Entwurf

Versions-Label

Name

Geschlechtegk

Bezeichnung

Geschlecht (eGK)

Beschreibung

Code für das Geschlecht so wie auf der elektronischen Gesundheitskarte kodiert

Benutzung: 1

Id	Name	Typ
Template
1.2.276.0.76.10.4272	eGK-Geschlecht Observation	DYNAMIC

Quell-Codesystem

1.2.276.0.76.5.483 - FHIR: urn:oid:1.2.276.0.76.5.483

Level/ Typ	Code	Bezeichnung	Codesystem
0‑L	M	männlich	1.2.276.0.76.5.483
0‑L	W	weiblich	1.2.276.0.76.5.483
0‑L	X	nicht angegeben	1.2.276.0.76.5.483

Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) schlägt Text in originalText vor. HL7 V3: NullFlavors werden im @nullFlavor Attribut statt in @code angegeben.

DMP

Diese Terminologie ist eine Momentaufnahme vom . Terminologien können sich im Laufe der Zeit weiterentwickeln. Wenn eine neuere (dynamische) Versionen dieser Terminologie benötigt wird, bitte von der Quelle abrufen.

Id

1.2.276.0.76.11.138

Gültigkeit

2019‑01‑01

Status

Definitiv

Versions-Label

1.03

Name

S_KBV_DMP

Bezeichnung

S_KBV_DMP

Beschreibung

DMP-Kennzeichen: gibt an, in welchen DMPs ein Versicherter eingeschrieben ist (§ 267 Abs. 2 Satz 4 SGB V). Die Angabe ist auf der EGK vorhanden und auf der KVK Teil des Feldes: Statusergänzung.

Benutzung: 2

Id	Name	Typ
Datensatz
konsab-dataelement-130	DMP-Zuordnung	DYNAMIC
Template
1.2.276.0.76.10.4271	DMP Observation	DYNAMIC

Quell-Codesystem

1.2.276.0.76.5.223 - FHIR: urn:oid:1.2.276.0.76.5.223

Level/ Typ	Code	Bezeichnung	Codesystem
0‑L	00	nicht gesetzt	1.2.276.0.76.5.223
0‑L	01	DM2	1.2.276.0.76.5.223
0‑L	02	BRK	1.2.276.0.76.5.223
0‑L	03	KHK	1.2.276.0.76.5.223
0‑L	04	DM1	1.2.276.0.76.5.223
0‑L	05	Asthma	1.2.276.0.76.5.223
0‑L	06	COPD	1.2.276.0.76.5.223
0‑L	07	HI	1.2.276.0.76.5.223
0‑L	08	Depression	1.2.276.0.76.5.223
0‑L	09	Rueckenschmerz	1.2.276.0.76.5.223
0‑D	1	DM2	1.2.276.0.76.5.223
0‑D	2	BRK	1.2.276.0.76.5.223
0‑D	3	KHK	1.2.276.0.76.5.223
0‑D	4	DM1	1.2.276.0.76.5.223
0‑D	5	Asthma	1.2.276.0.76.5.223
0‑D	6	COPD	1.2.276.0.76.5.223

Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) schlägt Text in originalText vor. HL7 V3: NullFlavors werden im @nullFlavor Attribut statt in @code angegeben.

Personengruppe

Diese Terminologie ist eine Momentaufnahme vom . Terminologien können sich im Laufe der Zeit weiterentwickeln. Wenn eine neuere (dynamische) Versionen dieser Terminologie benötigt wird, bitte von der Quelle abrufen.

Id

1.2.276.0.76.11.151

Gültigkeit

2018‑07‑01

Status

Definitiv

Versions-Label

1.02

Name

S_KBV_PERSONENGRUPPE

Bezeichnung

S_KBV_PERSONENGRUPPE

Beschreibung

Personengruppe: kennzeichnet, zu welcher Personengruppe der Versicherte gehört (§ 264 SGB V). Die Angabe ist auf der EGK vorhanden und auf der KVK Teil des Feldes: Statusergänzung.

Benutzung: 2

Id	Name	Typ
Datensatz
konsab-dataelement-124	Personengruppe	DYNAMIC
Template
1.2.276.0.76.10.4273	Person Group Observation	DYNAMIC

Quell-Codesystem

1.2.276.0.76.5.222 - FHIR: urn:oid:1.2.276.0.76.5.222

Level/ Typ	Code	Bezeichnung	Codesystem
0‑L	00	nicht gesetzt	1.2.276.0.76.5.222
0‑L	04	SOZ	1.2.276.0.76.5.222
0‑L	06	BVG	1.2.276.0.76.5.222
0‑L	07	SVA1	1.2.276.0.76.5.222
0‑L	08	SVA2	1.2.276.0.76.5.222
0‑L	09	ASY	1.2.276.0.76.5.222
0‑D	4	SOZ	1.2.276.0.76.5.222
0‑D	6	BVG	1.2.276.0.76.5.222
0‑D	7	SVA1	1.2.276.0.76.5.222
0‑D	8	SVA2	1.2.276.0.76.5.222

Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) schlägt Text in originalText vor. HL7 V3: NullFlavors werden im @nullFlavor Attribut statt in @code angegeben.

Versichertenstatus

Diese Terminologie ist eine Momentaufnahme vom . Terminologien können sich im Laufe der Zeit weiterentwickeln. Wenn eine neuere (dynamische) Versionen dieser Terminologie benötigt wird, bitte von der Quelle abrufen.

Id

1.2.276.0.76.11.162

Gültigkeit

2014‑01‑01

Status

Definitiv

Versions-Label

Name

S_KBV_VERSICHERTENSTATUS

Bezeichnung

S_KBV_VERSICHERTENSTATUS

Beschreibung

Versichertenstatus gibt an, ob ein Versicherter ein Familienversicherter, Mitglied oder Rentner ist. Auf der KVK ist diese Angabe Teil des Feldes VERSICHERTENSTATUS - die 1. Stelle.

Quell-Codesystem

2.16.840.1.113883.3.7.1.1 - KBV_CS_SFHIR_KBV_VERSICHERTENSTATUS

Level/ Typ	Code	Bezeichnung	Codesystem
0‑L	1	Mitglied	2.16.840.1.113883.3.7.1.1
0‑L	3	Familienangehörige	2.16.840.1.113883.3.7.1.1
0‑L	5	Rentner	2.16.840.1.113883.3.7.1.1

Legende: Typ L=leaf, S=specializable, A=abstract, D=deprecated. NullFlavor OTH (other) schlägt Text in originalText vor. HL7 V3: NullFlavors werden im @nullFlavor Attribut statt in @code angegeben.

Anhang

Referenzen

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

Abbildungen

↑ Muster 16
↑ Interaktionsdiagramm
↑ Use Cases
↑ CDA-Dokument-Template

[1] Abstimmungsverfahren (Regeln) des Interoperabilitätsforums http://wiki.hl7.de/index.php?title=Abstimmungsverfahren_(Regeln)

[2] HL7 Deutschland e. V. http://www.hl7.de

[3] Muster 16

[4] Interaktionsdiagramm

[5] Use Cases

[6] CDA-Dokument-Template

[1]

[2]

[Abbildung 1]

[Abbildung 2]

[Abbildung 3]

[Abbildung 4]

eRezept

Inhaltsverzeichnis

Dokumenteninformationen

Impressum

Ansprechpartner und Autoren

Disclaimer

Copyright-Hinweis, Nutzungshinweise

Einleitung

Muster 16: Arzneiverordnungsblatt (eRezept)

Rationale

Zweck

Vorarbeiten

Standardisierung

andere KV-Formulare

Nutzer

Forderungen und Potenziale

Abgrenzung

Offene Punkte und Besonderheiten

Transportaspekte

Interaktionsdiagramm

Dokumentenaustausch

Rechtssichere Übertragung

Rechtssichere Übertragung

Akteure

Transportwege

Use Case

eVerschreibung durchführen

eVerschreibung einlösen

eVerschreibung abrechnen

Stornierung einer Verschreibung

Übersicht CDA Header und Body

CDA Document Level Templates

16: eRezept

16: eRezept für Sprechstundenbedarf

16: eAbgabe/eAbrechnung

CDA Header Level Templates

CDA author Person (vomgt)

CDA recordTarget (vomgt)

CDA Section Level Templates

Insurance Section

Rezept Section

wichtige Angaben Section

CDA Entry Level Templates

Coverage Activity

DMP Observation

eGK-Geschlecht Observation

KV-Zuordnung Observation

Rezept Entry

Person Group Observation

Policy Activity

Weitere Kennzeichen Observation

WOP-Kennzeichen Observation

Terminologien

eGK-Geschlecht

DMP

Personengruppe

Versichertenstatus

Anhang

Referenzen

Abbildungen

Navigationsmenü

Suche