gms | German Medical Science

Seit über 10 Jahren stellt die Erlanger Kommunikationsdrehscheibe (EKDS) die elektronische Kommunikation zwischen klinischen und administrativ orientierten IT-Anwendungssystemen sicher. Bereits Anfang 1995 stand als Werkzeug für die Integration von Subsystemen eine datenbankbasierte Integrationsplattform, die sog. „Kommunikationsdatenbank“ (KDB) zur Verfügung, die später durch den Kommunikationsserver eGate um eine nachrichtenbasierte Kommunikation ergänzt wurde.

Durch die aktuelle Pilotierung des klinischen Arbeitsplatzsystems Soarian der Fa. Siemens ergeben sich neue Anforderungen an die Kommunikation: Dort werden patientenbezogene - nicht im aktuellen Patientenmanagementsystem SAP IS-H abgebildete - Daten erfasst, die analog zur Kommunikation von Patientendaten aus IS-H ebenfalls über HL7 ADT-Nachrichten zu anderen IT-Anwendungssystemen kommuniziert werden müssen. Diese parallelen ADT-Datenströme müssen synchronisiert, sowie syntaktisch und semantisch aneinander angeglichen werden, was eine große Herausforderung darstellt.

Mit der geplanten Einführung der Gesundheitskarte und dem damit verbundenen Aufbau der bundesweiten Telematikplattform wird die EKDS auch Schnittstellen für eine sektorübergreifende Kommunikation zur Verfügung stellen, also mit anderen „Teilnehmern“ im Gesundheitswesen kommunizieren müssen. Auch beim Aufbau von Netzen für die integrierte Gesundheitsversorgung sind die Anforderungen ähnlich. Beide Fragestellungen setzen die Unterstützung der HL7 Version 3 durch die EKDS voraus. Ist die EKDS den zukünftigen Anforderungen gewachsen und welche Erweiterungen müssen dafür umgesetzt werden?

Anfang der 90er Jahre wurden am Universitätsklinikum Erlangen bereits erste Ansätze von datenbankbasierter Kommunikation auf der Basis des hierarchischen Datenbanksystems ADABAS C getestet. Im Jahre 1995 ging – zeitgleich mit der Einführung des SAP IS-H Systems – mit der sog. „Kommunikationsdatenbank“ (KDB) auf Basis des relationalen Datenbank-Management-System ADABAS D der erste Baustein der EKDS in den Produktiveinsatz. Anfang 1996 fand die Auswahl eines Kommunikationsservers statt, mit dem die nachrichtenbasierte Kommunikation realisiert werden sollte. Die Entscheidung fiel auf das Produkt DataGate der jetzigen Firma SeeBeyond. Mit der Einführung von DataGate wurde die KDB nicht etwa abgelöst, sondern es wurden beide Lösungsansätze kombiniert, um einerseits einen größeren Zeitrahmen für die Migration der an die KDB angebundenen Systeme in Richtung eGate zu erhalten, andererseits um durch Verknüpfung der Vorteile beider Kommunikationsansätze eine höhere Funktionalität der Integrationsplattform zu erreichen. Im Jahre 2001 fand die Migration des Kommunikationsservers auf die Version eGate 4 statt.

Derzeit sind über 50 Schnittstellen zu verschiedenen IT-Systemen im Universitätsklinikum Erlangen im Produktivbetrieb. Aktuell werden HL7-Nachrichten aus den Bereichen ADT (Patientendaten), ORU (Befunde), DFT (Leistungsdaten), ORM (Untersuchungs-Anforderungen) und MDM (Masterfile) unterstützt. Die KDB hat dabei auch heute noch ihre Existenzberechtigung, da sie die Defizite der Kommunikationsschnittstellen der Subsysteme sowie des HL7-Standards der Version 2.x (HL7 V2) ausgleicht. So dient die KDB z.B. als Zwischenspeicher für Inhalte aus nicht „HL7-konformen Subsystemen“ und zur Realisierung von Schnittstellen, die bei einigen Subsystemen nicht vorgesehen sind.

Zurzeit sind immer noch 17 Subsysteme direkt an der KDB angeschlossen. Das Ziel ist, auch diese Systeme von der proprietären Kommunikation via SQL-Abfragen auf die standardisierte Kommunikation via HL7 zu migrieren. Auch in Zukunft werden die Daten der KDB beispielsweise für Plausibilitätsprüfungen innerhalb der Leistungskommunikation benötigt. Zudem werden in der KDB Daten gespeichert, die über die Export-Schnittstellen (HCM, BAPI) des Patientenmanagementsystems IS-H nicht geliefert werden können, z.B. werden die Organisationseinheiten und deren Struktur über Reports aus IS-H exportiert, in der KDB abgelegt und damit anderen IT-Systemen zur Verfügung gestellt.

Die EKDS ist in der aktuellen Implementierung auf eine nachrichtenbasierte Kommunikation mittels HL7 V2 spezialisiert, wobei eine große Herausforderung die Integration der nicht HL7-konformen Schnittstellen des SAP IS-H war. Im Bereich der ADT-Schnittstellen heißt dies, dass das proprietäre Nachrichtenformat HCM nach HL7 umgewandelt werden muss. In Erlangen wurde 1996/97 entschieden, dass es dabei keinen für alle Systeme verbindlichen Hausstandard geben soll, sondern dass die Schnittstellen auf jede Anbindung speziell zugeschnitten werden. Auch in der eGate-internen Implementierung wurde darauf verzichtet, die HCM-Nachrichten zuerst in ein HL7-Zwischenformat zu übersetzen, welches dann in einem zweiten Schritt in das Format des Subsystems transformiert werden würde. Die Definition eines solchen Zwischenformats würde aber aus Sicht der Integration den Vorteil einer weiteren Entkopplung der Nachrichtenformate von Quell- und Zielsystemen bringen - entsprechend dem Pattern „Canonical Data Model“ [Ref. 1], welches im Bereich der Applikationsintegration Einsatz findet

Die Definition eines Zwischenformates allein wird aber nicht die Lösung des Problems mit zwei Patienten-Master-Systemen darstellen, dazu sind die HL7-Nachrichten aus IS-H und Soarian vom Umfang zu verschieden. Die nächste zu bearbeitende Problemstellung ist daher, dass die Nachrichten aus dem einen System mit den jeweils aktuellen Daten des anderen Systems angereichert werden und obendrein beide Nachrichtenströme auf ein einheitliches Event-Modell gebracht werden müssen. Dies kann nur über eine Integrationsplattform mit einem Hintergrundspeicher, der die Inhalte aller kommunizierten Nachrichten vorhält, gelöst werden.

Ein Ausbau der aktuellen EKDS ohne Berücksichtigung der zukünftig zu unterstützenden sektorübergreifenden Kommunikation wäre allerdings unzureichend. Sowohl in der Spezifikation für die bundesweite Telematikplattform [Ref. 2] als auch in ersten Spezifikationen für den Aufbau von Netzen der integrierten Versorgung [Ref. 3] wird inzwischen der Einsatz von HL7 Version 3 (HL7 V3) sowohl als Grundlage zur Modellierung der Daten als auch zur Implementierung des Nachrichtenaustausches empfohlen bzw. gefordert. Während also HL7 V3 als Standard in den nächsten Jahren in der klinikinternen Kommunikation kaum eine Rolle spielen wird, sollte es sich in der sektorübergreifenden Kommunikation etablieren.

Eine zukunftssichere Integrationsplattform muss deswegen unbedingt die Werkzeuge bereitstellen, um die technische Umsetzung von HL7 V3 zu unterstützen. Dazu gehört unter anderem die Verarbeitung von XML als neue Transfersyntax und die Implementierung von Web Services für die Realisierung der Schnittstellen. Andererseits muss aber auch auf logischer Ebene eine Anpassung an HL7 V3 erfolgen. HL7 V3 stellt einen weiteren Schritt in Richtung „Plug&Play“ bei der Integration medizinischer EDV-Systeme dar, was durch die Definition eines konsistenten Informationsmodells (das HL7 V3 RIM), die Eliminierung von Optionalitäten und die Einführung standardisierter Applikationsrollen (ähnlich der Definition der Actors in den Integration Profiles bei IHE) erreicht werden soll. Daraus folgt umgekehrt, dass der Aufwand für die Integration eines nicht HL7 V3 konformen Systems in eine HL7 V3 konforme Umgebung einen ungleich höheren Aufwand bedeutet als dies bei HL7 V2 der Fall ist [Ref. 4].

Ausgehend von den beiden Anforderungen, einerseits ein einheitliches Zwischenformat innerhalb der EKDS zu definieren und andererseits eine zukünftige HL7 V3 Kommunikation unterstützen zu können, ergibt sich in Erlangen der Lösungsansatz, einen HL7 V3 Transaktionsserver aufzubauen, der eingehende Nachrichten gleich welchen Formats auf ein internes, dem RIM angepassten Datenmodell abbildet und darauf aufsetzend sowohl HL7 V2 als auch HL7 V3 Nachrichten erzeugen kann.