E-Rezept, ePA und Co: TI-Monitoring-Tool hilft, Störungen im Blick zu behalten

Wer täglich mit der Telematikinfrastruktur (TI) – der Datenautobahn des deutschen Gesundheitswesens – arbeitet, weiß: Störungen und Verzögerungen können in Praxen und Kliniken schnell zum Problem werden. Abhilfe schaffen soll ein Monitoring-Tool, das nicht nur schneller informiert, sondern auch historische Daten archiviert und so erstmals Muster erkennbar macht.

Im Interview berichtet der Entwickler Lukas Schmidt-Russnak, selbst im Gesundheitswesen tätig, von seiner Motivation, den Nutzen transparenter TI-Daten und den Chancen seines Open-Source-Ansatzes. Die Grundlage für sein auf Github veröffentlichtes TI-Monitoring-Tool liefert eine API der Gematik, die ebenfalls dort verfügbar und gut dokumentiert ist.

Sie haben ein eigenes Monitoring-Tool für die Telematikinfrastruktur entwickelt. Wie kam es dazu?

Das Fachportal der Gematik hat verschiedene Einschränkungen. Zum Beispiel fehlen bei den Benachrichtigungen Filtermöglichkeiten für bestimmte Komponenten, Störungsmeldungen werden teilweise 15 bis 20 Minuten verzögert weitergegeben – beispielsweise an den WhatsApp-Kanal – und bei der Behebung von Störungen gibt es oft keine Entwarnung per E-Mail. Für eine Einrichtung, die täglich mit der TI arbeitet, sind das relevante Informationen. Deshalb habe ich mich entschieden, ein eigenes Tool zu programmieren.

Was kann Ihr Tool besser?

Zum einen kann über benutzerdefinierte Benachrichtigungsprofile nach relevanten Komponenten gefiltert werden, etwa dem eigenen VPN-Zugangsdienst. Zum anderen werden Störungen dauerhaft archiviert – im Gegensatz zum Fachportal, das nur die vergangenen 14 Tage anzeigt – im Diagramm im Fachportal werden lediglich die letzten 12 Stunden angezeigt. Mit der Archivierung werden Muster oder Häufungen erstmals sichtbar und quantifizierbar. Natürlich ersetzt das keine Einzelfallprüfung nach einem Service Level Agreement (SLA), aber es liefert eine realistischere Annäherung an den Alltag.

Regelmäßig wird kritisiert, dass die TI-Dashboards wenig Transparenz bieten. Teilen Sie diese Einschätzung?

Im Fachportal der Gematik hat sich zuletzt einiges getan. So wurden beispielsweise Abhängigkeiten zwischen Komponenten, Diensten und TI-Anwendungen modelliert. Dennoch empfinde ich insbesondere die Darstellung und Kommunikation von Wartungen beziehungsweise Changes häufig als undurchsichtig, wenn diese beispielsweise in einem Confluence-Wiki stehen, aber nicht im Change-Kalender. Das kann für Unsicherheit und Frustration bei den Nutzenden sorgen, was sich leicht vermeiden ließe. Die Gematik ist nach SGB V (§ 331) verpflichtet, Maßnahmen zur Überwachung des Betriebs zu treffen. Ich denke, dass ein transparenterer Umgang mit Störungen möglich wäre und sowohl die Stabilität der Systeme als auch die Akzeptanz der Nutzenden fördern würde. Das käme letztlich allen Beteiligten zugute.

Bild 1 von 7

Wie lange sind die Daten derzeit abrufbar?

Im Dashboard meines Tools werden standardmäßig die Daten der letzten 24 Stunden angezeigt. Dieser Parameter lässt sich jedoch in der Konfiguration frei anpassen. Zudem ist diese Einstellung unabhängig von der eigentlichen Archivierung, die im Backend erfolgt. Hier können Daten theoretisch über einen beliebig langen Zeitraum gesammelt und dank des offenen Dateiformats mit gängigen Statistik-Tools ausgewertet werden.

Sie haben Ihr Tool frei zugänglich auf GitHub veröffentlicht. Wie ist das Interesse?

Viele Einrichtungen haben weder die Zeit noch die Ressourcen, um eigene API-Abfragen zu entwickeln. Die Resonanz war erfreulich: In den ersten Tagen 40 Clones auf GitHub und auch zwei Wochen später gab es täglich weit über 100 Zugriffe von unterschiedlichen IP-Adressen auf die Demo-Instanz. Der Wunsch nach Austausch und Transparenz ist groß. Open Source erleichtert die gemeinsame Anpassung und Weiterentwicklung des Tools. Die einzelne Einrichtung muss gewissermaßen nicht bei null anfangen. Noch besser wäre es, wenn das Tool bei Open CoDE veröffentlicht werden könnte. Die Gematik hat dort bereits einen Account.

Gab es schon Reaktionen von der Gematik?

Ja, ich habe viel positives Feedback von Mitarbeitenden der Gematik erhalten. Es wurde allerdings auch auf die bekannten Disclaimer verwiesen: Über die APIs werden nur potenzielle Störungen ausgespielt und SLA-Bewertungen erfordern immer sorgfältige Einzelfallprüfungen. Eine Übernahme meines Ansatzes scheint mir eher unwahrscheinlich.

Dabei wäre es eine Win-win-Situation – weniger Kritik am Dashboard, mehr Transparenz für die Nutzer. Wie schätzen Sie die aktuellen Monitoring-Initiativen der Gematik ein?

Technisch ist es richtig, Abhängigkeiten zwischen zentralen Komponenten und Anwendungen wie dem E-Rezept sichtbar zu machen. Das ist für die Interpretation von Störungen sehr hilfreich, weil bei einigen Komponenten viel Know-how erforderlich ist, um die Auswirkungen auf konkrete TI-Anwendungen abzuschätzen. Aber solange die Daten nicht zeitnah und verlässlich ankommen, bringt das wenig. Eine Störungsmeldung, die fast 30 Minuten zu spät kommt oder eine Entwarnung, die komplett fehlt, hilft vor allem in großen Einrichtungen nicht. Ein zielgerichtetes, schnelles Monitoring kann hingegen einen wertvollen Zeitvorsprung verschaffen: Debugging-Maßnahmen können umgehend eingestellt und die betroffenen Personen – wo möglich – um die Nutzung von Ersatzverfahren gebeten werden. Das spart Ressourcen und Nerven.

Wo sehen Sie den größten Handlungsbedarf?

Mehr Transparenz, ein verstärkter Dialog mit den die TI nutzenden Einrichtungen und Personen sowie klare Vorgaben für die Hersteller. Ob es um Monitoring oder IT-Sicherheit geht – es wäre technisch vergleichsweise einfach, gewisse Standards festzuschreiben, anstatt jede Einrichtung mit Einzelfalllösungen alleine zu lassen.

Mit dem TI-Monitoring-Tool will ich niemanden anprangern, sondern für Nachvollziehbarkeit sorgen. Auch Verbesserungen sollen transparent sichtbar sein. Monitoring ist ein Werkzeug, um die Realität objektiv abzubilden – und das hilft allen Beteiligten, das Lagebild zu verbessern und dauerhaft eine echte Hochverfügbarkeit zu erreichen, wie es im KRITIS-Bereich erforderlich ist.

(mack)