gms | German Medical Science

51. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e. V. (gmds)

10. - 14.09.2006, Leipzig

Die Grenzen der Einsetzbarkeit von HL7 am Beispiel der Übermittlung von Diagnosen und Prozeduren am Universitätsklinikum Hamburg-Eppendorf

Meeting Abstract

Suche in Medline nach

  • Wolfgang Gleiniger - Universitätsklinikum Hamburg-Eppendorf, Hamburg

Deutsche Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie e.V. (gmds). 51. Jahrestagung der Deutschen Gesellschaft für Medizinische Informatik, Biometrie und Epidemiologie. Leipzig, 10.-14.09.2006. Düsseldorf, Köln: German Medical Science; 2006. Doc06gmds368

Die elektronische Version dieses Artikels ist vollständig und ist verfügbar unter: http://www.egms.de/de/meetings/gmds2006/06gmds247.shtml

Veröffentlicht: 1. September 2006

© 2006 Gleiniger.
Dieser Artikel ist ein Open Access-Artikel und steht unter den Creative Commons Lizenzbedingungen (http://creativecommons.org/licenses/by-nc-nd/3.0/deed.de). Er darf vervielfältigt, verbreitet und öffentlich zugänglich gemacht werden, vorausgesetzt dass Autor und Quelle genannt werden.


Gliederung

Text

Einleitung und Fragestellung

Beim Aufbau eines Klinischen Arbeitsplatzsystems am Universitätsklinikum Hamburg-Eppendorf (UKE) wurde eine Verteilung von Teilaufgaben des Prozesses der Erfassung und Bearbeitung von Diagnosen und Prozeduren über mehrere Systeme hinweg implementiert. Dies geschah aus unterschiedlichen Gründen, primär jedoch mit dem Ansatz für eine Architektur die Dokumentationsaufgaben klinisch tätiger Mitarbeiter möglichst in einem Dokumentationssystem zu belassen und damit das Ziel zu verfolgen, die Dokumentation abrechnungsrelevanter Daten als Abfallprodukt klinischer Dokumentation zu erhalten. Daher wurde im UKE die Integration über HL7-Schnittstellen massiv ausgebaut.

Es ergibt sich der in Abbildung1 [Abb. 1] dargestellte Basisprozess für die Übermittlung von Diagnosen und Prozeduren bei der Integration der klinischen und administrativen Systeme, wobei alle Nachrichten über einen zentralen HL7-Kommunikationsserver übermittelt werden.

Der Erfolg dieser Strategie zeigt sich in einer Verbesserung der Datenqualität und einer Beschleunigung des gesamten Prozesses im Vergleich zur vorherigen rein papierbasierten Abwicklung, wodurch beispielsweise unmittelbar der Abrechnungsrückstand verringert und die Liquidität des Hauses erhöht werden konnte. Daher war das gewählte Vorgehen vermutlich alternativlos. Obwohl die Schnittstellen technisch ordnungsgemäß implementiert, durch die Fachabteilung abgenommen und zum Betrieb freigegeben wurden, treten im laufenden Betrieb immer wieder Probleme insbesondere bezüglich der Vollständigkeit der Datensätze und der Vollständigkeit der Nachrichten auf, deren Ursachen und Fehlerquellen in den folgenden Ausführungen untersucht werden.

Material und Methoden

Die Problemstellen und Fehlerquellen im Basisprozess sind in der Abbildung 2 [Abb. 2] skizziert. Allein die Vielzahl der Punkte zeigt die Komplexität des Prozesses deutlich. Hinzu kommt, dass der Prozess der Erhebung von Daten für die Abrechnung in den klinischen Bereichen durch Aktivitäten des Gesetzgebers einem jährlichen Wandel unterworfen ist, der jedes Mal direkte Auswirkungen auf die HL7-Schnittstellen zeigt. Die in der Regel kurzfristige Auslieferung von Software mit den gesetzlichen Änderungen zum Jahreswechsel (z.B. neue Zusatzentgelte) und eine sich gleichzeitig ändernde interne Organisation (z.B. neue Einrichtungen oder Zentren) lassen zu wenig Zeit für Anpassungen der Schnittstellen an geänderte Datenströme und Organisationsformen.

Ad 1), 4) und 7): Zwingend für das Funktionieren einer Schnittstelle ist die Übereinstimmung von Katalogen. Auch innerhalb der aktuell gültigen Kataloge ergeben sich Spielräume, wie beispielsweise die Verwendung von nicht amtlichen Erweiterungen.

Ebenfalls zwingend für das Funktionieren einer Schnittstelle ist die Verwendung einheitlicher Kataloge für Leistungsstellen und Organisationseinheiten. Nicht bei allen Systemen ist es möglich, den aktuellen Katalog über alle Einrichtungen hinweg einzustellen, da viele Systeme gar nicht für mehrere Einrichtungen ausgelegt sind.

Ad 2): Der Auslöser zum Versand besteht in der Regel aus einer Freigabe, die aktiv durch eine berechtigte Person gesetzt werden muss. Zweistufige Freigabeprozesse, z.B. mit Arzt – Oberarzt, die durch parallele papierbasierte Prozesse nicht zwingend elektronisch durchgeführt werden müssen, können zu verspäteter Übermittlung führen. Wenn dann im Klinischen Dokumentationssystem bereits eine Validierung des Aufenthalts stattgefunden hat, ist die Übermittlung eigentlich nicht mehr sinnhaft.

Ad 3): Der Import von Nachrichten zu einem bereits validierten Fall ist nicht möglich, da dann die Validierung wieder aufgehoben würde. Fehlermeldungen landen im System-Log, so dass eine Auswertung nur sehr schwer möglich ist.

Ad 4) und 7): Die Komplexität der Abrechnungsregeln im Datenmodell ist sehr hoch. Nicht immer stimmen alle Regeln in beiden Systemen vollständig überein, wodurch Interpretations- und Übermittlungsfehler entstehen können. Insbesondere die zunehmende Verzahnung zwischen ambulant und stationär stellt für die Übereinstimmung der Datenmodelle eine große Herausforderung dar.

Ad 4): Wenn für die Abrechnung zusätzliche Felder wie beispielsweise besondere Medikamente oder Beatmungszeiten erforderlich werden, so müssen die Software und die Schnittstelle zusammen mit dem Hersteller spezifiziert und angepasst werden. Die Akzeptanz für ein Klinisches Dokumentationssystem, das nur langfristig auf die Bedürfnisse der klinisch tätigen Mitarbeiter ausgerichtet ist und kurzfristig primär zur Erfassung administrativer Daten ohne weiteren Nutzen für die klinische Dokumentation dient, ist sehr schwer herzustellen. Da Leistungsanforderung und Befundpräsentation nochmals jeweils in eigenen Systemen geschehen, stehen Laborbefunde nicht im System zur direkten Übernahme in Dokumente wie z.B. den Arztbrief bereit.

Ad 5): Auch Kommunikationsserver stürzen ab. Leider kann dies zu Datenverlusten in stehenden Warteschlangen führen. Nachrichten kommen dann nicht zwingend an.

Ad 6): Die im Standard ausgelieferte Importschnittstelle wird längst nicht mehr allen Anforderungen gerecht. Daher wurde eine eigene Schnittstelle auf Grundlage der Standardschnittstelle entwickelt, die jedoch bei jeder Änderung wieder überprüft und ggf. angepasst werden muss.

Ergebnisse

Trotz des zweifelsohne großen Erfolgs durch den Einsatz dieses Prozesses, der sich in einem erheblichen Rückgang der Anzahl der nicht abgerechneten Fälle zeigt, bleiben Anmerkungen zu kritischen Punkten offen.

  • Die Validierung der Medizinischen Dokumentation sollte möglichst in dem System erfolgen, in dem die Abrechnung erfolgt. Ansonsten muss die Übermittlung und Vollständigkeit der Daten gegebenenfalls nochmals extra geprüft werden.
  • Die HL7-Schnittstellen wie auch die Funktionalität der eingesetzten Software können oft nicht rechtzeitig an jährlich sich ändernde Anforderungen und Datenströme angepasst werden.
  • Die Abläufe im Klinikum sind nicht immer so ausgeprägt wie geplant und beschrieben.
  • Eine Trennung zwischen Klinischem Dokumentationssystem und Abrechnungssystem bedingt eine direktere Kopplung als es ein Nachrichtenaustausch über HL7 ermöglicht. Eine strategische Partnerschaft zwischen den Softwareherstellern für das Abrechnungssystem und das Klinische Dokumentationssystem, die über das Austauschen von Schnittstellenspezifikationen hinausgeht und eine gemeinsame Entwicklung der Systemintegration beinhaltet, wäre wünschenswert. Optimal wäre die Abbildung der gesamten Funktionalität in einem System.
  • Ein Klinisches Dokumentationssystem, das weiteren Nutzen schaffen soll, muss die Ambulanzen sowie die Leistungsanforderung und die daraus resultierende Befunddarstellung nativ integriert haben.
  • Die Spezialsysteme können über die entsprechenden HL7-Schnittstellen integriert werden, sofern eine regelhafte Pflege der Kataloge und Hitlisten geschieht.

Diskussion

Die Komplexität der Prozesse und die Häufigkeit der Veränderungen durch die interne Organisation und den Gesetzgeber ermöglichen auch bei bestem Willen aller Beteiligten nur mit sehr großem Aufwand eine fehlerfreie asynchrone Kommunikation von Diagnosen, Prozeduren und der zugehörigen grouperrelevanten Daten. Aus Sicht der Informationstechnologie ist daher größere eine Konzentration von Funktionalitäten in einer Software zwingend, um die internen Prozesse stärker optimieren zu können und letztendlich dauerhaft auch in Zukunft im Wettbewerb der Krankenhäuser und Kliniken erfolgreich zu bestehen.


Literatur

1.
Dokumentation der Softwarehersteller, Verfahrensdokumentation des Geschäftsbereichs Informationstechnologie des UKE
2.
ICD, OPS, etc., www.dimdi.de
3.
HL7 Standard Version 2.6, www.hl7.org