Der ePA-Fehlalarm: Ein einziger API-Parameter und seine Folgen
Der jüngste Vorfall bei der AOK Niedersachsen hat in der deutschen Digital-Health-Szene für viel Aufsehen gesorgt: Zahlreiche Versicherte erhielten fälschlicherweise Post, in der die dauerhafte Löschung ihrer elektronischen Patientenakte (ePA) bestätigt wurde. Was auf den ersten Blick wie ein Formularfehler aussieht, entpuppt sich beim zweiten Hinsehen als ein klassisches Problem verteilter Systeme: Nur ein geänderter API-Parameter im Zuge einer technischen Umstellung durch die Gematik führte zu unvorhergesehenen, verketteten Fehlern im nachgelagerten System der Krankenkasse.
In Zeiten der ePA nach dem Opt-out-Prinzip wiegen solche Patzer schwer. Denn für die Endanwender ist der Unterschied zwischen „Das System hat einen Bug“ und „Meine hochsensiblen Daten sind weg“ nicht erkennbar. Für uns als IT-Verantwortliche, Softwareentwickler und Cybersecurity-Experten ist dieser Vorfall ein perfektes (wenn auch schmerzhaftes) Fallbeispiel dafür, wie eng Systemarchitektur, Datenintegrität und MDR-Compliance in der Praxis zusammenhängen.
Was hinter dem Bug steckt
Die Telematikinfrastruktur (TI) ist kein monolithischer Block, sondern ein fragiles Ökosystem. Gematik, Krankenkassen, Vertrauensdiensteanbieter und die Primärsysteme in den Kliniken und Praxen (KIS/PVS) greifen über unzählige Schnittstellen ineinander.
Wenn an zentraler Stelle ein technischer Parameter angefasst wird, müssen alle nachgelagerten Systeme diesen Wandel fehlerfrei interpretieren können. Der aktuelle Vorfall zeigt uns schonungslos die Realität im alltäglichen Change Management:
- Das Dilemma mit den End-to-End-Regressionstests: Ein zentrales Schnittstellen-Update darf im Jahr 2026 nicht dazu führen, dass nachgelagerte Systeme fälschlicherweise Löschungsroutinen triggern oder Briefe drucken. Im Healthcare-Sektor fehlen oft automatisierte, systemübergreifende Testumgebungen, die solche Seiteneffekte vor dem Rollout im Live-Betrieb aufdecken.
- Die unsichtbare Gefahr: Der „Configuration Drift“: Systeme wachsen über Jahre. Dabei driften die Konfigurationen von Test- und Produktivumgebungen schleichend auseinander. Ein vermeintlich harmloser Payload-Wechsel in einer API kann dann in einer spezifischen Altsystem-Infrastruktur fatale Logikfehler auslösen.
Aus der Praxis für die Praxis: IT-Sicherheit besteht nicht nur aus Verschlüsselung (Confidentiality). Verfügbarkeit (Availability) und Datenintegrität (Integrity) sind mindestens genauso wichtig. Wenn eine Applikation fälschlicherweise den Verlust von Daten meldet, ist der Vertrauensschaden bereits angerichtet. Völlig egal, ob die Daten physisch noch auf dem Server liegen.
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 solche verketteten 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.
Wenn das System versagt, steht die IT allein da
Während Krankenkassen und Dienstleister die technischen Grundlagen aushandeln, tragen die IT-Teams in Krankenhäusern, MVZs und Praxen die operative Last, mit begrenzten Ressourcen und oft ohne ausreichende Vorlaufzeit. Sie baden es aus, wenn Systeme streiken oder korrupte Daten via API geliefert werden. Angesichts der NIS-2-Umsetzung wird die Cyber-Resistenz hier endgültig zur Führungsaufgabe.
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 Schluckauf hat. |
Fazit: Vertrauen ist eine Frage der technischen Exzellenz
Die Akzeptanz der ePA steht und fällt mit dem Vertrauen der Menschen. Und dieses Vertrauen ist im deutschen Gesundheitswesen ein volatiles Gut. Vorfälle wie dieser zeigen uns, dass IT-Sicherheit kein statisches Zertifikat an der Wand ist, sondern ein täglicher, dynamischer Prozess.
Für uns als Techniker, Entwickler und Architekten bedeutet das: Wir müssen unsere Systeme so konzipieren, dass sie resilient gegen die Fehler anderer sind. Ein transparentes Änderungsmanagement, lückenlose Testautomatisierung und eine kompromisslose Zero-Trust-Mentalität sind die einzigen Werkzeuge, mit denen wir die Digitalisierung im Gesundheitswesen sicher auf die Straße bringen.
Share This Article
