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)

Die Gerüchte stimmten: Apple erlaubt es Entwicklern künftig auch, Anthropics Claude als Coding-Assistenten zu verwenden. Die Funktion ist Teil der siebten Beta von Xcode 26, die in der Nacht zum Freitag für Mitglieder von Apples Developer-Programm veröffentlicht wurde. Neben Claude wird nun auch GPT-5 von OpenAI verfügbar gemacht.

Reasoning-Modell von GPT-5 – aber nur „Low“

Der ChatGPT-basierte Assistent in Xcode beherrschte zuvor nur GPT-4.1. Künftig ist GPT-5 das Standardmodell von OpenAI, es ist aber auch möglich, auf GPT-4.1 zurückzuwechseln, schließlich ist GPT-5 auch für das Programmieren nicht unumstritten. GPT-5 sei „für schnelle, qualitativ hochwertige Ergebnisse“ optimiert, schreibt Apple im Xcode-26-Beta-7-Beipackzettel. „Das sollte für die meisten Coding-Aufgaben gut funktionieren.“ Es ist aber lobenswerterweise auch möglich, auf das Reasoning-Modell von GPT-5 umzustellen.

„Dieses benötigt mehr Zeit zum Nachdenken, kann aber genauere Ergebnisse für komplexere Programmieraufgaben liefern.“ Apple gibt an, dass GPT-5 ohne Reasoning im „minimalen“ Reasoning-Level läuft, GPT-5 mit Reasoning im Reasoning-Level „Low“. Das heißt, dass die volle Nachdenkleistung über Xcode nicht verfügbar ist – mit der ChatGPT-App für macOS sollte das hingegen funktionieren. OpenAI hatte schon im letzten Jahr eine Xcode-Integration entwickelt.

Paid-Account von Claude notwendig

Claude in Xcode basiert auf Sonnet 4 und ist über das „Intelligence Settings“-Panel aufrufbar. Kostenlos ist es nicht: User müssen ihren Bezahlaccount bei Anthropic hinterlegen. Ob auch noch Opus 4 unterstützt wird, bleibt unklar – dazu hatten sich zuvor Code-Referenzen gefunden. Wenn Xcode 26 erscheint, soll es weiterhin möglich werden, Drittmodelle via deren API einzubinden. Schließlich will Apple auch lokale Modelle unterstützen, die immer beliebter werden, sofern der Mac ausreichend performant ist.

Weitere Spekulationen, Claude könne demnächst auch in Siri beziehungsweise systemweit integriert werden, wie man das von ChatGPT kennt, bestätigten sich zunächst nicht. Xcode 26 Beta 7 läuft auch unter macOS 15 alias Sequoia. Allerdings scheint die KI-Unterstützung dort nicht aktiv zu sein. Nutzer benötigen also auch noch eine Beta von macOS 26 alias Tahoe. Auch hier gibt es eine Hürde: In einer VM darf dieses nicht laufen, da dort der Apple-Intelligence-Hauptschalter nicht aktiviert werden kann

(bsc)

Die japanische Weltraumagentur will sich an einer europäischen Weltraummission beteiligen, in deren Rahmen eine Sonde den Asteroiden Apophis bei seinem außergewöhnlich nahen Vorbeiflug an der Erde begleiten soll. Das hat die ESA jetzt publik gemacht und erklärt, dass die JAXA die Solarkollektoren, eine Infrarotkamera und die Startmöglichkeit für die Mission namens Ramses (Rapid Apophis Mission for Space Safety) stellen will. Eine entsprechende Anfrage sei an die japanische Regierung gestellt worden. Dabei ist noch immer nicht entschieden, ob Ramses tatsächlich realisiert wird, erst im November soll der ESA-Ministerrat das beschließen. Wegen des Zeitdrucks haben vorbereitende Arbeiten aber schon längst begonnen.

Einmalige Gelegenheit für die Wissenschaft

Apophis wurde 2004 entdeckt und nach einem der wichtigsten Antagonisten in der damals aktuellen Fernsehserie Stargate SG-1 benannt. Weil anfangs eine Wahrscheinlichkeit von immerhin 2,7 Prozent für einen Einschlag auf der Erde im Jahr 2029 ermittelt wurde, erregte der Himmelskörper viel Aufmerksamkeit. Dank zusätzlicher Daten wurde dieser Einschlag ausgeschlossen, das konnte später auch für die Vorbeiflüge in den Jahren 2036 und 2069 nachgereicht werden. Erschwert wurden die Prognosen dadurch, dass nicht genau genug ermittelt werden konnte, inwieweit Apophis jeweils durch seine Annäherungen an die Erde abgelenkt werden wird. Der Asteroid hat einen Durchmesser von 375 Metern, eine Kollision hätte deshalb katastrophale Folgen.

Nachdem eine nahe Gefahr für die Erde ausgeschlossen werden konnte, ist das Interesse der Wissenschaft an Apophis weiter gewachsen. Angesichts des außergewöhnlich nahen Vorbeiflugs in jetzt nur noch vier Jahren handle es sich um eine Gelegenheit, wie sie die Forschung nur einmal pro Jahrtausend bekomme, schreibt die ESA jetzt. Deshalb soll Ramses zu ihm geschickt werden und ihn begleiten, wenn er in gerade einmal 32.000 km an der Erdoberfläche vorbeirasen wird. Weil die Sonde dafür spätestens 2028 gestartet werden muss, haben die Vorbereitungen bereits begonnen, auch wenn eine abschließende Genehmigung der Mission noch aussteht. Vor, während und nach der Erdannäherung soll Ramses dann beobachten, wie sich der Asteroid unter der Gravitation der Erde verändert.

Sollte Ramses genehmigt werden, wäre es aber nicht die einzige Weltraumsonde, die Apophis direkt untersuchen soll. Mit Osiris-Apex ist auch eine umgewidmete NASA-Sonde auf dem Weg zu ihm. Die hat als Osiris-Rex den Asteroiden Bennu besucht und von dort eine Gesteinsprobe zur Erde gebracht. Danach hat sie Kurs auf Apophis genommen und funktioniert nach einer Annäherung an die Sonne sogar besser als vorher. Wegen ihrer Umlaufbahn wird sie aber erst etwa einen Monat nach dem Vorbeiflug von Apophis an der Erde dort ankommen, kann ihn also nur nachträglich erforschen. Ramses soll die Lücke schließen und bei der ESA freut man sich, dass Japan ein Interesse an der Mitarbeit hat.

(mho)