Folge #43 – Kommunikationsserver

Written by

in

Beschreibung

In dieser Folge beschäftigen sich Renato und Christian mit Kommunikationsservern im Krankenhausumfeld. Ausgehend von Systemen wie KIS, RIS, PACS, DMS, PDMS und LIS erläutern die beiden die zentrale Rolle von Kommunikationsservern bei der Integration und dem Datenaustausch zwischen unterschiedlichen IT-Systemen. Darüber hinaus werden Funktionen, Vor- und Nachteile sowie typische Einsatzgebiete und Anbieter solcher Integrationslösungen im Gesundheitswesen eingeordnet.

Podcast: Play in new window

Transkription

Renato, ein Kommunikationsserver, was ist denn das? Da stellen wir uns jans dumm und überlegen uns erst mal, wie ist es dazu gekommen. Also die IT-Landschaft hat sich ja in den letzten Jahrzehnten so ein bisschen gewandelt im Krankenhaus früher, was durchaus üblich, dass es so monolitische Architekturen gab, ein Anbieter für das gesamte Krankenhaus. Heutzutage pricht das ein bisschen auf. Es gibt immer wieder diesen Best-of-Bread-Ansatz. Man holt sich das System, das einem bestimmten Wirkler am Besten unterstützt und das ist nicht immer das vom größten Anbieter oder nicht immer das von dem, was man die schon einmal haus hat. Und das erfordert dann letztendlich, dass diese verschiedenen Systeme miteinander kommunizieren. In Zukunft natürlich, dass die Digitalisierung Krankenhaus immer weiter voranschreitet und immer mehr Bereiche digitalisiert werden. Wenn früher zum Beispiel die Kurve noch auf Papier war, dann gibt es jetzt immer mehr Krankenhäuser, die das auch elektronisch umsetzen. Und dann nimmt man sich teilweise eben auch mal Fremdefirmen noch dazu und Haus und dadurch, wie gesagt, entstehen immer mehr Kommunikationspartner und wenn jetzt tatsächlich alle miteinander kommunizieren wollen, dann nimmt mit jedem Kommunikationspartner die Komplexität dieser Kommunikation immer mehr zu. Kann sich ja vorstellen, einer drei Kommunikationspartner alle reden miteinander, da gibt es drei Schnittstellen. Bei vier Kommunikationspartnern kommen jetzt drei Schnittstellen noch dazu, dann sind wir schon bei sechs und bei fünf Kommunikationspartnern kommen jetzt vier dazu, dann sind wir bei zehn. Also es nimmt Rapide zu und um diese komplexe Kommunikation zumindest etwas zu vereinfachen, bricht man es auf, dass jeder mit jedem kommunizieren muss, also dass diese Peer-to-Peer-Kommunikation stattfindet und man macht eine Sternförmenege Kommunikation. Das heißt, jede Kommunikation läuft über einen zentralen Punkt und selbst wenn ich jetzt direkt mit einem System kommunizieren will, geht das quasi einmal über Bande über einen zentralen Server. In dieser zentrale Server ist dann eben genau dieser Kommunikationsserver, weil er sich in die Kommunikation von diesen ganzen Systemen einschaltet. Die Vor-Nachteile, die werden wir gleich noch ein bisschen auseinander tröseln, das ist vielleicht erstmal so zur Architektur. Trösel, das ist eigentlich so ein Wort aus dem Saarland. Steht das im Duden? Nee, das ist ein Hochdeutsches Wort. 16 des Jahrhundert kommt von Drosophila. 

Gut, dann drösel ich jetzt mal weiter und zwar was für Aufgaben, was für Funktionen kann, denn so normaler Kommunikationsserver. Mit das Wichtigste ist sicher, dass er übersetzt oder konvertiert. Und mit übersetzen oder konvertieren ist sowohl gemeint, dass von einem Kommunikationsstandard in einen anderen Kommunikationsstandard konvertiert werden kann, also HL7 nach DICOM oder umgekehrt, LDT, nach HL7 oder umgekehrt oder auch HL7 in proprietäre Schnittstellen, wie zum Beispiel BAPI von SAP. Es kann aber auch, und das kommt im Alltag dann wirklich häufig vor, dass Daten innerhalb eines Kommunikationsstandards angepasst werden. Also das, was ja gerade bei HL7 vor 2 häufig vorkommt, also dass eine Information von System A im 12. Feld erwartet wird von einem Segment und in einem anderen System von mir aus im 13. Feld und da kann Kommunikationsserver helfen, der weiß einfach, welches System an welcher Stelle die Information erwartet und schickt dann jedem System die Nachricht genau so, wie sie braucht und muss natürlich vor die Nachrichten entsprechend anpassen. Das ist das zweite und das dritte, was übersetzen oder konvertieren angeht, kann man auch da drunterfassen der Übertragungsweg. Also es kann sein, dass moderne Systeme heutzutage von mir aus über ein Web-Service angesprochen werden wollen, dass es Mittelalte-Systeme gibt, die vielleicht Dateien in einem Filesystem ablegen und dort der Kommunikationsserverregeln mäßig nachschaut. Oder es gibt auch Systeme, es gibt nichts, was es nicht gibt, hier auch schon von Systeme gehört, die neue Nachrichten über klassische e-Mail-Protokolle versenden wie SMTP und Pop 3. Du hast Klippeln. Klippeln, Klippeln 3. Nachdem nicht alle Systeme, alle Übertragungswege können, kann dort der Kommunikationsserver auch helfen. Also auf diesen drei Ebenen von einem Kommunikationsstandard zum anderen konvertieren. Eins, zwei, innerhalb eines Kommunikationsstandards innerhalb einer Nachricht, natürlich die Daten anpassen und das dritte den Übertragungsweg auch überbrücken. 

Was macht zum Komsover noch? Der kann natürlich filtern. Also wenn eine Nachricht nicht an gewisse Systeme gehen soll, dann werden die einfach dort nicht weiter geleitet. Als ein Beispiel, das Riss muss erst dann von einem Patienten Bescheid wissen, wenn zu diesem Patienten radiologische Auftrag angelegt wird, vorher sollte der Kommunikationsserverlass entsprechend nicht durchlassen. Ein Essenssystem, natürlich, wenn das elektronisch von Statten geht und wenn das so eine entsprechende Schnittstelle hat, sollte direkt Bescheid wissen, wenn ein neuer Patient aufgenommen wurde. 

Aufgabe 3, nach übersetzen, konvertieren und filtern, ist Monitoring. So ein Kommunikationsserver kann auch dafür eingesetzt werden, um zu gucken, ob die Systeme tatsächlich noch laufen, ob die noch leben. Klassischerweise, wenn eine Nachricht geschickt wird, gibt es auch zwei unterschiedliche Bestätigungsmeldungen, dass die Nachricht also angekommen ist, das sogenannte ACK, das kann man noch mal unterteilen in ein Transport ACK, ja, die Nachricht ist angekommen und ein, sagen wir mal, Anwendungsak, ja, die ist angekommen und ich habe es auch verstanden, das ist alles in Ordnung. So was kann so eine Kommunikationsserver auch mit Monitoring und wenn normalerweise üblich ist, dass vielleicht ein System A alle zwei Minuten der Nachricht schickt und dass jetzt mal eine halbe Stunde stillsteht, könnte so ein Kommunikationsserver auch das mitbekommen und könnte eine Warnung schicken an den Administrator etc. 

Aufgabe 4, loggen, kann also mit protokuliert werden, welche Daten reingekommen sind, wie sie transformiert worden sind und wie sehr wieder rausgegangen sind. Für was ist das wichtig, wenn jetzt tatsächlich mal ein Fehler fall auftritt und im PDMS-System auf der Intensivstation zum Beispiel ein Patient nicht angekommen ist, also elektronisch nicht angekommen ist, nicht im System drin ist, dann kann man im Kommunikationsserver nachschauen und kann gucken, wo dran das denn jetzt liegt, ist die Nachricht vielleicht beim Patienten führenden System gar nicht ausgelöst worden, wo die gar nicht generiert, hängt es am Kommunikationsserver oder wurde eine richtige Nachricht rausgeschickt, anders PDMS und dort liegt dann irgendwo der Fehler, das heißt man kann es dort an einer zentralen Stelle relativ gut nachschauen und dann Fehlerursachen feststellen und als letztes puffern, speichern, klöpeln und archivieren, wenn also ein System vielleicht mal heruntergefahren werden muss, ja bleiben wir mal bei dem Essenssystem und ist ein Update bekommt und vielleicht deswegen zwei, drei Stunden nicht online ist, wäre es natürlich doof, wenn dann das System die ganzen Nachrichten nicht bekommt und somit die Patienten, die in dieser Zeit aufgenommen worden sind im Essenssystem gar nicht bekannt sind und da kann man den Kommunikationsserver sagen okay, wir haben jetzt ein Wartungsfenster von mir aus, das heißt du puffer jetzt mal alle Nachrichten, die an das Essenssystem gehen sollen, die schickst du nicht raus sondern die merkst du dir und wenn die es Wartungsfenster zu Ende ist, sagen wir jetzt schickt die Nachrichten wieder raus ans Essenssystem und zwar in der gleichen Folge, wie sie in echt Zeit rausgegangen werden, sodass dann nach einer gewissen Zeit auch dieses Essenssystem wieder auf dem aktuellen Stand ist. Wenn man Kommunikationsserver nicht hat, muss man das irgendwie anders machen, das puffern. 

Also das waren so grob die Aufgaben, übersetzen, auf den unterschiedlichen Ebenen, filtern, monitorn, ob alles in Ordnung ist, ob eine Nachricht angekommen ist oder nicht, protokulieren, zu fehlersuche, puffern, speichern und so weiter. Also das kann man natürlich auch beliebig kombinieren, das sind so die Hauptaufgaben, die einen Kommunikationsserver hat. 

Renato, ich habe die Agenda Form hier von daher weiß ich, dass du uns jetzt dringend etwas zu den Vor- und Nachteilen von Kommunikationsservern erzählen magst. 

Das mag ich genau. Also ein großer Vorteil, der sich auch schon aus der Herleitungen ergibt, die ich vorhin gesagt habe, ist, dass die Komplexität herabgesetzt wird. Ja, wir haben nicht mehr eine Kommunikation zwischen jeden Teilnehmer, sondern wir haben eine größere Schnittstelle zwischen den Teilnehmern und dem jeweiligen Kommunikationsserverkommt, ein neuer Teilnehmer hinzu. Dann gibt es eine neue Schnittstelle mit dem Kommunikationsserver und der Kommunikationsserver verteilt dann alles. Das reduziert die Komplexität, macht es wesentlich leichter, wartbar, macht es wesentlich leichter, handelbar, insbesondere für die Administratoren, die sich im Krankenhaus befinden, die können da sich etwas besser und einfacher zurücklehnen. Die haben natürlich dann auch mehr Aufgaben, aber sie haben bessere Übersicht über das, was sie tun. Ob den Anbiet dann immer so ganz recht ist, wenn sie jetzt mit einem Kommunikationsserver zu tun haben, das mag vielleicht dahingestellt sein, das liegt unter anderem aber daran, dass man sich natürlich auch jeder einzelne Schnittstelle bezahlen lässt und da kerben wir auch schon zu einem weiteren Vorteil. Zumindest aus Sicht der Krankenhäuser. Ein Vorteil kann sein, dass man durch so einen Kommunikationsserver die Kosten senken kann. Ich sag bewusst kann, es hängt sehr davon ab, wie viel Schnittstelle man davor hat, wie viel Kommunikationspartner man hatte, also wie viel Schnittstellen man dadurch dann einspart. Es hängt auch natürlich davon ab, was für einen Kommunikationsserverber man wählt, denn auch hier können natürlich noch große Kosten anfallen und es hängt natürlich auch davon ab, wie stabil das Ganze läuft, wenn man sich jetzt einen Kommunikationsserver ins Haus holt, der dann mehr Problem macht, als dass er einem hilft, dann hätte man vielleicht besser mit den alten Schnittstellen gearbeitet. Also die Kosten können ein großer Faktor sein, wenn man aus zehn Schnittstellen auf einmal vier oder fünf macht, dann kann man dadurch schon einiges an Geld einsparen. Dann ist ja vorhin schon rausgekommen, das Loggen, das manipulieren können, das zeigt, dass wir eine größere Transparenz bei der Kommunikation haben. Wir haben also die Möglichkeit, hier in den Strom direkt einzukreifen, was vielleicht vorher nicht gut möglich war, wenn es zu einer Piotopia-Kommunikation bekommen ist. Als Krankenhaus möchte man vielleicht nicht jedes Mal jede kleine Änderung über den Hersteller laufen lassen, sondern vielleicht an kleineren Änderungen auch direkt arbeiten und da bietet der Kommunikationsserver die Möglichkeit dazu. Komponenten sind leichter austauschbar, wenn ich also eine Komponente austausche, dann muss ich nicht alle Schnittstellen austauschen, die es von den anderen Komponenten zu meiner neuen Komponente gibt, sondern die anderen Komponenten kommunizieren ganz normal weiterhin mit dem Komponikationsserver und bekommen gar nicht mit, dass auf der anderen Seite jetzt eine Komponente ausgetauscht wurde. Das waren jetzt alles Vorteile mit den Kosten, das war so ein halb halb, was aber auf jeden Fall ein Nachteil ist, ist, dass dieser Kommunikationsserver there in der Mitte natürlich eine unheimliche Verantwortung hat. Im Ein Single Point of Failure, wenn der kaputt geht, dann steht quasi das ganze Haus früher, wenn ein Azubi des Haus-Lamlegen wollte, dann musste er vielleicht an vier der fünf Systemen, musste er dran rumtreten und heutschaft, der es, wenn er ein System, ein zentrales System lahmlegt. Also kann ich mitnehmen, dass Kommunikationsserver sehr azubifreundlich sind. Ja, definitiv. Kommunikationsserver sollte man immer anwenden, wenn man nicht ganz so fege azubi ist hat. Also das auf jeden Fall einen kritischer Punkt, dieses zentrale Element, das kaputt gehen könnte in Anführungszeichen. Und natürlich haben Kommunikationsserverwendungen, wenn man sie richtig verwendet, auch eine gewisse Komplexität, in die man sich einarbeiten muss. Das muss einem bewusst sein, aber wenn man Technik-Affien ist, dann kann es durchaus sein, dass man sich da gerne einarbeitet und das gar nicht als Belastung sich. 

Okay, jetzt zu unserem letzten Punkt schon Christian, was gibt es denn alles für Kommunikationsserverso auf dem Markt? 

Danke für die Überleitung, Renato. Also es gibt ein paar größere, den Mirth Connect zum Beispiel, der ist sogar kostenlos verfügbar, den setzt sich auch selbst in einer meiner Übung ein. Wenn man sich gar nicht damit auskennt, kann ich das wirklich nur empfehlen, dass man sich den mal runterlädt, gibt eine nette Web-Oberfläche, gibt es schon relativ viele Kommunikationsstandard, die der direkt out of the box spricht. Was gibt es noch? Es gibt von CorePoint Health, die CorePoint Integration Engine, es gibt den klassischen Cloverleaf von Health-Com. Es gibt zwei, die ehrlich gesagt mir bisher noch nicht untergekommen sind, aber vielleicht sind sie doch groß, kann ich tatsächlich nicht sagen, den Dataf-Kommunikationsserver und ein GKV-Kommunikationsserver. Und von der Firma Extension aus Österreich gibt es Orkestra. Gerade schon gesagt, falls man sich mit dem Thema mal ein bisschen beschäftigen möchte, und da ist wirklich die Lernkurve sehr schnell und sehr hoch bei diesem kostenlosen Produkt von Mirth Connect, dem Mirth-Kommunikationsserver unter mirth.com/mirth.com/mirth, der unterstützt direkt out of the box. HL7-DICOM-XML-X12 kann HL7-2. X auch nach XML umwandeln, natürlich nicht in ein valides HL7-V3-Format. Dazu fehlen natürlich bei einer klassischen HL7-V2-Nachricht zu viele Informationen. Der hat auch viele Connectoren, heißt das hier, also diese Übertragungswege. Der kann MLLP, das ist sowas wie TCP für HL7, der kann HTTP, also Web Services, der kann E-Mail. Ich habe hier vorhin schon gesagt, dass es Leute gibt, diese was machen, der kann klassisches altes, normales TCP. Der kann FTP, also da teilen, ablegen, über das File Transfer Protocol, der kann Datenbankverbindung direkt machen und so weiter und so weiter. Also der kann sehr viel, relativ schön erklärt, und das sind quasi meine letzten Worte, falls man sich damit nicht auskennt. Oder falls die IT-Liter sind in einem kleinen Haus und haben Angst davor sich einen großen Kommunikations-Servantshaus zu holen, die jetzt aber Geschmack bekommen haben oder Interesse dran bekommen haben, dann installieren sie sich mal den Mirst und damit kann man alleine schon sehr, sehr viel machen. 

Links zum Podcast

Schlagwörter

Kommunikationsserver, KIS, RIS, PACS, DMS, PDMS, LIS, Krankenhaus-IT, Schnittstellen, Interoperabilität, Systemintegration, eHealth, HL7