Ringholm-Logo Ringholm  Whitepaper Ringholm page header
Schulungen    Dienstleistungen   |   Whitepaper    Blog    Events    Links   |   Über uns    Partner    Kunden    Kontakt    Impressum

Neuerungen in der Version 2.6

Copyright Ringholm bv © 2006,2008. All Rights Reserved.
Unter http://www.ringholm.com/docs/00720_de.htm können Sie die letzte Version dieses Dokumentes finden.
Author: Frank Oemig - Associated Sr.Consultant, Ringholm bv
Status dieses Dokumentes: Final, Version 1.0 (2007-01-16)  
Senden Sie Fragen und Kommentare an frank@oemig.de.


Zusammenfassung

Im April 2007 würde die neue Version 2.6 freigegeben. Neben neuen Ereignissen, Segmenten und Feldern sind sowohl neue Szenarien in Form zweier neuer Kapitel (16 + 17) als auch internationale Belange berücksichtigt worden.

Die Unterschiede zwischen den Versionen 2.5 und 2.6 sind relativ klein. Wichtig sind

  • die separate Definition der Nachrichtenprifle, die jetzt in das Kaptiel 2B ausgelagert worden sind,
  • Veränderungen in den Basisdatentypen TS und CE,
  • optionales UAC-Segment in allen Nachrichten,
  • neue Segmente und Felder für die Übermittlung von DRG-relevanten Informationen,
  • "Mood-Code" in einigen Segmenten und
  • die beiden neue Kapitel.

Außerdem fließen die Erfahrungen aus der Spezifikation der Version 3.0 in die 2.x-Versionen mit ein. Daher ist diese Version - mal wieder - die beste und vollständigste aus der 2.x-Serie.

1. Einleitung

Die nachfolgende Grafik zeigt sehr deutlich, daß die Anzahl an allem erhöht worden ist. Der Standard nimmt weiter an Umfang zu. Dies sieht man sehr deutlich an der Anzahl der Ereignisse (>300) und der Anzahl der Datenelemente (>2000):

eine kleine Statistik

Umgekehrt kann man aus der Grafik aber auch ablesen, dass insgesamt eine Harmonisierung durchgeführt wurde. Obwohl es mehr Ereignisse gibt, ist doch die Zahl der Nachrichten nicht so stark gestiegen. Die direkt über Events definierten Nachrichten haben stark abgenommen.

 

2. Datentypen

Die wohl markantesten Veränderungen im Kapitel der Datentypen ist die Abschaffung des Datentyps CE, der dann durch CNE und CWE ersetzt wird. Hier wird noch darüber diskutiert, welche Eigenschaften diese beiden Datentypen auszeichnen.

Darüber hinaus hat sich die Übertragung der Längeninformationen aus dem Kapitel 2A in die einzelnen Chapter durchgesetzt, d.h. die verschiedenen Anwendungsgebiete haben die vorgeschlagenen Längenangaben übernommen. Da es sich bei der Länge zwar offiziell um einen Maximalwert handelt, man aber individuell etwas anderes vereinbaren kann und in Deutschland dieser Wert nur als Empfehlung gehandhabt wird, dürfte sich diese Spalte in der Attributtabelle möglicherweise in der Version 2.7 erübrigen.
Unterstützt wird diese Vermutung durch bereits getroffene Entscheidungen, wo die Längenangabe ganz aus der Attributetabelle verschwinden wird. Die Länge wird dann nur noch Bestandteil von Profilen sein und damit in der Verantwortung der Hersteller liegen.

Abschaffung des CE-Datentyps

Wie schon einleitend erwähnt wird ab v2.6 der Datentyp CE nicht mehr verwendet. Die einzelnen HL7 technischen Kommittees hatten darüber zu befinden, ob die bisherigen Felder nun den Datentyp CNE oder CWE bekommen!

CNE vs. CWE?

In den Grundzügen, d.h. in den ersten 6 Komponenten, sind die drei Datentypen CE, CNE und CWE identisch. Erst danach unterscheiden sie sich:

CNE - Coded with no exceptions

Das wichtigste Unterscheidungsmerkmal auf Komponentenebene ist die Verpflichtung, die erste Komponente zu füllen:

SEQ LEN DT OPT TBL# COMPONENT NAME SEC. REF.
120STR Identifier2.A.74
2199STO Text2.A.74
320IDO0396Name of Coding System2.A.35
420STO Alternate Identifier2.A.74
5199STO Alternate Text2.A.74
620IDO0396Name of Alternate Coding System2.A.35
710STC Coding System Version ID2.A.74
810STO Alternate Coding System Version ID2.A.74
9199STO Original Text 2.A.74

Darüber hinaus gibt es noch in der textuellen Erläuterung einen "kleinen" Unterschied:

Definition: Specifies a coded element and its associated detail. The CNE data type is used when a required or mandatory coded field is needed. The specified HL7 table or imported or externally defined coding system must be used and may not be extended with local values. Text may not replace the code. A CNE field must have an HL7 defined or external table associated with it. A CNE field may be context sensitive such that a choice of explicit coding systems might be designated. This allows for realm and other types of specificity. Every effort will be made to enumerate the valid coding system(s) to be specified in the 3rd component, however, the standards body realizes that this is impossible to fully enumerate.

Der Datentyp CNE darf nur genutzt werden, wenn es sich nicht um eine "user-defined Table" handelt. Dabei kommt es darauf an, dass die Tabelle im voraus bekannt ist und nicht erweitert werden kann/darf!

CWE - Coded with Exceptions

Hier nun die Spezifikation für CWE:

SEQ LEN DT OPT TBL# COMPONENT NAME SEC. REF.
120STO Identifier2.A.74
2199STO Text2.A.74
320IDO0396Name of Coding System2.A.35
420STO Alternate Identifier2.A.74
5199STO Alternate Text2.A.74
620IDO0396Name of Alternate Coding System2.A.35
710STC Coding System Version ID2.A.74
810STO Alternate Coding System Version ID 2.A.74
9199STO Original Text2.A.74

Zeitpunkt: neuer Datentyp DTM als Ablösung von TS

In den bisherigen Versionen des Standards hat sich wohl niemand um die korrekte Handhabung des Datentyps "TS" bemüht. Genaugenommen besteht - oder bestand - dieser aus 2 Komponenten, wobei die 2. Komponente eine Angabe über die Genauigkeit machen sollte. Damit konnte die 1. Komponente mit "beliebig" vielen Ziffern gefüllt werden, denn in der zweiten Stand dann, wie viele davon gültig waren. Beispielsweise war der Zeitpunkt bis auf die Sekunde genau angegeben, jedoch sollte der Wert nur bis auf den Tag genau ausgewertet werden.

Diese Vorgabe wurde in der Praxis jedoch nicht umgesetzt. Vielmehr wissen die meisten Hersteller nicht einmal um die Existenz dieser zweiten Komponente. Für die Erweiterung des Standards hat diese "unnütze" Komponente jedoch Probleme bereitet, da auf der zweiten Datentyp-Ebene TS nicht genutzt werden konnte, da es keinen "Sub-Sub-Komponententrenner" gibt.

Der neue Datentype "DTM" ersetzt nun durchgängig den bisherigen "TS". Die Definition ist gleich geblieben, nur fehlt jetzt die 2. Komponente.

ED-Datentyp

Dieser Datentyp enthält folgende Komponenten:

SEQ LEN DT OPT TBL# COMPONENT NAME SEC. REF.
11027HDO Source Application2.A.33
211IDR0834Type of Data2.A.35
332IDO0291Data Subtype2.A.35
46IDR0299Encoding2.A.35
565536TXR Data2.A.78

Die zugeordneten Tabellen sind dabei neu organisiert worden:

Imported Table 0834 - MIME Types

Diese Tabelle ist neu und lehnt sich im Wesentlichen an die aus dem WWW bekannten Kürzel an:

Value Description Comment
applicationApplication data 
audioAudio data 
imageImage data 
modelModel dataRFC 2077
textText data  
videoVideo data 
multipartMIME multipart package 

HL7 Table 0191 - Type of referenced data

Diese Tabelle wird nur noch wg. "Backward Compatibility" weitergeführt:

Value Description Comment
APOther application data, typically uninterpreted binary data (HL7 V2.3 and later)  
AUAudio data (HL7 V2.3 and later)  
FTFormatted text (HL7 V2.2 only)  
IMImage data (HL7 V2.3 and later)  
multipartMIME multipart package  
NSNon-scanned image (HL7 V2.2 only)  
SDScanned document (HL7 V2.2 only)  
SIScanned image (HL7 V2.2 only)  
TEXTMachine readable text document (HL7 V2.3.1 and later)  
TXMachine readable text document (HL7 V2.2 only)  

HL7 External Table 0291 - Subtype of referenced data

Diese Tabelle enthielt früher eine Reihe von Einträgen, von denen nur noch einer übrig geblieben ist:

Value Description Comment
x-hl7-cda-level-oneHL7 Clinical Document Architecture Level One documentRetained for backwards compatibility only as of v2.6 and CDA R 2. Preferred value is text/xml.

3. UAC-Segment

In der vorhergehenden Version des Standards wurde schon das SFT-Segment (Software) in alle Nachrichten eingebaut. In dieser Version ist es das UAC-Segment User Authentication Credential Segment), das Informationen über den Benutzer transportiert. In diesem Segment werden bspw. Kerberos-Tickets zur End-User-Identifikation in einem ED-Feld übertragen.

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME
14CWER 061502267User Authentication Credential Type Code
265536EDR  02268User Authentication Credential

4. sich wiederholende Elemente

Bisher hat es bei sich wiederholenden Elementen (Segmente oder Felder) Schwierigkeiten gegeben, wie das in Update-Nachrichten zu interpretieren ist ? insbesondere wenn Teile einer Nachricht fehlen. Hier gibt es jetzt anhand von Beispielen Klarheit.

5. Conformance: Nachrichtenprofile

Die bisherigen Nachrichtenprofile werden um Informationen über das genutzte Vokabular erweitert. "Annotations" erlauben ebenfalls weitere Informationen in einem Nachrichtenprofil anzugeben. Außerdem können über einen Pattern-Matching-Mechanismus zu den einzelnen Elementen über die Object Constraint Language (OCL), reguläre Ausdrücke (RegEx) oder XPath-Angaben weitere Einschränkungen definiert werden. Über den gleichen Mechanismus können verschiedene Elemente auch in Beziehung zueinander gesetzt werden.

6. Patient Administration

PA hat ebenfalls in allen Nachrichten ein neues Segment eingeführt.

  • ARV - Access Restriction

Damit kann sowohl auf Personen/Patienten- als auch auf Fallebene Zugangs-/Auskunftsbeschränkunge definiert werden.

7. DRG-relevante Informationen

Im Zuge der DRG-Abrechnung sollten für alle Informationen, die benötigt werden, Felder in den entsprechenden Segmenten bereitgestellt werden. Dazu sind die vorhandenen Segmente erweitert worden. Darüber hinaus ist noch ein Segment für die Stammdaten hinzugekommen.

In den hier genannten Segmenten sind nur die neuen Felder aufgelistet.

DRG-Segment

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME
121103XPNO  02156Name of Coder
13705CWEO 073402157Grouper Status
1420CWEO 072802158PCCL Value Code
155NMO  02159Effective Weight
1620MOO  02160Monetary Amount
1720ISO 073902161Status Patient
18100STO  02162Grouper Software Name and Version
1920ISO 074202163Status Financial Calculation
2020MOO  02164Relative Discount/Surcharge
2120MOO  02165Basic Charge
2220MOO   02166Total Charge
2320MOO  02167Discount/Surcharge
245NMO  02168Calculated Days
2520ISO 074902169Status Gender
2620ISO 074902170Status Age
2720ISO 074902171Status Length of Stay
2820ISO 074902172Status Same Day Flag
2920ISO 074902173Status Separation Mode
3020ISO 075502174Status Weight at Birth
3120ISO 075702175Status Respiration Minutes
3220ISO 075902176Status Admission

DG1-Segment

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME
22427EIC  02152Parent Diagnosis
23705CWEO 072802153DRG CCL Value Code
2420ISO 013602154DRG Grouping Usage
2520ISO 073102155DRG Diagnosis Determination Status

Das erste neue Feld "Parent Diagnosis" dient der Verlinkung auf die "übergeordnete" Diagnose. Hiermit kann die Kreuz-/Stern-Notation realisiert werden.

Durch das neue REL-Segment ist dieses Feld aber schon überflüssig geworden.

Die restlichen Feldern dienen den ermittelten diagnosebezogenen DRG-Werten.

PR1-Segment

Status
SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME
2120ISO 076102177DRG Procedure Determination Status
2220ISO 076302178DRG Procedure Relevance

Diese beiden neuen Felder dienen ausschließlich den prozedurbezogenen DRG-Informationen.

Master-Files

Die Stammdaten zu den DRGs werden mit dem neuen Ereignis M17 kommuniziert.

DMI - DRG Master File Information

Zu jedem DRG-Code gibt es ein paar Informationen, die statisch dazugehören und deshalb nicht in den normalen Nachrichten mit ausgetauscht werden. Diese Felder sind in diesem neuen Segment untergebracht.

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME
1250CNEO 005500382Diagnostic Related Group
21CNEC 083000381Major Diagnostic Category
37NRC  02231Lower and Upper Trim Points
45NMC  02232Average Length of Stay
57NMC  02233Relative Weight

8. "Mood-Code"

Ein ganz neues Konstrukt in der v2-Familie ist der Mood-Code. Denjenigen, die sich mit V3 auskennen, ist dieser Wert ein Begriff:

INT Intent
APT Appointment
ARQ Appointment Request
PRMS Promise
PRP Proposal
RQO Request-Order
EVN Event
EVN.CRT Event Criterion
EXP Expectation

Dieses Feld wird in den Segmenten OBX, RXO, PRB, GOL, PTH und PRD eingeführt.

Auf den ersten Blick erscheint dieses Feld problematisch. Auf den zweiten Blick ist es das auch, da damit in bestehenden Nachrichten die Intention verändert werden kann, wenn man dieses Feld nicht korrekt auswertet. Deshalb darf dieses Feld nur in neuen Nachrichten verwendet werden.

Der Grund, um dieses Feld überhaupt aufzunehmen, liegt in der Problematik von Einweisungen (REF-Messages). Hier müssen Informationen in unterschiedlicher Laune ("Mood") kommuniziert werden. Darunter ist bspw. die Unterscheidung zwischen einem Benachrichtigung, Versprechen und Absicht zu verstehen.

9. Order Entry/Result Reporting

Im Laborbereich gibt es zwei neue Nachrichten:

  • O37: OPL - Population/Location-Based Laboratory Order Message
  • O38: OPR - Population/Location-Based Laboratory Order Acknowledgment Message

Die Struktur dieser Nachrichten zielt auf den Einsatz im Veterinärmedizinbereich ab. Nicht unerwähnt bleiben soll die Übersichtstabelle zu den Order Control Codes, damit man relativ leicht ersehen kann, welcher Code in welcher Nachricht genutzt werden darf.

9. Query

Eine kleinere aber längst überfällige Neuerung ist die Umbenennung der falsche Bezeichnung "Conformance Statement" in "Query Profile" um die richtige Intention wiederzugeben. Desweiteren werden eine Reihe von Nachrichten aus dem Standard entfernt:

  • EQQ - embedded query language query
  • RQQ - event replay query
  • SPQ - stored procedure request
  • VQQ - Virtual Table query

10. Observations

Auch im OBX-Segment wird ein Mood Code eingeführt. Allerdings darf dieses Feld aus Kompatibilitätsgründen in bereits genutzten Nachrichten nicht verwendet werden. In einigen Nachrichten wird das ROL-Segment eingeführt, um bei Befunden weitere Ärzte zuordnen zu können.

Des weiteren gibt es eine neue Nachricht:

  • R25: OPU - Unsolicited Population/Location-Based Laboratory Observation Message

Diese Nachricht übermittelt die Befunde zu den neuen Aufträgen aus Kapitel 4.

11. Patient Care

Neben der Einführung des "Mood Codes" in den Segmenten GOL, PTH und PRB ist das neue Segment REL für "Relationship" erwähnenswert. Dieses Segment erlaubt die Verlinkung zwischen Entitäten innerhalb und außerhalb der Nachricht. Bei Entitäten ist hier an Diagnosen, Prozeduren, und Befunden gedacht. Außerdem kann hier die Art der Beziehung direkt mit angegeben werden. Beispielsweise ist eine Diagnose durch einen entsprechenden Befund begründet oder eine Komplikation steht in einem direkten kausalen Zusammenhang mit einer Maßnahme.

Allerdings wird dieses Segment noch in keiner Nachricht verwendet. Es wurde von den Australiern eingebracht, um für Überweisungsnachrichten die Menge an zu übermittelnden Daten zu reduzieren.

12. REL-Segment

Ein Segment ganz anderer Art ist das neue REL-Segment. Es wird zwar noch in keiner Nachricht genutzt, wird aber schon von den Australiern genutzt, um die für Einweisungen notwendigen Daten zu reduzieren. Dieses Segment dient dazu, beliebige Segmente und externe Objekte miteinander in Beziehung zu setzen. Die nachfolgende Segmentbeschreibung ist die Mischung aus der aktuellen Beschreibung gemäß Kapitel 12 (Patient Care) und der aufgrund negativer Kommentare notwendiger Ballot Reconciliation:

SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME Kommentar
14SIC  02240Set ID - REL
2705CWER  02241Relationship Type
360EIR  02242This Relationship Instance Identifier
460EIR  02243Source Information Instance Identifierneu: Source Object ID
560EIR  02244Target Information Instance Identifierneu: Target Object ID
SI/NMR  ????? neu: Source Set ID
SI/NMR  ????? neu: Target Set ID
660EIO  02245Asserting Entity Instance ID
7250XCNO  02246Asserting Person
8250XCNO  02247Asserting Organization
9250XADO  02248 Assertor Address
10250XTNO  02249 Assertor Contact
1153DRO  02250Assertion Date Range
121IDO 013602251Negation Indicator
13705CWEO  02252Certainty
1426NMO  02253Priority No ( relative ordering, workflow: plans etc)
15250NMO  02254Priority Sequence No ( rel preference for consideration)
161IDO 013602255 Separability Indicator

Dieses Segment ist noch nicht endgültig. Vermutlich werden bereits festgelegte Attribute wieder aus dem Kapitel entfernt, um sich nicht zu weit festzulegen.

Offen ist auch noch, ob tatsächlich jeweils zwei Source/Target-Informationen angegeben werden müssen, oder ob man das nicht auf die Object-ID reduzieren kann. Es würde reichen, wenn man die externen Objekte eindeutig identifizert und dann nur noch diese externen IDs kommuniziert.

13. Claims and Reimbursement

Dieses neue Kapitel 16 basiert zum großen Teil auf NeCST, dem "National eClaims Standard" aus Kanada. Das Ziel ist Rechnungsinformationen zu übertragen. (In den USA steht für die Rechnungsinformationen X.12 zur Verfügung.) Damit dieses Kapitel auch in anderen Ländern anwendbar ist, wurden die Nachrichten und Segmente um Anforderungen aus Deutschland, der Schweiz und Argentinien erweitert. Damit ist es bspw. geeignet, um die für §301 SGB V notwendigen Daten zu transportieren.

Folgende Events werden neu definiert:

  • E01: Submit Health Services Invoice
  • E02: Cancel Health Services Invoice
  • E03: Query Health Services Invoice Status
  • E04: Re-Assess HealthCare Services Invoice
  • E10: Edit/Adjudication Results
  • E12: Request Additional Information
  • E13: Additional Information Response
  • E15: Payment/Remittance Advice
  • E20: Submit Authorization Request
  • E21: Cancel Authorization Request
  • E22: Query Authorization Request
  • E24: Authorization Response
  • E45: Query Eligibility

Zur Realisierung der o.g. Nachrichten sind eine Reihe von neuen Segmenten notwendig:

  • ADJ - Adjustment
  • IPR - Invoice Processing Results
  • IVC - Invoice Segment
  • PMT - Payment Information
  • PSS - Product/Service Section
  • PSG - Product/Service Group
  • PSL - Product/Service Line Item
  • PYE - Payee Information
  • RTI - Request for Information

14. Materials Management

Das neue Kapitel 17 beschäftigt sich mit der Handhabung von Material. Dazu gibt es zwei neue Domänen:

  • Inventory Item Master Updates
  • Sterilization and Decontamination

Inventory Item Master Updates

Neue Segmente für "Inventory Item Master":

  • IIM - INVENTORY ITEM MASTER SEGMENT
  • ITM - MATERIAL ITEM SEGMENT
  • STZ - STERILIZATION PARAMETER SEGMENT
  • VND - PURCHASING VENDOR SEGMENT
  • PKG - PACKAGING SEGMENT
  • PCE - PATIENT CHARGE COST CENTER EXCEPTION
  • IVT - MATERIAL LOCATION SEGMENT
  • ILT - MATERIAL LOT SEGMENT

Placer Request:

  • SLR/SLS - REQUEST NEW STERILIZATION LOT (EVENT S28)
  • SLR/SLS - REQUEST STERILIZATION LOT DELETION (EVENT S29)
  • STI/STS - REQUEST ITEM (EVENT S30)
  • SDR/SDS - REQUEST ANTI-MICROBIAL DEVICE DATA (EVENT S31)
  • SMD/SMS - REQUEST ANTI-MICROBIAL DEVICE CYCLE DATA (EVENT S32)

Filler Request:

  • STC/ACK - NOTIFICATION OF STERILIZATION CONFIGURATION (EVENT S33)
  • SLN/ACK - NOTIFICATION OF NEW STERILIZATION LOT (EVENT S34)
  • SLN/ACK - NOTIFICATION OF STERILIZATION LOT DELETION (EVENT S35)
  • SDN/ACK - NOTIFICATION OF ANTI-MICROBIAL DEVICE DATA (EVENT S36)
  • SCN/ACK - NOTIFICATION OF ANTI-MICROBIAL DEVICE CYCLE DATA (EVENT S37)

Sterilization and Decontamination

Neue Segmente für "Sterilization and Decontamination":

  • SCP - STERILIZER CONFIGURATION SEGMENT
  • SLT - STERILIZATION LOT SEGMENT
  • SDD - STERILIZATION DEVICE DATA SEGMENT
  • SCD - ANTI-MICROBIAL CYCLE DATA SEGMENT

15. Ausblick auf 2.7

Version 2.6 ist noch nicht endgültig verabschiedet, und trotzdem gibt es schon Vorschläge für 2.7. Abgesehen von der Tatsache, dass im Vorstand die Entscheidung für 2.7 bereits gefallen ist, kann als radikalste Änderung der Umgang mit den Längeninformationen erwartet werden.

16. Referenzen

[HL7] "HL7", 2007, http://www.hl7.org/, Version 2.6.


Über Ringholm bv

Die Ringholm bv basiert auf einem Zusammenschluß von europaweit anerkannten Experten auf dem Gebiet der Systemintegration von IT-Systemen im Gesundheitswesen. Ringholm bietet Schulungen und Beratung im Bereich der Schnittstellenstandards und -technologien.
Für mehr Informationen besuchen Sie http://www.ringholm.com oder rufen Sie uns an unter +31 33 7 630 636.