deutsche Nachrichtenprofile: eGK-Daten im Originalformat

Aus Hl7wiki
Nachrichtenprofile
Wechseln zu: Navigation, Suche


Abstimmungsdokument 
Version Datum Status Realm
01 6.11.2014 in Arbeit Flag de.svg Deutschland
Document PDF.svg noch kein download verfügbar
Kontributoren 
Logo-Agfa.jpg Agfa HealthCare GmbH Bonn
Logo Health-comm.jpg Health-Comm GmbH München


Version: 01
Ausgabe: 2014
HL7-Version: 2.5
Stand: 06. November 2014
Dokumenten-OID: 2.16.840.1.113883.2.6.7.62
Profil-OID: 2.16.840.1.113883.2.6.9.74


Ansprechpartner:

Frank Oemig, Agfa HealthCare GmbH, Bonn


Dokumentinformation

Änderungshistorie

Version Datum Bemerkung Dok.-OID
0.1 06.11.14 Erstellung


Editor

  • Frank Oemig (FO), Agfa HealthCare GmbH, Bonn


Autoren Ausgabe 2014

  • Simone Heckmann (SH), Health-Comm GmbH, München
  • Frank Oemig (FO), Agfa HealthCare GmbH, Bonn

Autoren und Copyright-Hinweis, Nutzungshinweise

Nachnutzungs- bzw. Veröffentlichungsansprüche

Das vorliegende Dokument wurde von Agfa HealthCare und Health-Comm entwickelt. Die Nachnutzungs- bzw. Veröffentlichungsansprüche sind nicht beschränkt.


Der Inhalt dieser Spezifikation ist öffentlich.

Zu beachten ist, dass Teile dieses Dokuments auf dem HL7-Standard v2.5 beruhen, für die © Health Level Seven, Inc. gilt. Näheres unter [1] und [2].

Die Erweiterung oder Ablehnung der Spezifikation, ganz oder in Teilen, ist dem Vorstand der Benutzergruppe und den Editoren/Autoren schriftlich anzuzeigen.


Alle auf nationale Verhältnisse angepassten und veröffentlichten HL7-Spezifkationen können ohne Lizenz- und Nutzungsgebühren in jeder Art von Anwendungssoftware verwendet werden.


Disclaimer

Obwohl diese Publikation mit größter Sorgfalt erstellt wurde, kann weder die HL7-Benutzergruppe in Deutschland e.V. noch die an der Erstellung beteiligten Firmen keinerlei Haftung für direkten oder indirekten Schaden übernehmen, die durch den Inhalt dieser Spezifikation entstehen könnten.


Einleitung

Es gibt zwei Möglichkeiten, eGK-Daten zu übermitteln:

  • in strukturierter Form mittels der INx-Segmente in Kombination mit dem ZGK-Segment

(siehe Profilkomponente (HL7v2-Profile_Kostenträger)

Ein Großteil der Daten auf der Gesundheitskarte kann in Felder des IN1-Segmentes gemapped werden. (Siehe Spezifikation eGK-Daten)
Zur Übermittlung der verbleibenden Daten auf der KVK wurde das Z-Segment ZGK eingeführt.

Seit der Erweiterung des eGK-Datensatzes auf die Schemaversion 5.2 ist der Datensatz jedoch so umfangreich geworden, dass es nach der Auffassung des Technischen Komitees nicht länger zielführend ist, den Datensatz in ein bzw. mehrere HL7-V2-Segment zu mappen. Die meisten bekannten Use-Cases zielen darauf hin, dass der Empfang der eGK-Daten über die HL7-Schnittstelle anstelle des Einlesens der eGK tritt. Die Übertragung im HL7-Segment macht es daher erforderlich, die weiterverarbeitenden Prozesse im empfangenden System für die eGK-Daten für zwei verschiedene Formate (primärer XML-Datensatz sowie HL7-Segment) zu implementieren. Es erscheint daher logisch, auch bei der Übermittlung der Daten per HL7 das Original-XML-Datensatzformat beizubehalten, so dass die Daten im Zielsystem genau so weiterverarbeitet werden können, wie beim Einlesen der Karte.

Daher empfiehlt das Technische Komitee bei der Übermittlung von eGK-Daten ab der Version 5.2, die XML-Originaldaten in die HL7-Nachricht in ein OBX-Segment einzubetten. Gleichzeitig sollten die enthaltenen Versicherungsinformationen weiterhin strukturiert im IN1-Segment übermittelt werden. Das ZGK-Segment wird lediglich zur Abwärtskompatibilität mit älteren eGK- und KVK-Schemaversionen beibehalten.

Im folgenden Profil sind alle gegenüber dem Dokument "gemeinsame Nachrichtenelemente" vorgenommenen Änderungen grau markiert.

Basis-Dokumente

Dieses Dokument benötigt folgende Dokumente:

  • gemeinsame Nachrichtenelemente (OID 2.16.840.1.113883.2.6.7.27)
  • Rahmendokument (OID 2.16.840.1.113883.2.6.7.26)
  • die entsprechenden ADT-Profil-Dokumente
  • HL7 v2.5 in der deutschen Fassung für eine vollständige Dokumentation

Dazu kommt dann noch das jeweilige Dokument zur Spezifikation des jeweiligen ADT-Profils.

Nachrichten

Nachrichtenfragment

Segmente Kard. Verwendung Beschreibung Kap.
MSH [1..1] R Message Header 2.15.9
...
OBX [1..1] R Observation
...

Dieses Segment kommt bspw. in folgenden Nachrichten vor:

  • A01
  • A02
  • A03
  • A04
  • A05
  • A06
  • A07
  • A08
  • A13
  • ...

Beispielspezifikation für A01

Segmente Kard. Verwendung Beschreibung Kapitel
MSH [1..1] R Message Header 2.15.9
[ { SFT } ] [0..1] C
(O)
Software Segment 2.15.12
EVN [1..1] R Event Type 3.4.1
PID [1..1] R Patient Identification 3.4.2
[ PD1 ] [0..0] X
(O)
Patient Additional Demographic 3.4.10
[ { ROL } ] [0..*] O Role 15.4.7
[ { NK1 } ] [0..*] O Next of Kin / Associated Parties 3.4.5
PV1 [1..1] R Patient Visit 3.4.3
[ PV2 ] [0..1] O Patient Visit – Additional Information 3.4.4
[ { ROL } ] [0..*] O Role 15.4.7
[ { DB1 } ] [0..0] X
(O)
Disability 3.4.11
[ { OBX } ] [1..*] O Observation/Result 7.4.2
[ { AL1 } ] [0..*] O Patient Allergy Information 3.4.6
[ { DG1 } ] [0..*] O Diagnosis 6.5.2
[ DRG ] [0..1] O Diagnosis Related Group 6.5.3
[{ [0..*] O --- PROCEDURE
PR1 [1..1] R Procedures 6.5.4
[ { ROL } ] [0..*] O Role 15.4.7
}]
[ { GT1 } ] [0..0] X
(O)
Guarantor 6.5.5
[{ [0..*] O --- INSURANCE
IN1 [1..1] R Insurance 6.5.6
[ IN2 ] [0..1] O Insurance Additional Information 6.5.7
[ { IN3 } ] [0..0] O Insurance Additional Information, Certification 6.5.8
[ { ROL } ] [0..*] O Role 15.4.7
}]
[ ACC ] [0..1] O Accident 6.5.9
[ UB1 ] [0..0] X
(O)
UB82 6.5.10
[ UB2 ] [0..0] X
(O)
UB92 Data 6.5.11
[ PDA ] [0..1] O Patient Death and Autopsy 3.4.12

Für andere Nachrichten sieht das dann entsprechend aus.

Segmente

Lfd. Nr. Beschreibung Kard. Verwendung Tab. Data Item DT Länge Kap.
1 Field Separator/ Feldtrennzeichen [1..1] R 00001 ST 1 2.15.9.1
2 Encoding Characters/ Weitere Trennzeichen [1..1] R 00002 ST 4 2.15.9.2
3 Sending Application/ Sendende Anwendung / Sendender Bereich [1..1] R 0361 00003 HD 2.15.9.3
4 Sending Facility/ Sendender Prozeß / Sendende Einrichtung innerhalb des Bereiches [1..1] R 0362 00004 HD 2.15.9.4
5 Receiving Application/ Empfangende Anwendung / Empfangender Bereich [1..1] R 0361 00005 HD 2.15.9.5
6 Receiving Facility/ Empfangender Prozeß / Empfangende Einrichtung innerhalb des Bereiches [1..1] R 0362 00006 HD 2.15.9.6
7 Date/Time Of Message/ Zeitpunkt Nachrichtenerstellung [1..1] R 00007 TS 2.15.9.7
8 Security/ Sicherheitsspezifikation [0..0] X 00008 ST 2.15.9.8
9 Message Type/ Nachrichtentyp und Ereigniscode [1..1] R 00009 MSG 2.15.9.9
10 Message Control ID/ Nachrichtenkontrollnummer [1..1] R 00010 ST 2.15.8.2
11 Processing ID/ Verarbeitungsmodus [1..1] R 00011 PT 2.15.9.11
12 Version ID/ HL7-Versionsnummer [1..1] R 00012 VID 2.15.9.12
13 Sequence Number/ Laufende Nummer [0..0] X 00013 NM 2.15.9.13
14 Continuation Pointer/ Fortsetzungszeiger [0..0] X 00014 ST 2.15.4.1
15 Accept Acknowledgment Type/ Bedingung für Empfangsbestätigung [1..1] R 0155 00015 ID 2.15.9.15
16 Application Acknowledgment Type/ Bedingung für Verarbeitungsbestätigung [1..1] R 0155 00016 ID 2.15.9.16
17 Country Code/ Ursprungsland der Nachricht [0..1] RE 0399 00017 ID 2.15.9.17
18 Character Set/ Zeichensatz [1..1] R 0211 00692 ID 2.15.9.18
19 Principal Language Of Message/ Sprache der Nachricht [0..1] RE 0296 00693 CE 2.15.9.19
20 Alternate Character Set Handling Scheme/ Verfahren zum Zeichensatzwechsel innerhalb der Nachricht [0..0] X 0356 01317 ID 2.15.9.20
21 Message Profile Identifier/ ID des Nachrichtenprofils [1..\*] R 01598 EI 2.15.9.21


MSH - Message Header

MSH-21 ID des Nachrichtenprofils

2.16.840.1.113883.2.6.9.74

OBX-Segment: Codes

Das OBX-Segment dient primär zur Übermittlung von Befunden und Beobachtungen, es kann aber auch dafür verwendet werden, Zusatzinformationen zu übermitteln. Die zu übermittelnden Informationen werden relativ generisch in einem Feld (OBX-5) eingetragen und über einen Code (OBX-3) kenntlich gemacht. Dadurch lassen sich über Wiederholungen alle möglichen Daten übermitteln.

Dieses Segment gehört zum Standardumfang von HL7 und wurde mit den verschiedenen Versionen weiterentwickelt. Für entsprechende Details ist auf die HTML-Dateien verwiesen. Für Profile gibt es eine separate Ausarbeitung.

Codes nach Profil

HL7v2 Profile für eGK-Daten


Codes in der Übersicht

Die nachfolgende Tabelle listet besondere Nutzungszwecke - bspw. für DRG - und die dazugehörigen Codes auf:

OBX-2 OBX-3 OBX-5 OBX-6
Inhalt Datentyp Code (als CNE) Wert Einheit(en) Tabelle Einsatzzweck Bemerkung
Portionsgröße CWE 4918 Küche
Kostart CWE 4919 Küche
Kostform CWE 4920 Küche
Körpergewicht NM 3141-9^Koerpergewicht^LN kg
g
LOINC DRG
Körpergröße NM 3137-7^Koerpergroesse^LN m
cm
LOINC DRG
Geburtsgewicht NM 8345-1^Koerpergewicht^LN g
kg
LOINC DRG
Geburtsgröße NM 8305-5^Koerpergroesse^LN cm LOINC DRG
Schwangerschaftswoche NM 11884-4^Gestationsalter^LN "/1" LOINC DRG
Tag der Wundheilung TS 30573-0^Tag der Wundheilung^LN <leer> LOINC DRG
Gruppengröße NM GRP-SIZE^Gruppengröße^HL7-DEU <leer> HL7-DEU Abrechnung (Leistung)
Anzahl der Mitarbeiter, die an einer Leistung beteiligt sind NM EMP-COUNT^Mitarbeiterzahl^HL7-DEU <leer> HL7-DEU Abrechnung (Leistung)
eGK-Daten ED EGK_DATA^eGK-Daten^HL7-DEU <leer> HL7-DEU Abrechnung (Leistung) Die Daten werden prinzipiell im Originalformat übertragen, jedoch in der NAchricht als Base64-kodierte Information repräsentiert.
eGK-Daten (Version 5.2) ED EGK_DATA52^eGK-Daten^HL7-DEU <leer> HL7-DEU Abrechnung (Leistung) Die Daten werden prinzipiell im Originalformat übertragen, jedoch in der NAchricht als Base64-kodierte Information repräsentiert.
KVK-Daten ED KVK_DATA^KVK-Daten^HL7-DEU <leer> HL7-DEU Abrechnung (Leistung) Die Daten werden prinzipiell im Originalformat übertragen, jedoch in der NAchricht als Base64-kodierte Information repräsentiert.
Photo des Patienten ED PHOTO <leer> Patientenphoto patient photo(Lvl: 1)
Photo des Patienten: Gesamtansicht ED PHOTO_FULL <leer> Patientenphoto patient photo: full (Lvl: 2)
Photo des Patienten: Oberkörper ED PHOTO_UPPER <leer> Patientenphoto patient photo: upper body (Lvl: 2)
Photo des Patienten: Kopf ED PHOTO_HEAD <leer> Patientenphoto patient photo: head (Lvl: 2)
Photo des Patienten: Kopf/Gesicht von vorne ED PHOTO_HEAD_FRONTAL <leer> Patientenphoto patient photo: head/face frontal (Lvl: 3)
Photo des Patienten: Kopf/Gesicht mit Brille ED PHOTO_HEAD_FRONTAL_W <leer> Patientenphoto patient photo: head/face frontal with glasses (Lvl: 4)
Photo des Patienten: Kopf/Gesicht ohne Brille ED PHOTO_HEAD_FRONTAL_WO <leer> Patientenphoto patient photo: head/face frontal without glasses (Lvl: 4)
Photo des Patienten: Kopf/Gesicht von links ED PHOTO_HEAD_LEFT <leer> Patientenphoto patient photo: head/face left side (Lvl: 3)
Photo des Patienten: Kopf/Gesicht von rechts ED PHOTO_HEAD_RIGHT <leer> Patientenphoto patient photo: head/face right side (Lvl: 3)


Dieses Segment kann so dann bspw. auch in ADT-Nachrichten u.ä. eingesetzt werden.

Beispiel für die Verwendung des OBX-Segmentes zum Transport von eGK-Daten

OBX|1|ED|EGK_DATA52^eGK-Daten^HL7-DEU||^AP^application/xml^Base64^<Hier kommt der codierte Datensatz...>

oder

OBX|1|ED|EGK_DATA52^eGK-Daten^HL7-DEU||^AP^application/gzip^Base64^<Hier kommt der gezippte und codierte Datensatz...>

Detaillierte Änderungshistorie

Version Änderungen gegenüber Vorversion
0.1 Erstellung