Ein Update der Gematik verursacht einen ePA-Fehlalarm bei der AOK. Was zunächst wie ein PR-Problem wirkt, entpuppt sich als typischer Kaskadenfehler. Welche Lehren Tech-Teams daraus ziehen sollten und warum defensive Entwicklung wichtiger wird.

Quelle: www.Forenova.com/de/ 

 

Der neueste Vorfall bei der AOK Niedersachsen sorgt für Aufmerksamkeit in der Digital-Health-Szene. Versicherte erhielten fälschlicherweise Schreiben zur Löschung ihrer elektronischen Patientenakte.

Was zunächst wie ein einfacher Fehler wirkt, entpuppt sich als klassischer Kaskadenfehler in verteilten Systemen. Ein geänderter API-Parameter im Rahmen eines Gematik-Updates führte zu verketteten Fehlinterpretationen im nachgelagerten System.

 

Für Endanwender verschwimmt dabei die Grenze zwischen technischem Bug und vermeintlichem Datenverlust. Für IT-Verantwortliche und Cybersecurity-Teams zeigt dieser Fall deutlich, wie kritisch saubere Schnittstellen, Datenintegrität und durchgängige Überwachung sind. Genau hier setzen Lösungen wie NovaMDR™ von unserem Partner Forenova an, indem sie Anomalien und ungewöhnliche Systemreaktionen frühzeitig sichtbar machen.

 

Was hinter dem Fehler steckt

 

Die Telematikinfrastruktur ist kein geschlossenes System, sondern ein komplexes Zusammenspiel verschiedener Komponenten. Gematik, Krankenkassen, Vertrauensdiensteanbieter sowie Primärsysteme in Kliniken und Praxen arbeiten über zahlreiche Schnittstellen zusammen.

Werden zentrale Parameter verändert, müssen alle angeschlossenen Systeme diese Änderungen korrekt interpretieren. Der aktuelle Vorfall macht typische Herausforderungen im Change Management sichtbar:

 

• Die Herausforderung von End-to-End-Regressionstests
   Ein Update an einer zentralen Schnittstelle darf nicht dazu führen, dass nachgelagerte Systeme unbeabsichtigt Löschprozesse auslösen oder automatisiert Schreiben generieren. Im Gesundheitswesen fehlen häufig durchgängige, automatisierte Testumgebungen, die solche Effekte bereits vor dem Live-Betrieb erkennen

 

• Die unterschätzte Problematik des Configuration Drift
   Über die Zeit entwickeln sich Systeme auseinander. Unterschiede zwischen Test- und Produktivumgebungen entstehen schleichend. Dadurch kann eine scheinbar kleine Änderung in einer API in bestimmten Altsystem-Konstellationen gravierende logische Fehler auslösen.
•  

Integrität als zentraler Bestandteil von Sicherheit

IT-Sicherheit bedeutet mehr als Verschlüsselung. Neben Vertraulichkeit spielen Verfügbarkeit und Integrität eine zentrale Rolle. Wenn ein System fälschlich Datenverlust signalisiert, entsteht bereits ein Vertrauensschaden, unabhängig davon, ob die Daten tatsächlich noch vorhanden sind.

 

MDR und Software-Architektur: Defensive Programming ist kein Luxus

 

Viele IT-Lösungen, die ePA-Daten verarbeiten, gelten als Medizinprodukt, von digitalen Gesundheitsanwendungen bis hin zu KIS-Modulen. Wer Software as a Medical Device entwickelt, weiß: Die IEC 62304 setzt den Takt für den gesamten Software-Lebenszyklus.

 

Der Fall AOK zeigt, warum wir hier architektonisch umdenken und verkettete Effekte softwareseitig abfangen müssen:

 

• Robuste Fail-Safe-Mechanismen: Wenn eine externe API (sei es von der TI oder einer Krankenkasse) aufgrund einer Umstellung unerwartete Werte, leere Felder oder modifizierte Statuscodes liefert, darf Eure Applikation niemals in einen undefinierten Zustand übergehen.
•  
• Konsequentes Defensive Programming: Medizinische Software muss externen Datenströmen grundlegend misstrauen. Erhält das System ein unklares Signal, muss das Frontend den Nutzer sicher abfangen (z. B. durch eine kontrollierte, beruhigende Fehlermeldung), statt direkt den digitalen Weltuntergang zu suggerieren oder den klinischen Workflow zu blockieren.

 

Zudem fordert MDR im Zuge der Post-Market Surveillance (PMS) eine kontinuierliche Überwachung im Feld. Ein sauberes, automatisiertes API-Monitoring hätte hier sofort anschlagen müssen, noch bevor die Druckmaschinen der Krankenkasse überhaupt angelaufen sind.

 

MDR und Softwarearchitektur: Eine defensive Entwicklung ist essenziell

 

Viele Systeme, die mit ePA-Daten arbeiten, fallen unter die Regulierung für Medizinprodukte. Ob digitale Gesundheitsanwendung oder KIS-Modul – die IEC 62304 definiert den kompletten Software-Lebenszyklus.

 

Der Vorfall unterstreicht die Notwendigkeit, Systeme so zu bauen, dass sie verkettete Fehler abfangen können:

 

• Stabile Fail-Safe-Mechanismen: Wenn externe APIs unerwartete Werte, leere Felder oder veränderte Statuscodes liefern, darf das System nicht in einen undefinierten Zustand geraten.
• Konsequentes Defensive Programming: Medizinische Software muss externe Daten grundsätzlich kritisch behandeln. Unklare Signale sollten abgefangen werden, sodass Nutzer kontrolliert informiert werden, anstatt unnötig zu verunsichern oder Arbeitsabläufe zu blockieren.

 

Zusätzlich verlangt die MDR im Rahmen der Post-Market Surveillance eine laufende Überwachung im Betrieb. Ein strukturiertes, automatisiertes Monitoring von APIs hätte solche Abweichungen frühzeitig erkennen können – noch bevor sie praktische Auswirkungen zeigen.

 

Wenn Systeme Fehler liefern, trifft es die IT vor Ort

 

Während Anpassungen an zentralen Schnittstellen stattfinden, stehen die IT-Teams in Kliniken, MVZs und Praxen am Ende der Kette. Sie tragen die unmittelbaren Auswirkungen, wenn Systeme fehlerhaft arbeiten oder inkonsistente Daten liefern. Mit Blick auf die Umsetzung von NIS-2 wird deutlich, dass Cyber-Resilienz eine zentrale Rolle einnimmt.

 

Was bedeutet das konkret für Eure interne IT?

Handlungsfeld	Technische Maßnahme	Das Ziel
Zero Trust Architektur	Strikte Input-Validierung an allen TI-Schnittstellen im eigenen Haus.	Verhindert, dass fehlerhafte Statusmeldungen aus dem WAN die internen KIS-Daten korrumpieren.
Asset & Third-Party Risk	Kontinuierliche Inventarisierung aller vernetzten Medizinprodukte (IoMT).	Schnelle Übersicht, welche Systeme betroffen sind, wenn ein externer Dienstleister ausfällt.
Business Continuity (BCP)	Lokale Caching-Mechanismen und klar definierte Offline-Szenarien.	Der Behandlungsbetrieb und die Medikation müssen laufen – völlig egal, ob die ePA-Anbindung gerade Probleme hat.

 

Fazit: Vertrauen entsteht durch technische Qualität

 

Die Akzeptanz der ePA hängt direkt vom Vertrauen der Nutzer ab. Dieses Vertrauen ist jedoch empfindlich gegenüber technischen Fehlern. Der Vorfall zeigt, dass IT-Sicherheit kein statisches Ziel ist, sondern ein kontinuierlicher Prozess.

 

Für Entwickler, Architekten und IT-Verantwortliche bedeutet das, Systeme so zu gestalten, dass sie auch Fehler anderer Komponenten abfedern können. Transparente Änderungen, durchgängige Testautomatisierung und eine konsequente Zero-Trust-Strategie sind entscheidend, um die Digitalisierung im Gesundheitswesen zuverlässig umzusetzen.

 

Zu den Themenfeldern Zero Trust, Inventarisierung und Business Continuity stehen Experten bei Oberberg-Online (https://www.oberberg.net/anfahrt-kontakt-2/) gerne zum Gespräch bereit.