deutsche Nachrichtenprofile: eGK-Daten im Originalformat
K (→Einleitung) |
(Einleitung ausformuliert und verlinkt) |
||
Zeile 26: | Zeile 26: | ||
{{Infobox Contributors Begin}} | {{Infobox Contributors Begin}} | ||
{{Contributor | Logo = Logo-Agfa.jpg | Name = Agfa HealthCare GmbH | Location = Bonn }} | {{Contributor | Logo = Logo-Agfa.jpg | Name = Agfa HealthCare GmbH | Location = Bonn }} | ||
− | {{Contributor | Logo = | + | {{Contributor | Logo = Logo_Health-comm.jpg | Name = Health-Comm GmbH | Location = München }} |
{{Infobox Contributors End}} | {{Infobox Contributors End}} | ||
Zeile 99: | Zeile 99: | ||
=Einleitung= | =Einleitung= | ||
− | Es gibt zwei Möglichkeiten, eGK-Daten zu übermitteln | + | Es gibt zwei Möglichkeiten, eGK-Daten zu übermitteln: |
+ | * in strukturierter Form mittels der INx-Segmente in Kombination mit dem [[Segment ZGK|ZGK-Segment]] <br/> | ||
+ | (siehe Profilkomponente ([[HL7v2-Profile_Kostenträger]]) | ||
+ | * im Originalformat (XML) mit dem [[Segment OBX|OBX-Segmentes]]<br/> | ||
− | + | Ein Großteil der Daten auf der Gesundheitskarte kann in Felder des IN1-Segmentes gemapped werden. | |
+ | (Siehe [[Spezifikation eGK-Daten]]) <br/> | ||
+ | Zur Übermittlung der verbleibenden Daten auf der KVK wurde das Z-Segment [[Segment ZGK|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 [[Segment OBX (Codes)#Beispiel für die Verwendung des OBX-Segmentes zum Transport von eGK-Daten|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== | ==Basis-Dokumente== |
Version vom 6. November 2014, 17:57 Uhr
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 Sheckmann (talk| contribs) 10 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 Sheckmann (talk| contribs) 10 years ago. (Purge) |
Dieses Dokument gibt wieder:
Nachrichtenprofile deutsche Nachrichtenprofile: eGK-Daten im Originalformat (01). Die Teilmaterialien gehören der Kategorie v2profile an. |
HL7-Deutschland
Abstimmungsdokument | |||
---|---|---|---|
Version | Datum | Status | Realm |
01 | 6.11.2014 | in Arbeit | Deutschland |
noch kein download verfügbar |
Kontributoren | ||
---|---|---|
Agfa HealthCare GmbH | Bonn | |
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
Inhaltsverzeichnis
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
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.
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)
- im Originalformat (XML) mit dem OBX-Segmentes
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
Dieses Nachrichtenfragment kann grundsätzlich in allen Nachrichten in gleicher Art eingesetzt werden, da die eGK-Daten optional und wiederholbar im OBX-Segment sind. |
This message fragment can be used in all messages of the same type, because the eGK data information is optionally repeating conveyed in the OBX segment in all ADT messages. |
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
Wenn das OBX Segment bspw. in einer Aufnahmenachricht verwendet wird, dann müsste die entsprechende Spezifikation in etwa so aussehen. Die Veränderungen gegenüber dem Aufnahme-Profil sind markiert: |
If the OBX segment is used in an ADT message, then the according specification should look like following. The changes compared to the admission message profile are marked: |
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
Segment OBX being relevant for this profile is specified already in the document "common message elements". |
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
Das Segment MSH wird am Anfang jeder Nachricht verwendet. |
The MSH segment ist used at the beginning of each message. |
MSH-21 ID des Nachrichtenprofils
In diesem Feld wird die Kennung für dieses Nachrichtenprofil übermittelt: |
This field contains the identification for this message profile: |
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
Hier muss ein Transclude der Sektion HL7v2-Profile_eGK-Daten#OBX-3 Bezeichnung der Untersuchung rein |
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...>
Bei der Verwendung des OBX-Segmentes zur Übermittlung der eGK-Daten sollten die im Datensatz enthaltenen Kostenträgerinformationen stets auch in einem IN1-Segment übermittelt werden. Das Mapping der eGK-Daten nach IN1 befindet sich hier. |
Detaillierte Änderungshistorie
Version | Änderungen gegenüber Vorversion |
---|---|
0.1 | Erstellung |