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

HL7 Anfragenachrichten,
der nächste Schritt der Systemintegration in Deutschland ?

Copyright Ringholm bv © 2002,2010. All Rights Reserved.
Unter http://www.ringholm.com/docs/00300_de.htm finden Sie die neuste Version dieses Dokumentes.
Author: René Spronk - Sr.Consultant, Ringholm bv
Status des Dokuments: Final, Version 1.2 (2008-02-27)
Schicken Sie bitte Fragen und Kommentare an Rene.Spronk@Ringholm.com.


Zusammenfassung

Die Integration in deutschen Krankenhäusern hat einen Stand erreicht, wo HL7 version 2 weitestgehend als Standard zur Integration von Applikationen innerhalb einer Organisation anerkannt ist. Die meisten Organisationen benutzen Nachrichten, um demographische Patientendaten, Laborbefunde und Leistungen von einem System zum anderen zu schicken. Auftragskommunikation und Anfragen kommen typischerweise erst danach.

In Deutschland gibt es derzeit keine bekannte Schnittstelle für Anfragen einschließlich Antwort rein auf HL7 basierend.

Dieses Dokument beschreibt den Frage-Antwort-Mechanismus im allgemeinen und die Hauptkategorien von Anfragenachrichten, so wie sie international benutzt werden. Die Fähigkeiten des SAP Exchange Infrastructure werden als Beispiel beschrieben, wie so ein Anfrage-Mechanismus genutzt werden kann. Eine detaillierte Beschreibung von zwei Anfragenachrichten ist im Anhang A zu finden.

1. Einleitung

Eine auf Nachrichten basierende Systemintegration besteht aus dem einfachen Austausch von Nachrichten zwischen zwei Applikationen: das unaufgeforderte Update und das dazugehörige Acknowledgement bzw. die Anfrage und die Antwort dazu. Das darunterliegende operationale Modell entspricht dem von Client/Server. Über 95% aller Interaktionen sind unaufgeforderte Updates basierend auf klinischen oder administrativen Ereignissen, die in der sendenden Applikation dokumentiert sind. Der Anfrage-Mechanismus wird durch den Client durch das Absenden der Anfrage (eine Anforderung von Daten) an den Server initiiert. Der Server verarbeitet die Anfrage, antwortet direkt mit einer Angabe von Erfolg oder Mißerfolg der Anfrage durch den Client und später durch die Übermittlung der angeforderten Informationen.

Die Daten in dem unaufgeforderten Update sind nicht auf die Anforderungen einer bestimmten Empfängerapplikation zugeschnitten. Typischerweise wird ein Großteil der Daten an alle Systeme versendet, die die Informationen - oder nicht - brauchen.

Der Anfrage-Mechanismus wird eingesetzt, wenn es einen Bedarf an bestimmten Daten für einen Clienten gibt, wobei der Umfang durch die Anfrage bestimmt wird (bspw. zu einem bestimmten Patienten oder für einen bestimmten Zeitraum).

Ein typisches Beispiel, warum eine Applikation Bedarf an Anfragen hat, ist eine spezialisierte Applikation wie sie bspw. in der Strahlentherapie eingesetzt wird. Diese Anwendung muß demographische Patientendaten importieren, die in dem Patientendadministrationssystem (KIS) vor der Aufnahme in der Strahlentherapie eingegeben worden sind. Es ist unpraktisch, den Benutzer zur erneuten Eingabe zu zwingen. Da die Menge der Patienten in der Strahlentherapie nur eine kleiner Untermenge aller Patienten ist, ist es ebenfalls unpraktisch, die Daten aller Patienten in der Datenbank zu speichern. Die beste Lösung in diesem Fall ist für die Applikation in der Strahlentherapie eine Anfrage an das KIS zu schicken und nach allen demographischen Daten zu einen bestimmten Patienten zu fragen.

Nachfolgend ein paar typische Beispiele für Anfragen:

  • Daten zu einem einzigen Patienten, bspw. alle demographischen Daten oder Laborbefunde zu Patient #123456
  • Daten zu mehreren Patienten, bspw. eine Liste aller Patienten, die von Doktor #123 aufgenommen wurden
  • Daten ohne Patientenbezug, bspw. einen Belegungsstatus aller Betten auf Station #INT-1
  • Daten zu einem bestimmten Zeitraum, bspw. Glukose-Ergebnisse vom 1.1.01 bis zum 31.12.01 zu Patient #123456

Auf HL7 basierende Anfragenachrichten werden in den USA, U.K. und den Benelux-Staten vielfach genutzt - hauptsächlich für demographische Daten und Laborbefunde.

In Deutschland gibt es keine bekannten Implementierungen von Schnittstellen für Anfragen.


2. Die Nutzung von Anfragen

Basierend auf der Nutzung von Anfragenachrichten weltweit, dem Status der Systemintegration im deutschen Markt und den Anforderungen im Gesundheitssektor sind die Hauptkandidaten für Anfragen in Deutschland:

1. Demographische Patientdaten

Eine Applikation hat Bedarf an demographischen Daten über einen bestimmten Patienten und sendet eine Anfrage an das System, das diese Informationen hat.

Für demopgraphische Daten ist das KIS wahrscheinlich der "Eigentümer" der Daten. In einer Region, in der ein Patient mehrere Identifikatoren hat, sammelt der Master Patient Index (MPI) die demographischen Basisdaten. Diese enthalten Name, Adresse, Geburtsdatum, Geschlecht, Hausarzt und vielleicht auch den Ort (wenn erhoben), den aufnehmenden Arzt, Diagnosen und Versicherungsinformationen.

2. Befunde (Laborergebnisse)

Eine Anwendung fragt das Laborsystem nach bestimmten Laborergebnissen, um dem Anwender zusätzliche klinische Informationen zur Verfügung zu stellen.

Befunde können von allen Abteilungen erzeugt werden, bspw. Labor, Radiologie und Pathologie. Die Befunde können strukturierte Daten und textuelle Berichte enthalten.

3. Diagnosen/Prozeduren

Wenn Diagnosen/Befunde bezogen auf dieselbe Behandlungsepisode in mehreren Applikationen eingegeben werden, können Anfragen dazu verwendet werden, um eine komplette Liste aller Diagnosen/Prozeduren zu erhalten.

Es gibt zwei Szenarien, wo Anfragen nützlich sind: Das KIS fragt ein Subsystem nach Diagnosen/Prozeduren, die dort eingegeben wurden, um im KIS die Codes zu Abrechnungszwecken zusammenzuführen (und zu "optimieren"). Und ein Subsystem fragt im KIS nach Diagnosen, um dem Anwender zusätzliche klinische Informationen zur Verfügung zu stellen.

4. Bettenbelegung

In Krankenhäusern, in denen die Anwendung zur Steuerung einer Telekommunikationsanlage den Aufenthaltsort des Patienten innerhalb der Organisation verfolgt und daher die aktuellste und verläßlichste Information über die Bettenbelegung hat, kann ein System durch eine entsprechende Anfrage an diese Anwendung seine Daten aktualisieren.

Einige TK-Anlagen verfolgen den Aufenthaltsort aller Patienten, um dem Patienten die Nutzung einer bestimmten Durchwahl unabhängig von ihrem Aufenthalts zu ermöglichen. Die Patienten bekommen eine PIN-Nummer für das Telefon; die angefallenen Kosten werden dann nach der Entlassung abgerechnet. Die Qualität der Daten über den Aufenthaltsort von Patienten ist in der TK-Anlage oft besser als im KIS.

5. Kostenübernahmezusage

Wenn die Kostenübernahmezusage eines Patienten unklar ist, kann ein Krankenhaus eine Anfrage an den öffentlichen oder privaten Versicherer schicken.

Diese Anfrage dient der Überprüfung, ob ein Patient eine Kostenübernahme, d.h. eine Versicherungspolice, zu einem bestimmten Zeitpunkt hat. Der Zweck dieser Anfrage dient der Bestimmung des Umfangs, den die Versicherung abdeckt, d.h. der Leistungen, die der Patient bekommt.

6. Planungsinformationen

Wenn jemand Informationen über Zeitpläne, Termine und verfügbare Ressourcen haben möchte, veranlaßt er, dass die Applikation eine Anfrage an das System schickt, das diese Informationen verwaltet.

Die Informationen, die das anfragende System erhält, können zur Erzeugung von Arbeitslisten oder als Grundlage für eine darauf aufbauende Buchung genutzt werden.

3. Anfragen und 'Thin clients'

Die immer stärkere Verwendung von Internet-Technologien hat zu relativ einfachen Applikationen geführt, die die Anzeige von klinischen Daten über einen Web-Browser ermöglichen. Die darunterliegende Technologie kann entweder eine einfache Sammlung (serverseitig generierter) HTML-Seiten oder ein Java-Applet sein.

Diese 'Thin client'-Applikationen können typischerweise nicht die Daten auf dem Client persistent speichern. Ihre Funktionalität hängt von der Fähigkeit ab, verschiedene Datenelemente von verschiedenen Systemen zu erhalten.

Wenn der Thin Client nicht eng mit einer bestimmten Anwendung verknüpft ist, kann er eine Anfrageschnittstelle mit einem offenen Standard verwenden, so wie sie von verschiedenen Applikationen in Krankenhäusern bereitgestellt wird. Das reicht von Corba, J2EE, JMS (um nur einige zu nennen) bis hin zu HL7 Anfragenachrichten.

Die Anfragen und die dazugehörigen Antworten können auch als XML-Nachrichten formatiert werden. Diese können dann einfach druch XSLT nach HTML konvertiert werden. Durch die Nutzung eines Stylesheets kann die XML-Antwort sofort in geeigneter Form in einem Browser angezeigt werden.

Die Nutzung dieser Internet-Technologien und die Unterstützung von Anfrage-Schnittstellen im Gesundheitswesen nimmt zu. Einer der Gründe ist die Tendenz von Krankenhäusern stärker zusammenzuarbeiten. Das geht aber nur, wenn die Informationen von einem Leistungserbringer auch anderen Organisationen verfügbar gemacht werden.

 

Anfragen in SAP IS-H

Das IS-H Modul, wie alle anderen SAP Module auch, unterstützt Anfragen durch den SAP Exchange Infrastructure. Der SAP Exchange Infrastructure ist das Hauptmodul, wenn eine Integration mit SAP benötigt wird, die den SAP-Kunden sofort die Teilnahme an gemeinsamen Geschäftsszenarien und Marktplätzen erlaubt. Noch spezifischer, es erlaubt den SAP-Kunden sich mit beliebigen SAP-Applikationen und mySAP.com zu verbinden. Es ermöglicht auch die Integration mit nicht-SAP-Anwendungen und B2B-Transaktionen auf EDI-Art.

Ein XML-Dokument kann an den SAP Exchange Infrastructure geschickt werden, dieser antwortet ebenfalls mit einem XML-Dokument. Meistens wird dazu das HTTP Transportprotokoll genutzt. Über den SAP Exchange Infrastructure können alle durch das IS-H zur Verfügung gestellten APIs (bspw. BAPIs und RFCs) genutzt werden, vorausgesetzt, die Client-Anwendung hat die notwendigen Rechte. Im Gesundheitswesen kann dieses XML einfach in bzw. von anderen Standards wie HL7 übersetzt werden.

4. Zusammenfassung

Gegenwärtig gibt es keine Unterstützung für Anfrageschnittstellen in Deutschland. Die meisten Organisationen benutzen Nachrichten, um Basisinformationen zu übermitteln. Der Frage/Antwort-Mechanismus erlaubt einer Anwendung, ein System zu befragen, dem spezifische, für das anfragende System wichtige Informationen einer bestimmten Kategorie "gehören". Die Nutzung von Anfragenachrichten kann besonders dann sinnvoll sein, wenn in regionalen Kooperationsprojekten Daten für andere Organisationen zugänglich sein sollen. Typische Anfragen sind nach demographischen Patientendaten oder Laborergebnissen.

5. Referenzen

[HL7Query] "HL7 Query Messages", (Kapitel 2.8 der HL7-Version 2.2/ Kapitel 5.10.2 von HL7 v2.4), http://www.hl7.org/
[HL7ADTQuery] "HL7 Patient Administration Query messages", (Kapitel 3.2.9 der HL7-Version 2.2/ Kapitel 3.3.19 von HL7 v2.4), http://www.hl7.org/
[HL7ORUQuery] "HL7 Observation Query messages", (Kapitel 7.2.2 der HL7-Version 2.2/ Kapitel 7.3.3 von HL7 v2.4), http://www.hl7.org/
[HL7ConfStat] "Conformance Statements" (Kapitel 5 von HL7 v2.4), http://www.ringholm.com/docs/00500_en.htm


Anhang A: HL7 Anfragenachrichten

Dieser Teil enthält technische Details von HL7 Anfragenachrichten.

HL7 unterstützt verschiedene Anfragetypen: "Original Mode Queries" und erweiterte Anfragen. Vor der HL7-Version 2.4 gab es nur die "Original Mode Queries". Die Methologie für Anfragen wurde wie der HL7-Standard allgemein seit der Einführung mit Version 2.1 weiter entwickelt. Die Version 2.4 führt eine neue Methodologie ein, um die vorhergehende Generation von Anfragen abzulösen [HL7ConfStat]. Dieser Anhang fokussiert auf die "Original Mode Queries".

Dieser Abschnitt beschreibt die Nutzung von satzorientierten Original Mode Queries [HL7Query]. Separate Trigger wurden genutzt, um unterschiedliche Anfragen zu unterscheiden. Zusätzlich definieren einige der Kapitel Anfragen und Antworten mit separaten Ereignissen.

QRY^Q01^QRY_Q01 Generic Query
MSH Message Header
QRDQuery Definition
[ QRF ]Query Filter

Abbildung A.1 - QRY Nachrichtendefinition

Die Abbildung A.1 zeigt die Struktur von HL7 Anfragenachrichten. Die Anfrageparameter werden in den QRD (Query Details) und QRF (Query Filter) Segmenten übermittelt. Da diese Segmente bei allen Anfragen genutzt werden, ist der Inhalt nur ungenau im Standard festgelegt.

Der Anfragetyp wird durch QRD-9 (What subject filter) festgelegt. Der Suchbegriff der Anfrage wird entweder in QRD-8 ("Who") oder QRD-10 ("What") gespeichert. QRD-8 wird benutzt, wenn nach einer Person gefragt wird; QRD-10 falls nicht.

Die Struktur der Antwortnachricht enthält einige wenige anfragespezifische Segmente gefolgt durch eine Abfolge von Segmenten, so wie sie auch in ereignisgesteuerten Nachrichten desselben Kapitels definiert sind.

Anfrage nach demographischen Daten

Wenn eine Anwendung Bedarf an ADT-Daten über einen Patienten hat, sendet sie eine Anfrage an das ADT-System. Die Anfrage nach demograpischen Patientendaten (d.h. eine QRY^A19 Anfrage mit ADR^A19 als Antwort) ist die Anfrage, die international am meisten genutzt wird. [HL7ADTQuery]

QRY^A19^QRY_A19 Patient Query
MSH Message Header
QRD Query Definition
[ QRF ] Query Filter

Abbildung A.2 - QRY^A19 Nachrichtendefinition

Abbildung A.2 zeigt die Definition einer demographischen Anfrage. Der Anfragetyp (QRD-9: What subject filter) enthält DEM (Anfrage nach demographischen Patientendaten für eine bestimmte Patienten-ID), APN (Anfrage nach demographischen Patientendaten für einen bestimmten Patientennamen) oder andere gemäß HL7 Kapitel 3 festgelegte Anfragetypen.

MSH|^~\&|KIS||CommServer||200811111017||QRY^A19||P|2.2|
QRD|200811111016|R|I|Q1004|||1^RD|10000437363|DEM|||
Abbildung A.3 - QRY^A19 Beispielanfrage

Die Nachricht in Abbildung A.3 ist eine Anfrage (QRY) für demographische Patientendaten (DEM) zum Patienten mit der Identifikationsnummer "10000437363". Die Anfrage soll sofort beantwortet werden (I). Die Antwortnachricht soll maximal einen Datensatz (1^RD) enthalten. Die Daten sollen strukturiert (R) versendet werden - nicht in Textform. Ein Beispiel für eine Antwort zeigt Abbildung A.4.

MSH|^~\&|CommServer||KIS||200811111017||ADR^A19||P|2.2 
MSA|AA 
QRD|200811111016|R|I|Q1004|||1^RD|10000437363|DEM
PID|||10000437363|508003|Bauer^Fritz^^^||19631101|M|||Mercedesstr 12^^Bergheim^^68123^D||
   |||M|
NK1|1|Bauer^Karin|Ehefrau
PV1||S|CHI1^2W^1^CHI|R||||20 56 344^Antonius^ Markus^^^Dr.med.^^^Königstr. 112^69939
   ^Haarheim/M.^06146^61011|20 56 344^Antonius^Markus^^^Dr.med.^^^Königstr. 12^69939
   ^Haarheim/M.^06146^61011|N|||||||||9800703||K|||||||||||||||||||||||200811110928
DG1|1||355.9^355.9 Neuropathie onA^I9|||EL|||||||||1
DG1|2||386.-^386.- Schwindel^I9|||EL|||||||||2
DG1|3||087.9^087.9 Borreliose^I9|||EL|||||||||3
PR1|1||1-502.6^1-502.6 Biopsie durch Inzision am Unterschenkel^ICPM||20081107|P
PR1|2||5-940^5-940 Operationslagerung^ICPM|||P
PR1|3||5-900^5-900 Einfache Wiederherstellung der Kontinuität an Haut und Unterhaut
   ^ICPM|||P
IN1|1|0||NAK|Innenstr. 52 ^^Hannover^^30014||||||||207714 ||10035|Bauer^Fritz||19631101|
  Mercedesstr 12^^Bergheim^^68123
Abbildung A.4 - ADR^A19 Beispielantwort

Die Definition der Antwortnachricht ist in Abbildung A.5 dargestellt. (Anmerkung: Einige Segmente sind ausgelassen worden.) Der Inhalt der Nachricht ist in derselben Art wie andere Nachrichten aus Kapitel 3 strukturiert.

ADR^A19^ADR_A19 ADT Response
MSH Message Header
MSA Message Acknowledgment
[ERR] Error
[ QAK ] Query Acknowledgment
QRD Query Definition
[ QRF ] Query Filter
{  
  PID Patient Identification
  [{ ROL }] Role
  [{ NK1 }] Next of Kin / Associated Parties
  PV1 Patient Visit
  [ PV2 ] Patient Visit - Additional Info.
  [{ ROL }] Role
  [{ OBX }] Observation/Result
  [{ AL1 }] Allergy Information
  [{ DG1 }] Diagnosis Information
  [ DRG ] Diagnosis Related Group
  [{  
    PR1 Procedures
    [{ ROL }] Role
  }]  
  [{ GT1 }] Guarantor
  [{  
    IN1 Insurance
    [ IN2 ] Insurance Additional Info.
    [{ ROL }] Role
  }]  
  [ ACC ] Accident Information
}  

Abbildung A.5 - ADR^A19 Nachrichtendefinition

Anfrage nach Befunden

Eine Anwendung möchte die Befunde für einen Patienten haben und schickt deshalb eine Anfrage an das Laborsystem. Die Anfrage nach Laborbefunden (d.h. eine QRY^R02 Anfragenachricht mit QRF^R04 als Antwort) wird regelmäßig genutzt. [HL7ORUQuery]

QRY^R02^QRY_R02Result Query
MSH Message Header
QRD Query Definition
[ QRF ] Query Filter

Abbildung A.6 - QRY^R02 Nachrichtendefinition

Abbildung A.6 zeigt die Definition der Befundanfragenachricht. Der Anfragetyp (QRD-9: What subject filter) enthält RES (Anfrage nach Ergebnissen).

Die Anfrage in Abbildung A.7 möchte Daten eines EKG-Systems zum Patienten mit der Nummer 0123456-1 haben, die nach dem 1.1.2006 verändert bzw. erzeugt worden sind.

MSH|^~\&|MyEPA||EKG||||QRY^R02|CDB22222|P|2.2
QRD|200804180943|R|I|Q4412|||10^RD|0123456-1|RES
QRF|EKG||200801010000
Abbildung A.7 - QRY^R02 Beispielnachricht

Diese Anfrage (QRY) nach Ergebnissen (RES) basiert auf der Patienten-ID "0123456-1". Sie soll sofort (I) beantwortet werden. Die Antwort darf 10 Datensätze enthalten (10^RD), die Daten sollen ebenfalls strukturiert (R) übermittelt werden. Ein Filter schränkt die Ergebnisse auf einen Zeitbereich (20060101) ein. Abbildung A.8 enthält ein Beispiel für eine Antwort.

MSH|^~\&|EKG||MyEPA||||ORF^R04|X981672|P   
MSA|AA|CDB22222|P   
QRD|200804180943|R|I|Q4412|||10|RD|0123456-1|RES   
QRF|EKG||200801010000   
PID|1||0123456-1||Nordstein^Peter^H|||||||9821111   
OBR|1|43215^OE|98765^EKG|93000^EKG REPORT|R|200801111000|200801111330|||RMT||||200801111330|
  -|P030||||||200801120930||||||02^126666|A111|Viranyi^Andrew
OBX|1|ST|93000.1^VENTRICULAR RATE(EKG)||91|/MIN|60-100   
OBX|2|ST|93000.2^ATRIAL RATE(EKG)||/MIN|60-100   
OBX|3|ST|93000.3^PR INTERVAL||0|/MSEC|1.06-.10   
OBX|4|ST|93000.4^QRS INTERVAL||.368|/MSEC|.18-.22    
               ...   
OBX|8|CE|93000&IMP^EKG DIAGNOSES|1|^ATRIAL FIBRILATION   
OBX|9|CE|93000&IMP^EKG DIAGNOSIS|2|^ST DEPRESSION  
OBX|10|FT|93000&ADT^EKG COMMENT||\.br\ 1. Ein vergleich mit einem EKG vom 31.10.2002 zeigt, 
  dass die ventrikulär Frequenz um 30 bpm gestiegen ist.\.br\2. Die Kriterien für 
  einen Seitenwandinfarkt sind nich länger gegeben.
Abbildung A.8 - ORF^R04 Beispielantwort


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